Linux PSI가 CPU·메모리·I/O의 실제 대기 시간을 측정하는 방식

리눅스 PSI를 활용한 시스템 성능 병목 현상 정밀 진단

서버를 운영하거나 리눅스 시스템을 다루다 보면 시스템이 느려지는 경험을 하게 됩니다. 이때 가장 먼저 확인하는 것이 CPU 사용률이나 메모리 점유율입니다. 하지만 CPU 사용률이 100%가 아니더라도 시스템이 버벅거리는 경우가 많습니다. 이러한 현상은 자원이 부족해서가 아니라, 자원을 얻기 위해 프로세스가 대기하는 시간 때문에 발생합니다. 이를 정확하게 측정하기 위해 도입된 기능이 바로 PSI(Pressure Stall Information)입니다.

PSI는 리눅스 커널 4.20 버전부터 도입된 기능으로, 시스템이 자원을 기다리느라 얼마나 많은 시간을 허비하는지를 수치화합니다. 단순히 현재 자원을 얼마나 쓰고 있는지 보여주는 것이 아니라, ‘얼마나 많은 프로세스가 자원을 할당받지 못해 멈춰 서 있는가’를 측정함으로써 실제 사용자 경험과 직결된 성능 지표를 제공합니다.

왜 CPU 사용률만으로는 부족한가

전통적인 성능 모니터링 방식은 ‘사용률’에 집중했습니다. 하지만 현대의 복잡한 시스템에서는 사용률이 정답을 말해주지 않습니다. 예를 들어, CPU 사용률이 80%라고 해서 시스템이 과부하 상태라고 단정 지을 수는 없습니다. CPU가 80%를 사용하면서도 모든 프로세스가 원활하게 처리되고 있다면 성능에 문제가 없는 것입니다. 반대로 사용률이 50%인데도 시스템이 응답하지 않는다면, 이는 프로세스들이 CPU를 할당받기 위해 줄을 서서 기다리고 있다는 신호입니다.

PSI는 이러한 ‘대기 시간’을 측정합니다. 리눅스 커널은 특정 자원(CPU, 메모리, I/O)을 필요로 하는 프로세스가 해당 자원을 즉시 얻지 못하고 대기 상태에 머무는 시간을 추적합니다. 이를 통해 우리는 시스템이 ‘얼마나 고통받고 있는지’를 퍼센트 단위로 즉각 확인할 수 있습니다.

PSI가 측정하는 세 가지 자원

PSI는 시스템의 핵심적인 세 가지 자원에 대해 대기 상태를 측정합니다. 각 자원별로 측정 방식과 의미가 다르므로 이를 구분해서 이해하는 것이 중요합니다.

• CPU PSI: 프로세스가 CPU를 사용하고 싶지만, 이미 다른 프로세스가 CPU를 점유하고 있어 대기하는 시간입니다. CPU가 부족하여 스케줄링이 지연될 때 이 수치가 올라갑니다.

• Memory PSI: 프로세스가 메모리 페이지를 할당받아야 하는데, 물리 메모리가 부족하여 스왑(Swap)이 발생하거나 페이지 회수(Reclaim) 과정이 길어질 때 증가합니다. 메모리 부족으로 인한 성능 저하는 매우 치명적이며, 이 수치가 높다면 메모리 증설이 시급합니다.
• I/O PSI: 프로세스가 디스크나 네트워크 스토리지에서 데이터를 읽거나 써야 하는데, I/O 작업이 완료되기를 기다리는 시간입니다. 디스크의 속도가 느리거나 I/O 요청이 너무 많을 때 발생합니다.

PSI 지표 읽는 법

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초 동안의 평균 대기 시간 비율을 나타냅니다.

실생활 활용 사례와 전문가 조언

실제 운영 환경에서 PSI를 활용하는 가장 좋은 방법은 모니터링 도구와 연동하는 것입니다. Prometheus나 Grafana와 같은 도구를 사용한다면 PSI 지표를 수집하여 대시보드에 시각화하세요. 특정 임계치를 넘었을 때 알람을 설정하면, 사용자가 불만을 제기하기 전에 시스템 관리자가 먼저 문제를 인지하고 대응할 수 있습니다.

예를 들어, 웹 서버의 메모리 PSI 수치가 10%를 넘는다면, 이는 메모리 부족으로 인해 시스템이 비정상적으로 스와핑을 하고 있다는 뜻입니다. 이때는 메모리 사용량을 분석하여 메모리 누수가 있는지 확인하거나, 캐시 설정을 조정하여 메모리 압박을 줄여야 합니다. 단순히 CPU 사용률만 보고 있었다면 발견하지 못했을 병목 지점을 PSI는 명확하게 짚어줍니다.

