문제/배경
systemd-nspawn 컨테이너의 Fedora 32에서 실행되는 (관리되는) Postgres 10.16 인스턴스가 있습니다. 정기적으로 메트릭에서 "시스템" CPU 사용량이 크게 급증하는 것을 볼 수 있는데, 이는 Postgres 쿼리 처리량 및 디스크 활동의 급격한 감소와 관련되어 30초에서 몇 분까지 지속됩니다. 또한 지표 수집기는 10초마다가 아닌 불규칙한 간격으로 수집합니다. 이 문제는 대략 하루에 한 번 발생합니다. *
단서
지난번에 이런 일이 발생했을 때 몇 가지 진단을 실행한 결과 대부분의 낮은 성능 기간 동안 다음과 같은 사실을 발견했습니다.
- kswapd는 코어를 100% 사용하고 있습니다.
- 주기적 덤프를 살펴보면 변경 대비 변경 비율이 0.014라는
/proc/vmstat것을 알 수 있습니다 .pgsteal_kswapdpgscan_kswapd
즉, kswapd는 페이지 캐시에서 페이지를 회수하려고 하는 것으로 보이지만 회수하는 모든 페이지에 대해 약 70페이지를 살펴봐야 합니다.이 매뉴얼 페이지0.3 미만의 비율은 우려할 만한 원인임을 나타냅니다. 이벤트 중 하나의 50초 동안 kswapd는 총 230만 페이지를 스캔했고 그 중 32,000페이지만 재활용했습니다.
나는 이 병리학적 페이지 캐시 제거 동작이 이와 관련된 성능 문제와 관련이 있다고 의심합니다. 나는 또한 이것이 postgres가 여기 컨테이너에서 실행되고 있다는 사실과 관련이 있다고 생각합니다.비슷하지만 같지 않은 질문입니다.(안타깝게도 이 결정은 호스팅 제공업체에 따라 다르기 때문에 변경할 수 없습니다.) 하지만 이 동작의 원인이 구체적으로 무엇인지, 근본 원인을 찾거나 해결하는 방법은 잘 모르겠습니다.
질문
두 가지 관련 질문이 있습니다.
- 어떤 유형의 메모리/디스크 액세스 패턴이 재활용을 비효율적으로 만들 수 있습니까?
- 다음에 이런 일이 발생할 때 어떤 정보를 수집할 수 있습니까? 또는 가능성 공간을 좁히기 위해 디버깅하려면 어떻게 해야 합니까?
부록: 내가 고려하고 거부한 가설
이 책페이지 재활용 효율성이 낮은 두 가지 이유는 다음과 같습니다.
이 알고리즘의 성능이 저하될 수 있는 상황은 두 가지뿐입니다. 첫 번째는 재활용 후보가 주로 익명 페이지인지 여부입니다. 이 경우 Linux는 회수할 페이지를 검색하기 위해 프로세스 페이지 테이블을 선형적으로 스캔하기 전에 계속해서 많은 수의 페이지를 확인하지만 다행히도 이러한 경우는 드뭅니다.
/proc/meminfo비활성 페이지의 상당 부분이 "익명"이 아닌 "파일"임을 보여주는 동시 덤프가 있습니다. 이는 대부분의 시스템 메모리를 페이지 캐시에 할당하도록 권장하는 Postgres의 일반적인 현상입니다 . 그래서 나는 그것이 우리에게 적용되지 않는다고 생각합니다.
두 번째 경우는 단일 프로세스의 inactive_list에 자주 기록되는 파일 지원 상주 페이지가 많이 있다는 것입니다. 프로세스와 kswapd는 이러한 페이지를 지속적으로 "정리"하고 아무것도 공개하지 않고 inactive_list의 맨 위에 배치하는 루프에 들어갈 수 있습니다. 이 경우 두 목록 크기 간의 비율이 여전히 크게 변하지 않기 때문에 active_list에서 inactive_list로 이동되는 페이지가 거의 없습니다.
vmstat 덤프에 따르면 nr_dirtied이벤트 기간 동안 약 33k만 추가된 반면 pgscan_kswapd2.3m가 추가되었습니다. 따라서 kswapd는 페이지를 쓰는 것보다 훨씬 빠르게 페이지를 스캔할 수 있으며 그것도 문제가 되지 않습니다.
*50% 더 많은 코어와 2배 더 많은 RAM을 갖춘 대규모 오버프로비저닝 인스턴스로 업그레이드했기 때문에 아직 이런 일이 발생하지 않았습니다.