"캐시" 메모리는 실제로 무료인가요?

많은 실제 사례에서 이러한 견해는 매우 오해를 불러일으킬 수 있습니다.

이제 커널은 현장에서 사용 가능한 메모리의 추정치를 제공합니다 MemAvailable. 이 값은 와 크게 다릅니다 MemFree + Cached.

/proc/meminfo: 사용 가능한 메모리 추정치를 제공합니다.[커널 변경 노트, 2014]

많은 로드 밸런싱 및 작업 부하 배치 프로그램은 /proc/meminfo를 확인하여 사용 가능한 메모리 양을 추정합니다. 일반적으로 "무료"와 "캐시"를 추가하여 이 작업을 수행하는데, 이는 10년 전에는 괜찮았지만 오늘날에는 거의 확실히 잘못된 것입니다.

Cached에는 공유 메모리 세그먼트, tmpfs 및 ramfs와 같이 페이지 캐시로 해제할 수 없는 메모리가 포함되어 있고 대부분의 유휴 시스템에서 대부분의 메모리를 차지할 수 있는 회수 가능한 슬랩 메모리가 포함되어 있지 않기 때문에 이는 잘못된 것입니다. 시스템 메모리의 파일.

현재 새로운 워크로드에 사용할 수 있는 메모리 양은 MemFree, Active(파일), Inactive(파일), SReclaimable 및 /의 "낮은" 워터마크를 기반으로 시스템을 스왑하도록 강요하지 않고 추정할 수 있습니다. 공정/지역 정보. 그러나 이는 미래에 변경될 수 있으며 사용자 공간은 실제로 사용 가능한 메모리 양을 추정하기 위해 커널 내부를 알 것으로 기대해서는 안 됩니다. 이러한 추정치를 /proc/meminfo에 제공하는 것이 더 편리합니다. 미래에 상황이 변한다면 우리는 딱 한 가지만 바꾸면 됩니다.
...

Documentation/filesystems/proc.txt:
...
MemAvailable: 교체 없이 새 응용 프로그램을 시작하는 데 사용할 수 있는 메모리 양에 대한 추정치입니다. MemFree, SReclaimable, 파일의 LRU 목록 크기 및 각 지역의 최저 워터마크를 기준으로 계산됩니다. 이 추정치는 시스템이 제대로 작동하려면 일부 페이지 캐싱이 필요하다는 점과 프로젝트가 사용 중일 때 모든 회수 가능 슬래브가 회수 가능하지는 않다는 점을 고려합니다. 이러한 요소의 영향은 시스템마다 다릅니다.

1.MeM 사용 가능 세부정보

위에서 언급한 것처럼 tmpfs 및 기타 Shmem메모리는 해제할 수 없으며 스왑으로만 이동할 수 있습니다. Cached이는 스왑 가능 메모리가 포함되어 있기 때문에 오해의 소지가 있을 수 있습니다. tmpfs에 파일이 너무 많으면 메모리를 많이 차지할 수 있습니다. :-). 또한 일부를 포함할 수 있습니다/proc/meminfoShmemShmem그래픽 메모리 할당, 이는 매우 클 수 있습니다.

MemAvailable스왑 가능한 메모리는 의도적으로 포함되지 않습니다. 너무 많이 교환하면 오랜 지연이 발생할 수 있습니다. 스왑 공간 없이 실행하거나 상대적으로 제한된 양만 허용하도록 선택할 수도 있습니다.

이것이 어떻게 작동하는지 다시 확인해야 합니다 MemAvailable. 언뜻 보면 이 구별이 코드에 언급되어 있지 않은 것 같습니다.

/*
 * Not all the page cache can be freed, otherwise the system will
 * start swapping. Assume at least half of the page cache, or the
 * low watermark worth of cache, needs to stay.
 */
pagecache = pages[LRU_ACTIVE_FILE] + pages[LRU_INACTIVE_FILE];
pagecache -= min(pagecache / 2, wmark_low);
available += pagecache;

그러나 나는 그것이 Shmem"사용된" 메모리로 올바르게 계산된다는 것을 발견했습니다. tmpfs에 여러 개의 1GB 파일을 만들었습니다. 1GB가 추가될 때마다 1GB를 Shmem줄입니다 MemAvailable. 따라서 파일 LRU 목록의 크기에는 공유 메모리나 기타 스왑 가능한 메모리가 포함되지 않습니다. (이 동일한 페이지 번호도 사용되는 것으로 나타났습니다."더티 리미트"를 계산하는 코드에서).

