[TWIL]CPU 과점유 시 확인해야 할 사항들

이번에 통합 테스트를 진행하면서 cpu가 과점유되는 현상이 있었는데요.

그때 대처했다면 더 좋았을 사항들을 회고하려고 합니다.

 

문제 상황 : 

• 새로운 기능에 대한 통합 테스트 중 java 모듈이 순간적으로 cpu를 과점유 한다는 제보
• 해당 상황에서 전체적인 응답 지연 발생

Keep : 프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분

Top 명령으로 cpu 과점유를 하는 것으로 의심되는 process를 특정할 수 있었습니다.

 

linux의 top 은 시스템 리소스 모니터링 도구로, CPU, 메모리 사용량, 프로세스 목록 등을 실시간으로 확인할 수 있습니다.

옵션 없이 사용하면 3초마다 화면을 갱신하면서 CPU 사용률 순으로 정보를 보여줍니다.

 

top 명령 실행 시 아래와 같은 화면이 표시됩니다.

 

Top 명령어 실행 시 출력 정보

 

1. 현재 서버의 시간(date 명령을 치면 나오는 결과와 동일), 서버 구동 시간 ( 1day, 23:58분동안 서버 구동 중)

2. 현재 시스템에 연결된 사용자의 수

3. 시스템의 Load Average : CPU 부하에 관련된 지표로, 왼쪽부터 1분 / 5분 / 15분에 대한 부하 수치입니다.

얼마나 많은 프로세스가 실행 중(Running) 혹은 실행 대기중인지(Uninterruptible Sleep) 의미하는 수치로. 

Load Average가 높다면 많은 수의 프로세스가 실행중이거나 I/O 등을 처리하기 위한 대기 상태에 있다는 것을 의미합니다.

 

참고로 Load Average 값은 CPU의 코어수에 따라 숫자가 달라지며

100% Load가 발생하는 경우 1코어는 1, 2코어는 2,  4코어는 4로 값이 표현됩니다. 

시스템 운영시 권장하는 에버리지는 70% 이하 이며 그 이상일 경우 시스템에 이상이 없는지 체크해야 한다고 합니다. 

 

4. 현재 시스템에서 구동중인 프로세스 개수 

Tasks의 지표를 통해 아래의 정보를 얻을 수 있습니다.

• total : 모든 상태의 프로세스 합계
• running : 요청을 처리하고 정상적으로 실행하며 CPU 액세스 권한을 가진 프로세스 수 
• slepping : 리소스를 대기중인 프로세스
• stopped : 리소스를 종료하거나 해제하는 프로세스
• zombie : 부모 프로세스가 릴리스하기를 기다리는 프로세스

5. 각각의 CPU, Mem, swap 메모리의 사용량 

&Cpu(s)는 프로세스가 사용하는 CPU 리소스에 대해 자세한 지표를 보여줍니다

• us : 사용자 프로세스 실행에 소요된 시간의 백분율
• sy : 커널 실행에 소요된 시간의 백분율
• ni : 수동으로 구성된 nice 값으로 프로세스를 실행하는 데 소요된 시간의 백분율
• id : 유휴 시간의 백분율(높은 경우 CPU가 과도하게 사용될 수 있다고 판단가능)
• wa : 대기 시간의 백분율(높은 경우 CPU가 I/O 액세스를 대기중이라고 판단 가능)
• hi : 하드웨어 인터럽트를 관리하는 시간의 백분율
• si : 소프트웨어 인터럽트를 관리하는 데 걸리는 시간의 백분율
• st : 호스트의 물리적 CPU에 리소스를 할당받기 위해 대기하는 가상 CPU 시간의 백분율

위의 지표 중 id, wa, st 지표로 현재 시스템이 얼마나 과부화 되었는지 알수 있다고 합니다.

 

MiB Mem 은 시스템이 가진 메모리 사용률을 보여줍니다.

• total : 설치된 총 메모리
• free : 사용 가능한 메모리
• used : 사용중인 메모리
• buff/cache : 쓰기 위해 버퍼링되는 정보의 양

