높은 "Shmem"을 진단하는 방법? (예: `echo 3 > drop_caches`가 캐시를 지우지 않는 이유는 무엇입니까?)

Question 1

저는 위 질문의 저자입니다. 아직까지 완전한 답변은 없지만 이것이 가장 유명한 설명입니다.

최신 Linux 커널에서는 Cached이 값이 /proc/meminfo더 이상 디스크 캐시의 양을 설명하지 않습니다. 하지만,커널 개발자는 현재 이 설정을 변경하기에는 너무 늦었다고 생각합니다..
실제로 사용되는 디스크 캐시의 양을 실제로 측정하려면 Cached - Shmem이를 추정하는 계산을 수행해야 합니다. 원래 질문에서 숫자를 취하면 15151936−14707664(kiB) (from /proc/meminfo) 또는 (kiB)의 출력을 얻게 되므로 444272시스템에 실제로 약 433MiB의 디스크 캐시가 있는 것으로 보입니다. 이 경우 모든 디스크 캐시를 제거해도 많은 메모리가 확보되지는 않습니다. 모든 디스크 캐시를 제거하더라도 필드는 Cached3%만 감소합니다.

따라서 가장 좋은 추측은 일부 사용자 모드 소프트웨어가 많은 공유 메모리(일반적으로 tmpfs또는 공유 메모리 매핑)를 사용하여 Cached시스템에 실제로 디스크 캐시가 거의 없음에도 불구하고 높은 값이 표시된다는 것입니다. 메모리 부족 상태가 가까워지고 있습니다. Committed_AS나는 이것이 이 이론을 뒷받침하는 데 큰 도움이 된다고 생각합니다 MemTotal.

linux-mm다음은 위 링크가 나중에 작동하지 않는 경우를 대비해 위에 링크된 스레드의 결론에 대한 (축약된) 사본입니다 .

제목: Re: Shmem이 /proc/meminfo의 캐시에 포함된 이유는 무엇입니까?
보낸 사람: Vlastimil Babka @ 2021-08-30 16:05 UTC

21년 8월 30일 오전 12시 44분에 Mikko Rantalainen은 다음과 같이 썼습니다.

이는 fs/proc/meminfo.c 함수 meminfo_proc_show()에서 바로 알 수는 없지만 Cached: 필드의 출력에는 항상 모든 Shmem: 필드가 포함되는 것 같습니다.

하지만 지금 바꾸면 더 큰 혼란을 야기할 수 있다. 사람들은 더 이상 새로운 커널의 출력을 처음 볼 때 오해하지 않을 것입니다(IIRC의 "free" 명령도 이를 사용합니다). 그러나 이전 커널과 새 커널을 사용하는 사람들은 이제 그것이 어느 시점에서 변경되었다는 점을 고려해야 합니다... 나쁘다.

보낸 사람: 칼리드 아지즈 @ 2021-08-30 19:38 UTC

2021년 8월 30일 월요일 20:26 +0300에 Mikko Rantalainen은 다음과 같이 썼습니다.

물론, 한 가지 가능한 해결책은 "캐시됨"을 변경하지 않고 실제 캐싱 의미 체계로 "캐시"를 도입하는 것입니다(즉, (캐시됨 - Shmem) 및 메모리 지원 RAM의 합계를 포함함). 이렇게 하면 시스템 관리자는 고유한 값을 가진 두 개 이상의 서로 다른 필드를 보고 문서를 찾을 수 있습니다.

새 필드를 추가하는 것이 좋습니다. /proc/meminfo의 데이터를 해석하고 해당 데이터에 대해 작업을 수행하는 도구/스크립트가 많이 있을 수 있습니다. 기존 데이터의 의미를 변경하면 이러한 도구는 작동하지 않습니다. 새로운 분야의 단점은 출력이 더욱 확장되지만 기존 도구를 손상시키지 않는다는 것입니다.

Answer

저는 위 질문의 저자입니다. 아직까지 완전한 답변은 없지만 이것이 가장 유명한 설명입니다.

최신 Linux 커널에서는 Cached이 값이 /proc/meminfo더 이상 디스크 캐시의 양을 설명하지 않습니다. 하지만,커널 개발자는 현재 이 설정을 변경하기에는 너무 늦었다고 생각합니다..
실제로 사용되는 디스크 캐시의 양을 실제로 측정하려면 Cached - Shmem이를 추정하는 계산을 수행해야 합니다. 원래 질문에서 숫자를 취하면 15151936−14707664(kiB) (from /proc/meminfo) 또는 (kiB)의 출력을 얻게 되므로 444272시스템에 실제로 약 433MiB의 디스크 캐시가 있는 것으로 보입니다. 이 경우 모든 디스크 캐시를 제거해도 많은 메모리가 확보되지는 않습니다. 모든 디스크 캐시를 제거하더라도 필드는 Cached3%만 감소합니다.