또한 이 MemAvailable계산에서는 코어의 "낮은 워터마크"와 동일할 만큼 최소한 충분한 파일 캐시를 유지하려고 한다고 가정합니다. 또는 현재 캐시의 절반 중 더 작은 것. (재활용 가능한 슬래브에 대해서도 동일한 가정을 합니다.) 커널의 "낮은 워터마크"를 조정할 수 있지만 일반적으로시스템 RAM의 약 2%. 따라서 대략적인 추정만 원한다면 이 부분을 무시해도 됩니다. :-).

실행할 페이지 캐시에 약 100MB의 프로그램 코드를 매핑할 때 firefox일반적으로 해당 100MB를 RAM에 유지하려고 합니다 :-). 그렇지 않으면 기껏해야 지연이 발생하고 최악의 경우 시스템이 모든 시간을 소비하게 됩니다.이기다다른 응용 프로그램 사이. MemAvailable이를 위해 소량의 RAM도 허용하십시오. 충분히 허용하지 않을 수도 있고, 너무 관대할 수도 있습니다. "이러한 요소의 영향은 시스템마다 다릅니다."

많은 PC 작업 부하의 경우 "파일 수가 많다"는 측면은 관련이 없을 수 있습니다. 그럼에도 불구하고 현재 내 노트북에는 500MB의 회수 가능한 태블릿 메모리(8GB RAM)가 있습니다. 이는 ext4_inode_cache(300,000개가 넘는 개체) 때문입니다 . 최근에 내 디스크 공간을 사용하고 있는 것이 무엇인지 찾기 위해 전체 파일 시스템을 스캔해야 했기 때문에 이런 일이 발생했습니다. :-). 나는 명령을 사용했지만 df -x / | sort -n예를 들어 Gnome Disk Use Analyser는 동일한 작업을 수행합니다.

2. [편집] 대조군의 기억

소위 "Linux 컨테이너"는 namespaces, 및 기타 다양한 기능을 통해 원하는 대로 구축됩니다. :-) cgroups이는 거의 전체 Linux 시스템과 같은 것을 실행하기에 충분한 설득력 있는 환경을 제공할 수 있습니다. 호스팅 서비스는 이러한 컨테이너를 구축하여 "가상 서버"로 판매할 수 있습니다. :-).

호스팅 서버는 또한 메인라인 Linux에는 없는 기능을 사용하여 "가상 서버"를 구축할 수도 있습니다. 오픈VZ컨테이너는 메인라인 cgroup보다 2년 앞서며 "beancounters"를 사용하여 메모리를 제한할 수 있습니다. 따라서 문서를 읽거나 메인라인 Linux 커널에 대해 질문하는 경우에는 이러한 메모리 제한이 어떻게 작동하는지 정확히 이해하지 못할 것입니다. cat /proc/user_beancounters현재 사용량과 한도를 표시합니다. vzubc조금 더 친근한 형식으로 표현합니다. 이것빈카운터 홈페이지레코드 행 이름.

제어 그룹에는 내부 프로세스에 대한 메모리 제한을 설정하는 기능이 포함됩니다. 그러한 cgroup 내에서 애플리케이션을 실행하는 경우 애플리케이션에서 모든 시스템 메모리를 사용할 수 있는 것은 아닙니다. :-). 그렇다면 이 경우 사용 가능한 메모리를 어떻게 확인할 수 있습니까?

인터페이스는 사용 여부에 따라 여러 면에서 다릅니다.cgroup-v1또는cgroup-v2.

내 노트북은 cgroup-v1을 사용하여 설치되었습니다. 나는 뛸 수 있습니다 cat /sys/fs/cgroup/memory/memory.stat. 파일에는 total_rss, total_cache, total_shmemshmem(tmpfs 포함)을 포함한 다양한 필드가 메모리 제한에 포함되는 것을 보여줍니다. total_rss의 역수라고 생각하시면 될 것 같습니다 MemFree. memory.kmem.usage_in_bytes보드를 포함하여 커널 메모리를 나타내는 파일도 있습니다 . (명시적으로 문서화되어 있지는 않지만 향후 확장 memory.kmem.도 포함된다고 가정합니다 .) memory.kmem.tcp.회수 가능한 태블릿 메모리를 볼 수 있는 별도의 카운터는 없습니다. cgroup-v1 문서에 따르면 실제로 메모리 제한에 도달했다고 나와 있습니다.아니요슬래브 메모리 회수를 트리거합니다. (문서에는 "구식"이므로 현재 소스 코드를 확인해야 한다는 면책 조항도 있습니다.)