MiB Swap 은 swap 메모리 사용률을 보여줍니다. Swap 메모리는 물리적 RAM이 부족할 때 디스크 공간을 임시 메모리로 사용하는 기능이죠. OS가 RAM이 부족하면 사용하지 않는 데이터를 Swap 공간으로 이동시켜서 RAM을 확보한다고 합니다. 

• total : 전체 swap 메모리
• free : 사용 가능한 swap 메모리
• used : 사용중인 swap 메모리
• avail Mem : 새로운 애플리케이션을 시작할 수 있는 메모리 양 추정

만약 swap 메모리가 상단에 있으면 swap 메모리의 사용 여부가 시스템의 상태에 중요한 영향을 끼친다는 뜻으로도 해석이 가능합니다. 

 

• PR : 프로세스의 실행 우선 순위
• NI : PR을 얼마만큼 조절할 것인지를 결정 ( 기존 PR + NI = 실제 PR값)
• VIRT : task가 사용중인 virtual memory의 전체 용량
• RES : task가 사용중인 물리 메모리의 양( 실제로 메모리 점유율은 RES를 보고 판단한다고 한다)
• SHR : 다른 프로세스와 공유하고 있는 shared memory의 양
• S : 프로세스 상태

프로세스 상태 종류:

- D(uninterruptible sleep) : 디스크 혹은 네트워크 I/O 를 대기하고 있는 프로세스를 의미

- R(running) : 실행 중인 프로세스. 실제로 CPU 자원을 소모

- S(sleeping) : sleeping 상태의 프로세스로, D 상태와의 가장 큰 차이점은 요청한 리소스를 즉시 사용할 수 있는지 여부

- T(traced or stopped) : 프로세스의 시스템 콜을 추적하고 있는 상태 (자주 볼 수 없는 상태)

- Z(zombie) : 부모 프로세스가 죽은 자식 프로세스를 의미 (자신을 만든 부모 프로세스가 완료된 상태인 경우)

 

S 상태의 프로세스가 많은 것은 시스템에 큰 영향을 끼치지 않습니다.

그러나  D 상태의 프로세스가 많으면 특정 요청이 끝나기를 기다리고 있는 프로세스가 많다는 것을 의미하고,

이 프로세스들은 요청이 끝나면 R 상태로 다시 돌아가야 하기 때문에 시스템의 부하를 계산하는 데 포함됩니다.

Top 명령어 옵션

- shift + p : CPU 사용률 순으로 정렬(기본값)

- shifg + m : Memory를 많이 사용하는 프로세스순으로 정렬

 

실제로 모니터링 하는 과정중에 특정 모듈에서 cpu 사용률이 100%이상으로 올라가는 것을 확인하였습니다.

 

- Shirf + h : 스레드 정보 출력

# 아래와 같이 top 명령 실행 가능(특정 PID의 스레드 확인)
- top -H -p [PID]

스레드 정보도 출력할 수 있으나 스레드이름만 나올 뿐 자세한 정보는 알 수 없어 원인 분석이 어려웠습니다.

Problem : 프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점

cpu 과점유가 발생한다는 제보는 밤이었는데요,

아침에 출근해서 visualVM으로 과점유 의심 프로세스를 모니터링 해보았으나

다른 분이 버그성 패치를 진행하면서 현상이 해소되어 정확하게 어떤 부분에서 과점유가 발생했는지는 알 수 없었습니다.

 

그래서 일단 다시 재현되지 않으니 패치를 통해 해소되었다 라고... 생각하고 넘어가게 되었습니다...(찜찜한 결말)

Try : Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해볼 점

visualVM을 이용하면 cpu 사용량을 그래프로 확인할 수 있고, thread 정보 또한 실시간으로 확인이 가능하기 때문에, 

만약 cpu 과점유 현상이 재현된다면

1. visualVM을 통한 모니터링 (증적 가능)

2. threadDump 생성 (원인분석을 위함)

 

이 두가지를 시도해보고 싶습니다.

 

 

참고 : https://haengsin.tistory.com/99