따라서 가장 좋은 추측은 일부 사용자 모드 소프트웨어가 많은 공유 메모리(일반적으로 tmpfs또는 공유 메모리 매핑)를 사용하여 Cached시스템에 실제로 디스크 캐시가 거의 없음에도 불구하고 높은 값이 표시된다는 것입니다. 메모리 부족 상태가 가까워지고 있습니다. Committed_AS나는 이것이 이 이론을 뒷받침하는 데 큰 도움이 된다고 생각합니다 MemTotal.

linux-mm다음은 위 링크가 나중에 작동하지 않는 경우를 대비해 위에 링크된 스레드의 결론에 대한 (축약된) 사본입니다 .

제목: Re: Shmem이 /proc/meminfo의 캐시에 포함된 이유는 무엇입니까?
보낸 사람: Vlastimil Babka @ 2021-08-30 16:05 UTC

21년 8월 30일 오전 12시 44분에 Mikko Rantalainen은 다음과 같이 썼습니다.

이는 fs/proc/meminfo.c 함수 meminfo_proc_show()에서 바로 알 수는 없지만 Cached: 필드의 출력에는 항상 모든 Shmem: 필드가 포함되는 것 같습니다.

하지만 지금 바꾸면 더 큰 혼란을 야기할 수 있다. 사람들은 더 이상 새로운 커널의 출력을 처음 볼 때 오해하지 않을 것입니다(IIRC의 "free" 명령도 이를 사용합니다). 그러나 이전 커널과 새 커널을 사용하는 사람들은 이제 그것이 어느 시점에서 변경되었다는 점을 고려해야 합니다... 나쁘다.

보낸 사람: 칼리드 아지즈 @ 2021-08-30 19:38 UTC

2021년 8월 30일 월요일 20:26 +0300에 Mikko Rantalainen은 다음과 같이 썼습니다.

물론, 한 가지 가능한 해결책은 "캐시됨"을 변경하지 않고 실제 캐싱 의미 체계로 "캐시"를 도입하는 것입니다(즉, (캐시됨 - Shmem) 및 메모리 지원 RAM의 합계를 포함함). 이렇게 하면 시스템 관리자는 고유한 값을 가진 두 개 이상의 서로 다른 필드를 보고 문서를 찾을 수 있습니다.

새 필드를 추가하는 것이 좋습니다. /proc/meminfo의 데이터를 해석하고 해당 데이터에 대해 작업을 수행하는 도구/스크립트가 많이 있을 수 있습니다. 기존 데이터의 의미를 변경하면 이러한 도구는 작동하지 않습니다. 새로운 분야의 단점은 출력이 더욱 확장되지만 기존 도구를 손상시키지 않는다는 것입니다.

Question 2

지금 쓰고 있어요메모리 문제 진단에 도움이 되는 도구, 에 있는 정보를 기반으로일부 수식을 포함하는 RedHat의 문서.

디스크 캐시/tmpfs와 관련하여 제가 이해한 바는 다음과 같습니다.

캐시 = 디스크 캐시 - 스왑 캐시 - tmpfs 메모리 사용량

tmpfs는 스왑에 상주할 수 있으므로 먼저 tmpfs의 실제 메모리 사용량을 계산해야 합니다.

간단한 솔루션:

shmem = 공유 메모리 세그먼트 + tmpfs ram

그러나 공유 메모리 세그먼트도 스왑에 있을 수 있으며 shmem은 hugepage 공유 메모리 세그먼트를 포함하지 않는 것으로 보입니다(커널 5.4 및 5.15에서 테스트됨).

더욱 정확한 솔루션

shmem = "4k 페이지 sysvipc shm rss" + tmpfs 램 사용량

"4k sysvipc shm rss"는 표준 페이지 크기(4k)의 공유 메모리 세그먼트에서 사용하는 메모리의 합계이므로 큰 페이지는 없습니다.

아래에서 메모리 세그먼트의 RSS 사용량을 확인할 수 있습니다 /proc/sysvipc/shm.

shm이 4k나 2M 페이지를 사용한다는 사실은 /proc에 노출되지 않는 것으로 보이지만, 공유 메모리 세그먼트에 연결하고 물리 페이지( /proc/kpageflags)를 스캔하면 해당 정보를 얻을 수 있다. 이를 사용하여 공유 메모리 페이지 수를 출력에 추가합니다.

sudo ./memstats groups
[...]
Scanning shm...
Shared memory segments (MiB):
         key           id       Size        RSS         4k/2M        SWAP   USED%        SID
============================================================================================
           0            3          9          9       2442/0            0  100.02           
           0            2          9         10          0/5            0  104.86           
[...]

Answer