cgroup-v2는 다릅니다. 나는 루트(최상위) cgroup이 메모리 계산을 지원하지 않는다고 생각합니다. cgroup-v2 파일이 아직 남아 있습니다 memory.stat. 모든 필드는 하위 cgroup에 대해 합산되므로 total_...필드를 조회할 필요가 없습니다 . 같은 일이 이루어졌다고 file말하는 분야가 있습니다 . 짜증나게도 inside 와 같은 전체 필드가 cache​​표시되지 않습니다 . 개별 필드를 더해야 할 것 같습니다. 회수 가능 슬래브 메모리와 회수 불가능 슬래브 메모리에 대한 별도의 통계가 있습니다. v2 cgroup은 메모리가 부족해지기 시작할 때 슬래브를 회수하도록 설계된 것 같습니다.rssmemory.stat

Linux cgroup은 자동으로 가상화되지 않으므로 /proc/meminfo(또는 그 안의 다른 파일 /proc) 전체 시스템에 대한 값이 표시됩니다. VPS 고객에게는 혼란스러울 수 있습니다. 하지만 네임스페이스를 사용하여 /proc/meminfo파일을 바꿀 수 있습니다.특정 컨테이너 소프트웨어로 위조됨. 잘못된 값의 유용성은 특정 소프트웨어의 기능에 따라 다릅니다.

systemdcgroup-v1은 컨테이너 등에 위임하기에 안전한 것으로 간주되지 않습니다. systemd-nspawncgroup-v1 시스템의 컨테이너 내부를 살펴보았습니다 . 그것이 배치된 cgroup과 그 안에 있는 메모리 공간을 볼 수 있습니다. 반면, 포함은 systemd리소스 계산을 위한 일반적인 서비스별 cgroup을 설정하지 않습니다. 이 cgroup 내에서 메모리 계산이 활성화되지 않으면 컨테이너가 이를 활성화할 수 없을 것 같습니다.

cgroup-v2 컨테이너 내부에 있는 경우 실제 cgroup-v2 시스템의 루트와 다르게 보일 것이며 최상위 cgroup의 메모리 공간을 볼 수 있을 것이라고 가정합니다. 또는 표시된 cgroup에 메모리 통계가 활성화되어 있지 않은 경우 위임을 받아 다음을 수행할 수 있기를 바랍니다.메모리 통계 활성화systemd(또는 이에 상응하는).

최신 Linux 커널의 경우 /proc/meminfo이 Cached값에는 모든 사용 사례 Shmem뿐만 아니라 이러한 모든 항목이 포함되므로 tmpfs이를 사용하는 프로그램은 필요한 경우 사실상 무료가 아닙니다. 내 경험상 Cached - Shmem실제 사용 가능한 메모리와 매우 잘 일치합니다. 프로세스를 종료하지 않고는 둘 중 하나를 해제할 수 없지만 Shmem메모리가 부족하면 교체할 수 있습니다.

다음 값을 확인하는 것이 좋습니다(예제 출력).

$ grep -E "^MemTotal|^Cached|^Committed_AS|^Shmem:|^MemAvailable|^MemFree" /proc/meminfo 
MemTotal:       32570668 kB
MemFree:         8245572 kB
MemAvailable:    7817776 kB
Cached:         11553648 kB
Shmem:          10604700 kB
Committed_AS:   36945628 kB

또한 my 는 메모리 중 일부가 조각화되어 전체 성능을 직접적으로 사용할 수 없는 것으로 추정되기 때문에 MemAvailable보다 작습니다 .MemFree

실제 여유 공간에 대한 또 다른 추정치 Cached는 다음과 같습니다.

$ sudo slabtop -sc -o | head | grep "Total Size"
 Active / Total Size (% used)       : 548703.26K / 672516.95K (81.6%)

내 경우에는 약 550MB가 사용 중이며 해제하면 시스템 성능이 저하됩니다.

간단히 말해서:실제 목적이 오해의 소지가 Free있으므로 이름을 보지 마십시오 . 필요한 경우 더 많이 소비할 수 있는 RAM의 양을 살펴보십시오.CachedMemAvailable