Linux PSI가 CPU·메모리·I/O 자원 병목을 감지하는 원리

리눅스 PSI를 활용한 시스템 성능 병목 현상 정밀 분석 가이드

리눅스 시스템을 운영하다 보면 갑자기 서버가 느려지거나 특정 프로세스가 응답하지 않는 상황을 마주하게 됩니다. 과거에는 이런 상황에서 CPU 사용률이 100%인지, 메모리가 부족한지, 혹은 디스크 I/O 대기 시간이 긴지를 개별적으로 확인해야 했습니다. 하지만 이런 파편화된 지표들은 ‘사용자가 실제로 체감하는 지연’을 설명하기엔 부족함이 많았습니다. 이를 해결하기 위해 등장한 것이 바로 PSI(Pressure Stall Information)입니다.

PSI는 리눅스 커널이 제공하는 강력한 도구로, 시스템 자원이 부족하여 프로세스가 대기하는 시간의 비율을 직접적으로 측정합니다. 단순히 자원을 얼마나 쓰고 있는지가 아니라, 자원을 쓰고 싶어도 쓰지 못해 얼마나 ‘정체’되었는지를 보여주기 때문에 성능 모니터링의 차원을 한 단계 높여줍니다.

PSI가 탄생한 배경과 중요성

기존의 모니터링 방식에는 치명적인 한계가 있었습니다. 예를 들어 CPU 사용률이 100%라고 해서 반드시 시스템이 느린 것은 아닙니다. 작업이 병렬로 잘 처리되고 있다면 높은 사용률은 오히려 효율적으로 자원을 쓰고 있다는 증거일 수 있습니다. 반대로 CPU 사용률이 낮더라도 I/O 대기(I/O Wait) 때문에 프로세스가 멈춰 있다면 사용자는 시스템이 멈췄다고 느낍니다.

PSI는 ‘프로세스가 자원을 기다리느라 멈춰 있는 시간’을 측정합니다. 이것은 시스템 성능의 ‘진실’에 가장 가까운 지표입니다. 운영자는 PSI를 통해 시스템이 단순히 바쁜 것인지, 아니면 자원 부족으로 인해 실제 서비스 장애가 발생하고 있는지를 즉각적으로 구분할 수 있습니다.

PSI가 감지하는 세 가지 핵심 자원

PSI는 시스템의 안정성을 해치는 세 가지 핵심 자원에 대해 각각 정보를 제공합니다. 각 자원별 특성을 이해하면 장애 대응이 훨씬 빨라집니다.

• CPU: 프로세스가 실행되기를 원하지만 CPU 스케줄러가 차례를 주지 않아 대기하는 시간입니다. CPU 코어 수 대비 프로세스가 너무 많을 때 발생합니다.

• Memory: 프로세스가 메모리 페이지를 할당받으려 하지만, 시스템에 가용 메모리가 없어 페이지 회수(Reclaim)나 스왑(Swap) 작업이 끝날 때까지 대기하는 시간입니다.
• I/O: 프로세스가 디스크에서 데이터를 읽거나 써야 하는데, 디스크의 처리 속도가 느려 입출력 작업이 완료되기를 기다리는 시간입니다.

PSI 지표의 구성과 해석 방법

리눅스 시스템의 /proc/pressure/ 디렉토리 아래에는 cpu, memory, io 파일이 존재합니다. 이 파일들을 열어보면 다음과 같은 형식의 데이터를 확인할 수 있습니다.

some avg10=0.00 avg60=0.00 avg300=0.00 total=0

full avg10=0.00 avg60=0.00 avg300=0.00 total=0

여기서 ‘some’과 ‘full’의 개념을 이해하는 것이 중요합니다.

• some: 적어도 하나 이상의 프로세스가 해당 자원을 기다리느라 지연되고 있는 시간의 비율입니다. 시스템 전반에 약간의 부하가 있다는 신호입니다.

• full: 모든 실행 가능한 프로세스가 해당 자원을 기다리느라 멈춰 있는 상태입니다. 이는 시스템 성능이 사실상 마비된 상태를 의미하며, 즉각적인 조치가 필요한 임계점입니다.
• avg10, avg60, avg300: 각각 최근 10초, 60초, 300초 동안의 평균 지연 시간 비율을 나타냅니다. 1.0은 100%의 시간을 의미하며, 0.05는 5%의 시간을 의미합니다.

흔한 오해와 사실 관계 바로잡기

