페이스북 소프트웨어 엔지니어인 로마노 구슈친 은 리눅스 커널 개발 메일링 리스트에 슬랩 드라이버의 메모리 할당 애플리케이션 (메모리 컨트롤러) 에 대한 일련의 패치를 게시했습니다 .
새로운 드라이버의 가장 큰 특징은 슬랩 회계를 메모리 페이지 수준에서 커널 객체 수준으로 이동시켜, 각 c-그룹마다 별도의 슬랩 캐시를 할당하는 대신 서로 다른 c-그룹 간에 슬랩 페이지를 공유할 수 있게 되었다는 점입니다.
Roman은 기존의 슬래브 메모리 컨트롤러에서 "매우 심각한 결함"이라고 부르는 것을 발견했습니다. 이로 인해 요즘 cgroup의 활용도가 낮아졌습니다.
“기존 설계가 슬래브 활용률을 낮추는 진짜 이유는 간단합니다. 슬래브 페이지는 메모리 풀에서만 독점적으로 사용됩니다.
cgroup에 의해 특정 크기의 할당이 몇 개만 있거나 cgroup이 제거 된 후 일부 활성 객체가 남아 있거나 cgroup에 커널 객체를 거의 할당하지 않지만 매번 활성화되는 단일 스레드 응용 프로그램이 포함 된 경우 새로운 CPU :이 모든 경우에 슬래브 사용률이 매우 낮습니다.
kmem 계정이 비활성화 된 경우 커널은 다른 할당을 위해 슬랩 페이지의 여유 공간을 사용할 수 있습니다. «
작년에 로마노 구슈친이 제안한 슬랩 메모리 컨트롤러는 슬랩 사용 효율성을 높이고 슬랩에 사용되는 메모리 크기를 30~45% 줄이며 코어의 전체 메모리 사용량을 크게 줄여주기 때문에 매우 유망한 것으로 평가받았습니다.
또한, 적용된 패치를 통해 페이스북이 이미 자사 서버에서 해당 코드를 실제 운영 환경에 사용하고 있으며, 프런트엔드 웹 서버 , 데이터베이스 캐싱 및 DNS 서버 등에서 약 650~700MB 이상의 용량을 절약하고 있는 것으로 나타났습니다.
이동 불가능한 슬래브의 수를 줄이는 것은 메모리 단편화에도 긍정적인 영향을 미칩니다. 새로운 메모리 컨트롤러는 슬래브 관리를 위한 코드를 크게 단순화하고 , 각 c-그룹에 대해 슬래브 캐시를 동적으로 생성 및 삭제하는 복잡한 알고리즘의 필요성을 없애줍니다.
새로운 구현에서 메모리에 대한 모든 cgroup은 공통 슬래브 캐시 세트를 사용하며, 슬랩 캐시의 수명은 더 이상 cgroup을 통해 설정된 메모리 제약의 수명과 연결되지 않습니다.
새로운 슬래브 컨트롤러에 구현 된보다 정확한 리소스 계산은 이론적으로 CPU에 더 많은 부하를 주어야하지만 실제로는 그 차이가 무시할 만합니다.
특히, 새로운 슬랩 컨트롤러는 다양한 유형의 부하를 처리하는 실제 페이스북 서버에서 수개월 동안 사용되었으며 , 현재까지 심각한 성능 저하는 감지되지 않았습니다.
패치에는 몇 개의 반독립적인 부품이 포함되어 있으며, 슬랩의 메모리 컨트롤러 외부에서도 사용할 수 있습니다.
- 페이지 크기가 아닌 다른 개체 (예 : percpu 할당)를 계산하는 데 나중에 사용할 수있는 Subpage Load API
- memcg로 계수되는 포인터가있는 mem_cgroup_ptr API는 다른 객체 (예 : pagecache)의 효율적인 부모 재 지정을 위해 재사용 할 수 있습니다.
동시에 메모리 사용량도 크게 감소했습니다 . 일부 호스트에서는 최대 1GB의 메모리를 절약할 수 있었지만, 이 수치는 부하의 특성, 전체 RAM 용량, CPU 사용량 및 메모리 사용 특성에 따라 크게 달라집니다.
각 메모리 cgroup에 대해 별도의 kmem_caches 집합을 만드는 대신 두 개의 전역 집합이 사용됩니다. 하나는 unaccounted 루트 집합이고 다른 하나는 루트 그룹 cgroup 할당이고 두 번째 집합은 다른 모든 할당입니다. 이를 통해 개별 kmem_cache의 수명 관리를 단순화 할 수 있습니다.
마지막으로, 새로운 19개 패치에 대해 더 자세히 알고 싶으시다면 커널 메일링 리스트에서 확인하실 수 있습니다.