Cgroup memory.usage_in_bytes가 잘못된 값을 표시합니다.

사용된 바이트 수

다른 커널 구성 요소와 마찬가지로 효율성을 높이기 위해 메모리 cgroup은 불필요한 캐시 라인 공유 오류를 방지하기 위해 몇 가지 최적화를 사용합니다. use_in_bytes는 이 방법의 영향을 받으며 메모리(및 스왑) 사용량에 대한 "정확한" 값을 표시하지 않으며 유효한 액세스에 대한 퍼지 값입니다. (물론 필요할 경우 동기식으로 수행됩니다.) 보다 정확한 메모리 사용량을 알고 싶다면 memory.stat의 RSS+CACHE(+SWAP) 값을 이용해야 합니다(5.2 참조).

정확한 문서를 읽고 또 읽으면,그리고시스템 성능이 CPU 사용량에 의해 제한된다는 것을 측정했습니다. memory_usage 샘플링을 고려할 수 있습니다.

어떻게 작동하는지 모르겠습니다. 그러나 LWN.net 독자로서 이것은 사용되는 위치에 로컬로 남아 있는 여러 카운터가 있을 수 있고 어떻게든 use_in_bytes를 읽는 것이 이러한 카운터의 즉각적인 동기화 및 요약을 강제하지 않는 상황과 유사하게 들립니다.

수년에 걸쳐 커널 개발자는 메모리 경합 및 이와 관련된 성능 저하를 최소화하기 위해 CPU당 데이터를 점점 더 많이 사용해 왔습니다. 간단한 예로, 블록 계층에서 유지 관리하는 디스크 작업 통계를 생각해 보세요. 각 디스크 작업에 대한 전역 카운터를 늘리면 관련 캐시 라인이 프로세서 간에 바운스됩니다. 디스크 작업은 성능 비용을 측정할 수 있을 만큼 자주 발생합니다. 따라서 각 CPU는 자체 카운터 세트를 로컬로 유지 관리하며, 카운터 중 하나의 값을 증가시키기 위해 다른 CPU와 경쟁할 필요가 없습니다. 총 개수가 필요한 경우 모든 CPU당 카운터가 추가됩니다. 카운터는 수정되는 것보다 쿼리되는 빈도가 훨씬 적기 때문에 이를 CPU별로 저장하면 성능이 크게 향상될 수 있습니다.

--https://lwn.net/Articles/258238/

CPU가 많지 않고 cgroup을 많이 유지하지 않는 소규모 시스템을 가지고 있다면 오버헤드가 그다지 크지 않을 것 같습니다. CPU 간에 몇 개의 캐시 라인을 바운스하는 것은 비용이 많이 들지 않습니다. 하지만 귀하가 Google이고 시스템에서 수천 개의 컨테이너를 실행 중이거나 시스템에 수천 개의 CPU가 있는 경우 효율성이 유용할 수 있습니다.

두 경우 모두 프로세스를 살펴보면 메모리 사용량이 일관되지 않은 것으로 보입니다.

장면 1: cgroup 바로 아래에 생성된 프로세스에서 표시되는 메모리 사용량이 올바른 것 같습니다.

# cgexec -g memory:mem128 sleep 30 &

[2] 18339

 # cat /sys/fs/cgroup/memory/mem128/memory.usage_in_bytes 

135168

장면 2: 프로세스를 별도로 생성하여 cgroup에 할당합니다. 표시된 메모리 사용량이 올바르지 않습니다. 36864가 잘못된 것 같습니다. 때로는 0이 표시되기도 합니다. 이것이 위에 표시된 시나리오 1과 다른 이유는 무엇입니까?

# sleep 90 &

[2] 18937

# cgclassify -g memory:/mem128 18937
# cat /sys/fs/cgroup/memory/mem128/memory.usage_in_bytes 

36864