PSI에 대해 많은 운영자가 흔히 하는 오해 중 하나는 “some 지표가 높으면 무조건 장애다”라는 생각입니다. 사실 some 지표는 시스템이 어느 정도 부하를 처리하고 있음을 나타낼 뿐, 반드시 서비스 장애를 의미하지는 않습니다. 하지만 full 지표가 0보다 크게 나타나기 시작한다면, 이는 사용자가 체감하는 서비스 지연이 발생하고 있다는 확실한 증거입니다.

또 다른 오해는 PSI가 모든 성능 문제를 진단해 줄 것이라는 기대입니다. PSI는 병목의 ‘존재’와 ‘위치’를 알려주지만, 그 원인이 무엇인지(예: 어떤 쿼리가 느린지, 어떤 코드가 메모리를 누수하는지)까지는 알려주지 않습니다. 따라서 PSI는 문제의 범위를 좁히는 1차 진단 도구로 활용하고, 이후 프로파일링 도구(eBPF, perf 등)를 결합하는 것이 올바른 접근입니다.

실무에서 PSI를 활용하는 비용 효율적인 전략

비싼 상용 모니터링 툴 없이도 리눅스 커널의 기본 기능만으로 강력한 알람 시스템을 구축할 수 있습니다. 다음은 실무에서 권장하는 PSI 활용 팁입니다.

1. 임계치 설정: full 지표가 1% 이상인 상태가 10초 이상 지속될 경우 알람을 보내도록 설정하세요. 이는 서비스 영향도가 큰 장애를 사전에 감지하는 데 매우 효과적입니다.
2. 로그 분석과 연동: 시스템 성능이 저하된 시점의 로그를 자동으로 수집하도록 구성하세요. PSI 값이 치솟는 순간의 dmesg 로그나 프로세스 상태를 덤프 뜨면 원인 파악이 훨씬 수월합니다.
3. 컨테이너 환경 적용: 최근 도커나 쿠버네티스에서도 PSI를 지원합니다. Cgroup v2를 사용하는 환경이라면 특정 컨테이너나 파드(Pod) 단위로 자원 병목을 추적할 수 있어 멀티테넌트 환경에서 매우 유용합니다.

전문가의 조언: 왜 PSI를 지금 바로 도입해야 하는가

클라우드 환경이 보편화되면서 인프라는 더욱 복잡해졌습니다. 가상화 계층에서의 지연, 네트워크 스토리지의 불안정성 등 기존의 단순한 메트릭으로는 설명할 수 없는 병목 현상이 너무나 많습니다. PSI는 인프라의 추상화 계층을 뚫고 ‘프로세스가 무엇을 기다리는가’라는 본질적인 질문에 답을 줍니다.

전문가들은 시스템 관리의 효율성을 높이기 위해 ‘지표의 우선순위’를 재정립할 것을 권장합니다. CPU 사용률 90%라는 숫자보다, 메모리 PSI가 0.1% 상승했다는 사실이 서비스 품질에는 훨씬 더 치명적일 수 있기 때문입니다. 여러분의 모니터링 대시보드에 지금 당장 CPU/Memory/IO의 PSI 지표를 추가하십시오. 시스템이 ‘고통받는’ 순간을 가장 먼저 알 수 있는 방법입니다.

자주 묻는 질문과 답변

Q: PSI를 활성화하려면 커널을 새로 컴파일해야 하나요?

A: 대부분의 현대적인 리눅스 배포판(CentOS 8+, Ubuntu 19.04+, Debian 10+)은 이미 PSI를 지원합니다. 커널 설정에서 CONFIG_PSI=y로 설정되어 있는지 확인만 하면 됩니다.

Q: PSI 지표가 높을 때 가장 먼저 무엇을 해야 하나요?

A: 먼저 해당 자원을 점유하고 있는 최상위 프로세스를 찾아야 합니다. ‘top’이나 ‘htop’ 명령어를 통해 CPU나 메모리 점유율이 높은 프로세스를 확인하고, 만약 I/O 지표가 높다면 ‘iotop’을 통해 디스크 입출력을 과도하게 발생시키는 범인을 색출하십시오.

Q: 시스템 성능에 오버헤드는 없나요?

A: PSI는 매우 경량화된 방식으로 설계되었습니다. 시스템 성능에 미치는 영향은 거의 무시할 수 있는 수준이므로, 운영 환경에서 안심하고 활성화해도 됩니다.

PSI는 단순히 관리자를 위한 숫자가 아닙니다. 시스템이 겪고 있는 고통의 크기를 정량화하여, 사용자가 불편을 겪기 전에 미리 조치할 수 있게 해주는 예방 의학적인 도구입니다. 이제 막연한 추측을 멈추고 시스템이 보내는 명확한 신호에 귀를 기울여 보시기 바랍니다.