전문가들은 시스템 튜닝의 첫 단계로 PSI를 확인하라고 권장합니다. 튜닝을 하기 전에 먼저 어디가 병목인지 파악하는 것이 우선인데, PSI는 그 병목이 CPU인지, 메모리인지, I/O인지를 즉시 알려주기 때문입니다. “추측하지 말고 측정하라”는 엔지니어링의 기본 원칙을 PSI가 완벽하게 실현해 줍니다.

흔한 오해와 사실 관계

많은 사람들이 PSI 수치가 0이 아닌 것은 무조건 나쁜 것이라고 생각합니다. 하지만 이는 오해입니다. 시스템은 항상 바쁘게 움직이며, 아주 짧은 순간의 대기 시간은 자연스러운 현상입니다. 중요한 것은 수치의 절대값이 아니라 추세입니다. 평소보다 갑자기 수치가 급격히 치솟거나, 장시간 높은 수치를 유지하는지 확인하는 것이 중요합니다.

또한 PSI가 높다고 해서 무조건 하드웨어 증설이 답은 아닙니다. I/O PSI가 높다면 디스크 성능이 문제일 수도 있지만, 비효율적인 데이터베이스 쿼리가 너무 많은 I/O를 유발하고 있을 가능성도 큽니다. PSI는 ‘어디가 문제인가’를 알려주는 나침반이지, ‘무엇을 교체하라’는 지시서가 아니라는 점을 명심해야 합니다.

비용 효율적인 성능 최적화 전략

하드웨어 증설은 비용이 많이 듭니다. PSI를 활용하면 불필요한 비용 지출을 줄일 수 있습니다. 예를 들어, 시스템이 느려질 때 무작정 서버를 업그레이드하기보다 PSI 데이터를 먼저 분석해 보세요. 만약 CPU PSI는 낮고 I/O PSI만 높다면, CPU를 업그레이드하는 것은 아무런 도움이 되지 않습니다. 대신 데이터베이스 인덱스를 최적화하거나, 읽기 전용 복제본을 추가하는 방식이 훨씬 저렴하고 효과적인 해결책이 될 수 있습니다.

또한 가상화 환경이나 클라우드 환경에서는 ‘노이즈 이웃(Noisy Neighbor)’ 문제로 인해 내 서버의 성능이 떨어질 수 있습니다. 클라우드 제공업체의 인프라 문제인지, 내 애플리케이션의 문제인지 구분할 때도 PSI는 강력한 증거가 됩니다. 제공업체에 문의할 때 “CPU 사용률이 높다”라고 말하는 것보다 “PSI 지표상 CPU 대기 시간이 비정상적으로 높다”라고 말하는 것이 훨씬 더 전문적이고 빠른 기술 지원을 이끌어낼 수 있습니다.

자주 묻는 질문과 답변

Q: PSI 지표를 확인하려면 별도의 설치가 필요한가요?

A: 아니요. 최신 리눅스 배포판(커널 4.20 이상)을 사용 중이라면 이미 내장되어 있습니다. 별도의 에이전트 설치 없이 /proc/pressure 디렉토리의 파일들을 읽기만 하면 됩니다.

Q: 모든 프로세스에 대해 PSI를 확인할 수 있나요?

A: 기본적으로 시스템 전체에 대한 PSI를 제공합니다. cgroup v2를 사용한다면 특정 그룹(컨테이너 단위 등)별로 PSI를 상세하게 추적할 수 있어, 어떤 서비스가 시스템 자원을 독점하고 있는지 파악하기 매우 용이합니다.

Q: PSI 수치가 어느 정도일 때 경고를 보내야 하나요?

A: 시스템의 성격에 따라 다르지만, 보통 10초 평균(avg10) 기준으로 5%~10%를 넘어가기 시작하면 주의 깊게 관찰해야 합니다. 20%를 넘어서면 즉각적인 조치가 필요한 수준으로 보는 것이 일반적입니다.

PSI는 리눅스 시스템 운영의 패러다임을 바꾼 중요한 지표입니다. 단순히 자원의 양을 보는 시대는 지났습니다. 이제는 자원을 얼마나 효율적으로 전달하고 대기 시간을 최소화하는지가 시스템 성능의 핵심입니다. 오늘부터 시스템 모니터링 도구에 PSI를 추가하여 더욱 정밀하고 스마트한 운영 환경을 구축해 보시기 바랍니다.