티스토리 뷰
[TroubleShooting] CPU - USR vs SYS 영역
GodNR 2018. 6. 19. 23:02본 포스팅은 CPU를 사용하는 usr / sys 영역간의 차이점에 대해 알아보겠습니다.
언젠가 사이트 CPU 이슈 발생 시 "CPU 사용 영역이 usr 영역인가요? sys 영역인가요?" 라고 물어봤던 기억이 납니다. CPU를 대량 사용하는 Process or Thread를 찾는 일은 매우 중요한일입니다. 다만 본 포스팅에서 다루는 내용을 통해 확인해야 할 범위를 최소화 할 수 있다면 이는 매우 도움이 될 것입니다. 예를 들어 usr or sys 영역을 줄일 수 있다면 범위를 40% 정도 줄인것이라 할 수 있습니다. 이번 포스팅이 CPU 사용에 대한 고민이 많은 엔지니어들에게 도움이 되었으면 합니다.
먼저 vmstat 명령 시 CPU 컬럼에 대해 알아보겠습니다.
us영역은 user mode 에서 소비된 cpu시간의 백분율을 나타냅니다.
사용자 모드에서 소비되는 CPU 시간의 퍼센트를 표시하는 열입니다.
UNIX 프로세스는 사용자 모드 또는 시스템 (커널) 모드에서 실행할 수 있습니다.
사용자 모드인 경우, 프로세스는 응용프로그램 내에서 실행하며, 계산, 메모리 관리, 변수 설정을 수행하는데 자원을 필요로 하지 않습니다.
sy영역은 system mode 에서 소비된 cpu 시간의 백분율을 나타냅니다.
sy 열은 CPU가 시스템 모드에서 프로세스를 실행한 시간의 퍼센트를 상세히 표시합니다.
이것은 커널 프로세스(kprocs) 및 커널 자원으로 액세스하기 위해 필요한 기타의 것들에 의해 소비되는 CPU 자원을 포함합니다.
프로세스가 커널 자원을 필요로 하는 경우, 시스템 호출을 실행해야 하며 자원을 사용할 수 있게 만들도록 시스템 모드로 스위치됩니다.
예를 들어, 메모리 맵핑된 파일이 사용되지 않는 경우, 파일의 읽기 또는 쓰기는 파일을 열고, 특정 위치를 찾으며, 데이터를 읽고 쓰는데 커널 자원을 필요로 합니다.
id영역은 delay 된 disk I/O가 없는 상태에서 CPU가 idle 한 시간을 나타냅니다.
id 열은 국지 디스크 입출력을 보류하지 않고 CPU가 유휴이거나 대기 중인 시간 퍼센트를 표시합니다.
실행할 수 있는 스레드가 없는 경우, 시스템은 idle kproc라고도 하는 대기라는 스레드를 작업 지정합니다.
SMP 시스템에서, 프로세서당 하나의 대기 스레드가 작업 지정될 수 있습니다.
ps 명령(-k 또는 -g 0 옵션과 함께)은 이것을 kproc 또는 wait로 식별합니다. ps 보고서가 이 스레드에 대해 높은 총계 시간을 표시하는 경우, 어떤 스레드도 실행할 준비가 되어 있지 않거나 CPU에서 실행을 위해 대기 중이지 않을 상당한 시간 간격이 있었다는 것을 의미합니다. 그러므로, 시스템은 대부분 새 타스크를 위해 유휴이면서 대기 중이었습니다.
wa영역은 delay된 disk I/O가 있는 상태에서 CPU가 idle 한 시간을 나타냅니다.
wa 열은 CPU가 보류 국지 디스크 입출력 및 NFS 마운트 디스크에서 유휴한 시간의 퍼센트를 자세히 나타냅니다.
wait가 실행 중일 때, 디스크에 대한 보류 입출력이 적어도 하나 존재한다면, 시간은 입출력에 대한 대기로 분류됩니다. 프로세스가 비동기식 입출력을 사용하지 않는다면, 디스크에 대한 입출력 요청은 요청이 완료될 때까지 호출 프로세스가 블록(또는 휴면)되도록 합니다. 프로세스에 대한 입출력 요청이 완료되면, 실행 대기행렬에 위치합니다.
입출력이 보다 신속하게 완료되는 경우, 더 많은 CPU 시간이 사용될 수 있습니다.
25%에 걸친 wa 값은 디스크 서브시스템이 올바르게 균형을 이루지 않았거나, 디스크 집약 작업 부하의 결과일 수 있습니다.
두번째로 sar 명령 시 CPU 컬럼에 대해 알아보겠습니다.
sar 명령어는 프로세서 또는 시스템간 통계에 대하여 보고합니다. -P 플래그와 함께 사용할 때 지정된 각 프로세서에 대한 정보가 제공됩니다. 그렇지 않으면, 시스템 전체에 대한 정보만 제공됩니다. -u플래그 정보가 백분율로 표현되므로 시스템 전체 정보는 단순하게 각 개별 프로세서 통계의 평균입니다. 또한, 입출력 대기 상태는 프로세서당 정의되는 것이 아니라 시스템 전체에 걸쳐 정의됩니다.
다음과 같은 값이 표시됩니다.
idle은 프로세서가 미해결한 디스크 입출력 요청 없이 유휴 상태인 시간의 백분율을 보고합니다.
sys는 프로세서가 시스템(또는 커널) 레벨에서 실행에 소비되는 시간의 백분율을 보고합니다.
usr는 프로세서가 사용자(또는 애플리케이션) 레벨에서 실행에 소비되는 시간의 백분율을 보고합니다.
wio는 시스템에 미해결한 디스크/NFS 입출력 요청이 있는 동안 프로세서가 유휴 상태인 시간의 백분율을 보고합니다.
physc는 소비된 물리적 프로세서 수를 보고합니다. 파티션이 공여를 위해 제공되고 사용으로 설정되거나, 공유 프로세서로 실행하고 있거나 동시 멀티스레딩이 사용 가능하게 했으면 이 데이터는 보고됩니다.
entc는 소비된 자격 부여 용량의 백분율을 보고합니다. 이는 파티션이 공유 프로세서와 함께 실행 중인 경우에만 보고됩니다. 이 데이터가 계산되는 시간축이 다양할 수 있으므로 자격 부여된 용량 백분율은 종종 100%를 초과할 수 있습니다. 이와 같은 초과 현상은 샘플링 간격이 작을 경우에 주로 발생합니다.
resc는 소비된 프로세서 자원의 백분율을 보고합니다. 이 메트릭은 WPAR 환경에만 적용될 수 있습니다. WPAR이 프로세서 자원 한계를 실시하는 경우에만 보고됩니다.
세번째로 User Mode & Kernel Mode에 대해 알아보겠습니다.
System Call Interface를 기준으로 상부에 User Mode, 하부에 Kernel Mode라고 하며 User Mode상에서 사용되는 CPU를 USER CPU라고 하며, Kernel Mode상에서 사용되는 CPU를 SYSTEM(Kernel) CPU라고 합니다.
read() 함수가 User Process에서 발생하게 되면 이는 System Call Interface를 통해 Kernel Mode에 전달되어 File System I/O를 통해 Hardware(Disk등)를 조작(operation)하게 됩니다.
USER 영역의 CPU는 프로그램 코드에 의해 수행되게 됩니다. 즉 User Process가 프로그램 코드를 수행함으로써 발생하는 CPU 연산 작업을 User 영역의 CPU라 할 수 있습니다.
SYSTEM 영역의 경우는 User Process가 프로그램 코드를 수행함에 있어 System Call Interface 부분을 사용하기 위한 코드가 들어간다면 (read, write등), 이때 OS는 자동으로 Kernel에게 해당 부분을 처리하기 위해 CPU 자원을 할당하게 됩니다.
CPU 과부하가 발생하는 경우 어느 영역의 CPU자원이 과부하인지를 확인함으로써 분석 범위를 줄일 수 있으며, 또한 수집해야 할 분석 대상 정보도 판별할 수 있습니다.
마지막으로 Application Code & System Call 매핑에 대해 알아보겠습니다.
메소드에서 일반적인 연산(String의 concatenation 연산)은 USER CPU를 사용하는 것이며, System.out.println()함수(표준출력,STDOUT으로 write)와 FileOutputStream(aaa.txt 파일에 String 내용을 기록)는 SYSTEM CPU를 사용하는 것입니다.
truss 결과 kwrite()와 open(), fstatx()등의 여러가지 SYSTEM CALL이 발생하는 것을 알 수 있습니다.
프로그램 코드와 매핑해 보면 System.out.println()은 kwrite(1,.......)의 함수와 매핑이 가능합니다.
System.out.println()은 표준출력(STDOUT, FD값 1)으로 "Hello World !!!!"를 출력하는 것이므로 kwrite의 첫번째 인자인 1 이 FD(File Descriptor)를 의미하며 출력 값이 "nullHello World !!!!" 인 것을 알 수 있습니다.
또한 open()함수를 통해 "aaa.txt" 파일을 생성하는 것을 알 수 있으며, fstatx()를 통해 해당 FD에 대한 정보를 획득합니다. 그리고 해당 FD로 kwrite()를 수행합니다.
CPU를 얼마나 효율적으로 사용할 수 있을까에 대한 정리입니다.
성능을 측정하는데 있어서 CPU 사용률은 그 측정의 기본이 됩니다. H/W는 CPU / Memory를 기준으로 측정하지만 일반적으로 좀 더 제한적인 CPU를 얼마나 잘 사용하느냐에 따라 이 시스템이 잘 짜여졌는지를 판단하기 때문입니다. 여기서 시스템은 OS / WAS / Web / Application / DB등을 포함한 인프라 아키텍처 전체를 의미합니다.
예를 들어 성능이 100인 시스템이 있다. 이는 성능이 50인 시스템보다 잘 짜여진 시스템이라고 할 수 있을까를 생각해 본다면 항상 그렇지는 않다고 대답하고 싶습니다. (물론 동일 시스템이라면 100이 잘짜여진 시스템입니다.)
성능이 100인 시스템은 조회성 업무가 주를 이루며 O/S의 전체 CPU 50% 미만일 때 WAS는 Thread Hang 직전에 놓이게 됩니다.
'② 성능 최적화, 트러블 슈팅 > ⓟ Performance Tuning' 카테고리의 다른 글
[GC] Log 분석 가이드 (IBM 계열 JDK) (0) | 2018.07.13 |
---|---|
[GC] Log 분석 가이드 (HotSpot 계열 JDK) (0) | 2018.07.13 |
[Performance Tuning] JMeter 성능 측정 툴 활용 (0) | 2018.06.03 |
[Performance Tuning] WAS Thread 수와 Instance 수 산정 방법 (1) | 2018.03.26 |
[Performance Tuning] 다양한 성능 저하 현상 분석 (0) | 2018.03.26 |
- Total
- Today
- Yesterday
- aws
- kubernetes
- 아키텍처
- Docker
- openstack token issue
- apache
- 쿠버네티스
- JEUS6
- TA
- 마이크로서비스 아키텍처
- git
- API Gateway
- JBoss
- aa
- Da
- nodejs
- k8s
- SWA
- wildfly
- Architecture
- 오픈스택
- 마이크로서비스
- jeus
- node.js
- MSA
- OpenStack
- SA
- openstack tenant
- webtob
- JEUS7
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |