NFS 페이지 캐시가 NUMA 지연을 키웠다는 u/sobrique의 운영 사례

본문

r/sysadmin에 글을 올린 u/sobrique는 운영 서버의 프로세스가 간헐적으로 느려져 실시간 처리 기한을 놓치는 문제를 수개월간 추적했다고 밝혔습니다. 파이썬으로 만든 자체 측정에서는 코어 절반이 50%가량 느린 듯 나타났습니다. 재부팅하면 증상이 사라지기도 했지만, 일부 테스트 호스트에서는 재부팅 뒤 NUMA 노드 간 메모리 지연이 더 커져 그대로 유지됐습니다. 작성자는 커널과 BIOS, IPMI를 새로 적용하고 BIOS 설정도 초기화했지만 하드웨어 고장 여부를 가려내지 못했다고 썼습니다.

측정 결과가 뒤집혀 보인 이유도 설명했습니다. 작성자는 느려진 것으로 보인 시스템이 기준 성능으로 돌아온 상태였고, 오히려 “좋은” 시스템이 약간 성능이 낮아진 상태였다고 했습니다. 정상 처리된 ECC 이벤트가 BIOS에서 NUMA lookup directory를 비활성화하게 만든다는 설명입니다. 이 조회를 건너뛰면 데이터를 대략 두 번 가져와 NUMA 대역폭을 더 쓰지만, 속도는 약간 높아질 수 있다고 덧붙였습니다.

장시간 실행 프로세스가 NUMA 지연을 겪은 원인으로는 NFS 파일을 집중적으로 읽으며 쌓인 페이지 캐시를 지목했습니다. 해당 호스트는 재부팅 후 약 한 시간 안에 캐시를 채웠습니다. NUMA 시스템에서는 CPU와 메모리가 노드별로 나뉘며 메모리 배치가 접근 지연에 영향을 줍니다. 리눅스 커널 문서는 시스템이 가동된 뒤 기본 메모리 정책이 로컬 노드 할당을 쓴다고 설명합니다.

u/sobrique는 페이지 캐시가 찬 뒤 NUMA 노드 간에 메모리가 넘쳐 배치되고, 후속 캐시 할당도 여러 노드에 분산되면서 프로세스 메모리가 노드별로 나뉠 수 있다고 설명했습니다. 장시간 실행 프로세스는 그 결과 NUMA 메모리 접근 지연을 겪는다는 진단입니다. 작성자는 당시 운영체제에서 “free”로 남은 메모리가 약 2GiB인 상태에서 새 프로세스가 8~12GB를 확보하면 노드 간 분산이 빠르게 일어날 수 있다고 봤습니다.

작성자는 두 가지 방안을 제시했습니다. numactl로 프로세스 메모리를 특정 NUMA 노드에 바인딩하거나, systemd에서 해당 서비스 단위의 MemoryHigh를 무제한 대신 물리 메모리의 90~95%로 설정하는 방식입니다. 작성자는 후자가 몇 GB를 회수해 새 프로세스가 8~12GB를 확보할 때 노드 간 분산을 피할 여지를 만든다고 설명했습니다. systemd 문서상 백분율은 설치된 물리 메모리를 기준으로 하며, MemoryHigh는 해당 단위 프로세스의 메모리 사용량을 조절합니다. 사용량이 경계를 넘으면 프로세스 처리를 크게 늦추고 메모리를 적극 회수하며, 불가피하면 사용량이 MemoryHigh를 초과할 수 있습니다. 절대 상한은 별도 설정인 MemoryMax가 맡습니다.

u/sobrique는 해결책을 테스트 환경에 배포했고 오랜 문제의 실마리를 찾은 듯하다고 적었습니다. 어느 방안을 적용했는지와 적용 후의 성능 수치는 게시물에 없습니다. 호스트 구성과 NUMA 토폴로지도 구체적으로 제시되지 않아, 진단은 작성자가 보고한 운영 사례에 한정됩니다.

자료: Reddit r/sysadmin / 정리·해설: Trawling