Linux에서 성능 문제 해결 및 병목 현상 격리
적용 대상: ✔️ Linux VM
성능 문제 및 병목 현상
서로 다른 운영 체제 및 애플리케이션에서 성능 문제가 발생하는 경우 각 사례에는 문제 해결을 위한 고유한 접근 방식이 필요합니다. CPU, 메모리, 네트워킹 및 입력/출력(I/O)은 문제가 발생할 수 있는 주요 영역입니다. 이러한 각 영역은 서로 다른 증상을 나타내며(때로는 동시에) 다른 진단과 솔루션이 필요합니다.
성능 문제는 애플리케이션 또는 설정의 잘못된 구성으로 인해 발생할 수 있습니다. 예를 들어 올바르게 구성되지 않은 캐싱 계층이 있는 웹 애플리케이션이 있습니다. 이 경우 캐시에서 제공되는 대신 원본 서버로 다시 흐르는 더 많은 요청이 트리거됩니다.
또 다른 예에서는 MySQL 또는 MariaDB 데이터베이스의 다시 실행 로그가 운영 체제(OS) 디스크 또는 데이터베이스 요구 사항을 충족하지 않는 디스크에 있습니다. 이 시나리오에서는 리소스에 대한 경쟁과 더 높은 응답 시간(대기 시간)으로 인해 TPS(초당 트랜잭션 수)가 줄어들 수 있습니다.
이 문제를 완전히 이해하면 스택(CPU, 메모리, 네트워킹, I/O)에서 확인할 위치를 더 잘 식별할 수 있습니다. 성능 문제를 해결하려면 변경한 후 메트릭을 비교하고 전체 성능이 개선되었는지 여부를 평가할 수 있는 기준을 설정해야 합니다.
VM(가상 머신) 성능 문제 해결은 물리적 시스템의 성능 문제를 해결하는 것과 다르지 않습니다. 시스템에서 병목 현상을 일으키는 리소스 또는 구성 요소를 결정하는 것입니다.
병목 현상이 항상 존재한다는 것을 이해하는 것이 중요합니다. 성능 문제 해결은 병목 현상이 발생하는 위치와 덜 불쾌한 리소스로 이동하는 방법을 이해하는 것입니다.
이 가이드는 Linux 환경의 Azure Virtual Machines에서 성능 문제를 검색하고 해결하는 데 도움이 됩니다.
성능 포인터 가져오기
리소스 제약 조건이 있는지 여부를 확인하거나 거부하는 성능 포인터를 가져올 수 있습니다.
조사되는 리소스에 따라 많은 도구가 해당 리소스와 관련된 데이터를 가져오는 데 도움이 될 수 있습니다. 다음 표에는 주 리소스에 대한 예제가 포함되어 있습니다.
| 리소스 | 도구 |
|---|---|
| CPU | top, htop, mpstat, pidstatvmstat |
| 디스크 | iostat, , iotopvmstat |
| 네트워크 | ip, , vnstatiperf3 |
| 메모리 | free, , topvmstat |
다음 섹션에서는 기본 리소스를 찾는 데 사용할 수 있는 포인터 및 도구에 대해 설명합니다.
CPU 리소스
CPU의 특정 백분율이 사용되거나 사용되지 않습니다. 마찬가지로 프로세스는 CPU에서 시간을 소비하거나(예: 80% usr 사용량) 그렇지 않습니다(예: 80%의 유휴 상태). CPU 사용량을 확인하는 주요 도구는 .입니다 top.
도구는 top 기본적으로 대화형 모드에서 실행됩니다. 1초마다 새로 고쳐지고 CPU 사용량별로 정렬된 프로세스를 표시합니다.
[root@rhel78 ~]$ top
top - 19:02:00 up 2:07, 2 users, load average: 1.04, 0.97, 0.96
Tasks: 191 total, 3 running, 188 sleeping, 0 stopped, 0 zombie
%Cpu(s): 29.2 us, 22.0 sy, 0.0 ni, 48.5 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 7990204 total, 6550032 free, 434112 used, 1006060 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7243640 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd
1680 root 20 0 410268 38596 5644 S 3.0 0.5 2:15.10 python
772 root 20 0 90568 3240 2316 R 0.3 0.0 0:08.11 rngd
1472 root 20 0 222764 6920 4112 S 0.3 0.1 0:00.55 rsyslogd
10395 theuser 20 0 162124 2300 1548 R 0.3 0.0 0:11.93 top
1 root 20 0 128404 6960 4148 S 0.0 0.1 0:04.97 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.56 ksoftirqd/0
7 root rt 0 0 0 0 S 0.0 0.0 0:00.07 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.0 0.0 0:06.00 rcu_sched
10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 lru-add-drain
11 root rt 0 0 0 0 S 0.0 0.0 0:00.05 watchdog/0
12 root rt 0 0 0 0 S 0.0 0.0 0:00.04 watchdog/1
13 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/1
14 root 20 0 0 0 0 S 0.0 0.0 0:00.21 ksoftirqd/1
16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
18 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
19 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd
21 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kintegrityd
이제 해당 출력의 dd 프로세스 줄을 확인합니다.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd
프로세스가 CPU의 dd 99.7%를 사용하는 것을 볼 수 있습니다.
참고 항목
1을 선택하여 도구에서
topCPU당 사용량을 표시할 수 있습니다.이 도구는
top프로세스가 다중 스레드되고 둘 이상의 CPU에 걸쳐 있는 경우 총 사용량이 100% 이상 표시됩니다.
또 다른 유용한 참조는 부하 평균입니다. 부하 평균은 1분, 5분 및 15분 간격으로 평균 시스템 부하를 표시합니다. 이 값은 시스템의 부하 수준을 나타냅니다. 이 값 해석은 사용 가능한 CPU 수에 따라 달라집니다. 예를 들어 부하 평균이 1 CPU 시스템에서 2이면 시스템이 너무 로드되어 프로세스가 큐에 대기하기 시작합니다. 4개 CPU 시스템에 부하 평균이 2인 경우 전체 CPU 사용량은 약 50%입니다.
참고 항목
명령을 실행 nproc 하여 CPU 수를 빠르게 가져올 수 있습니다.
이전 예제에서 부하 평균은 1.04입니다. 이는 CPU 사용량이 약 50%인 2개 CPU 시스템입니다. 유휴 CPU 값이 48.5%인 경우 이 결과를 확인할 수 있습니다. 명령 출력에서 top 유휴 CPU 값은 레이블 앞에 id 표시됩니다.
부하 평균을 시스템의 성능에 대한 빠른 개요로 사용합니다.
uptime 명령을 실행하여 부하 평균을 가져옵니다.
디스크(I/O) 리소스
I/O 성능 문제를 조사할 때 다음 용어는 문제가 발생하는 위치를 이해하는 데 도움이 됩니다.
| 용어 | 설명 |
|---|---|
| IO 크기 | 트랜잭션당 처리되는 데이터의 양(일반적으로 바이트 단위로 정의됨)입니다. |
| IO 스레드 | 스토리지 디바이스와 상호 작용하는 프로세스 수입니다. 이 값은 애플리케이션에 따라 달라집니다. |
| 블록 크기 | 지원 블록 디바이스에서 정의한 I/O 크기입니다. |
| 섹터 크기 | 디스크에 있는 각 섹터의 크기입니다. 이 값은 일반적으로 512바이트입니다. |
| IOPS | 초당 입력 출력 작업 수입니다. |
| 대기 시간 | I/O 작업이 완료되는 데 걸리는 시간입니다. 이 값은 일반적으로 밀리초(밀리초)로 측정됩니다. |
| 처리량 | 특정 시간 동안 전송되는 데이터 양에 대한 함수입니다. 이 값은 일반적으로 초당 메가바이트(MB/s)로 정의됩니다. |
IOPS
IOPS(초당 입력 출력 작업 )는 특정 시간(이 경우 초)에 걸쳐 측정되는 입력 및 출력(I/O) 작업 수의 함수입니다. I/O 작업은 읽기 또는 쓰기일 수 있습니다. 삭제 또는 삭제는 스토리지 시스템에 대한 작업으로 계산될 수도 있습니다. 각 작업에는 I/O 크기와 동일하게 해당하는 할당 단위가 있습니다.
I/O 크기는 일반적으로 애플리케이션 수준에서 트랜잭션당 쓰거나 읽은 데이터의 양으로 정의됩니다. 일반적으로 사용되는 I/O 크기는 4K입니다. 그러나 더 많은 스레드를 포함하는 작은 I/O 크기는 더 높은 IOPS 값을 생성합니다. 크기가 작기 때문에 각 트랜잭션을 비교적 빠르게 완료할 수 있으므로 I/O가 작을수록 동일한 시간에 더 많은 트랜잭션을 완료할 수 있습니다.
반대로 스레드 수가 동일하지만 더 큰 I/O를 사용한다고 가정합니다. 각 트랜잭션을 완료하는 데 시간이 오래 걸리기 때문에 IOPS가 감소합니다. 그러나 처리량이 증가합니다.
다음 예시를 참조하세요.
1,000 IOPS는 초당 1,000개의 작업이 완료된다는 것을 의미합니다. 각 작업에는 약 1밀리초가 걸립니다. (1초에 1,000밀리초가 있습니다.) 이론적으로 각 트랜잭션에는 완료할 약 1밀리초 또는 약 1밀리초의 대기 시간이 있습니다.
IOSize 값과 IOPS를 알고 있으면 IOSize를 IOPS에 곱하여 처리량을 계산할 수 있습니다.
예시:
4K IOSize에서 1,000 IOPS = 4,000KB/s 또는 4MB/s(정확하게 3.9MB/s)
1M IOSize에서 1,000 IOPS = 1,000MB/s 또는 1GB/s(정확하게 976MB/s)
수식에 친숙한 버전은 다음과 같이 작성할 수 있습니다.
IOPS * IOSize = IOSize/s (Throughput)
처리량
IOPS와 달리 처리량은 시간에 따른 데이터 양에 대한 함수입니다. 즉, 각 초 동안 특정 양의 데이터가 작성되거나 읽혀집니다. 이 속도는 데이터/><시간> 또는 초당 메가바이트(MB/s)로 측정<됩니다.
처리량 및 IOSize 값을 알고 있는 경우 처리량을 IOSize로 나누어 IOPS를 계산할 수 있습니다. 단위를 가장 작은 주석으로 정규화해야 합니다. 예를 들어 IOSize가 Kb(킬로바이트)로 정의된 경우 처리량을 변환해야 합니다.
수식 형식은 다음과 같이 작성됩니다.
Throughput / IOSize = IOPS
이 수식을 컨텍스트에 넣려면 IOSize 4K에서 10MB/s의 처리량을 고려합니다. 수식에 값을 입력하면 결과는 10,240/4=2,560 IOPS입니다.
참고 항목
10MB는 정확히 10,240KB와 같습니다.
대기 시간
대기 시간은 각 작업이 완료되는 데 걸리는 평균 시간의 측정값입니다. IOPS 및 대기 시간은 두 개념이 모두 시간 함수이기 때문에 관련됩니다. 예를 들어 100 IOPS에서 각 작업을 완료하는 데 약 10ms가 걸립니다. 그러나 동일한 양의 데이터를 더 낮은 IOPS에서 더 빠르게 가져올 수 있습니다. 대기 시간을 검색 시간으로도 알려져 있습니다.
iostat 출력 이해
sysstat 패키지의 일부로 이 iostat 도구는 디스크 성능 및 사용 메트릭에 대한 인사이트를 제공합니다. iostat 는 디스크 하위 시스템에 관련된 병목 상태를 식별하는 데 도움이 될 수 있습니다.
간단한 명령으로 실행할 iostat 수 있습니다. 기본 구문은 다음과 같습니다.
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
매개 변수는 정보가 iostat 제공하는 것을 결정합니다. 명령 매개 변수 iostat 가 없으면 기본 세부 정보가 표시됩니다.
[host@rhel76 ~]$ iostat
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76) 08/05/2019 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
41.06 0.00 30.47 21.00 0.00 7.47
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 182.77 5072.69 1066.64 226090 47540
sdd 2.04 42.56 22.98 1897 1024
sdb 12.61 229.23 96065.51 10217 4281640
sdc 2.56 46.16 22.98 2057 1024
md0 2.67 73.60 45.95 3280 2048
기본적으로 iostat 각 디바이스에 대해 최소 데이터가 제공되지만 모든 기존 블록 디바이스에 대한 데이터를 표시합니다. 확장 데이터(예: 처리량, IOPS, 큐 크기 및 대기 시간)를 제공하여 문제를 식별하는 데 도움이 되는 매개 변수를 사용할 수 있습니다.
트리거를 지정하여 실행 iostat 합니다.
sudo iostat -dxctm 1
결과를 추가로 확장 iostat 하려면 다음 매개 변수를 사용합니다.
| 매개 변수 | 작업 |
|---|---|
-d |
디바이스 사용률 보고서를 표시합니다. |
-x |
확장된 통계를 표시합니다. 이 매개 변수는 IOPS, 대기 시간 및 큐 크기를 제공하기 때문에 중요합니다. |
-c |
CPU 사용률 보고서를 표시합니다. |
-t |
표시되는 각 보고서의 시간을 인쇄합니다. 이 매개 변수는 장기 실행에 유용합니다. |
-m |
통계를 사람이 읽을 수 있는 형식인 초당 메가바이트 단위로 표시합니다. |
명령의 숫자는 1 1초마다 새로 고치도록 지시합니다 iostat . 새로 고침을 중지하려면 Ctrl+C를 선택합니다.
추가 매개 변수를 포함하는 경우 출력은 다음 텍스트와 유사합니다.
[host@rhel76 ~]$ iostat -dxctm 1
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76) 08/05/2019 _x86_64_ (1 CPU)
08/05/2019 07:03:36 PM
avg-cpu: %user %nice %system %iowait %steal %idle
3.09 0.00 2.28 1.50 0.00 93.14
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.02 0.52 9.66 2.46 0.31 0.10 70.79 0.27 23.97 6.68 91.77 2.94 3.56
sdd 0.00 0.00 0.12 0.00 0.00 0.00 64.20 0.00 6.15 6.01 12.50 4.44 0.05
sdb 0.00 22.90 0.47 0.45 0.01 5.74 12775.08 0.17 183.10 8.57 367.68 8.01 0.74
sdc 0.00 0.00 0.15 0.00 0.00 0.00 54.06 0.00 6.46 6.24 14.67 5.64 0.09
md0 0.00 0.00 0.15 0.01 0.00 0.00 89.55 0.00 0.00 0.00 0.00 0.00 0.00
값 이해
출력의 iostat 기본 열은 다음 표에 나와 있습니다.
| 열 | 설명 |
|---|---|
r/s |
초당 읽기(IOPS) |
w/s |
초당 쓰기(IOPS) |
rMB/s |
초당 읽는 메가바이트(처리량) |
wMB/s |
초당 메가바이트 쓰기(처리량) |
avgrq-sz |
섹터의 평균 I/O 크기; I/O 크기를 바이트(I/O 크기)로 가져오기 위해 일반적으로 512바이트인 섹터 크기를 곱합니다. |
avgqu-sz |
평균 큐 크기(대기 중인 I/O 작업 수) |
await |
디바이스에서 제공하는 I/O의 평균 시간(밀리초) (대기 시간) |
r_await |
디바이스에서 제공하는 I/O의 평균 읽기 시간(밀리초) (대기 시간) |
w_await |
디바이스에서 제공하는 I/O의 평균 읽기 시간(밀리초) (대기 시간) |
제공된 iostat 데이터는 정보이지만 특정 열에 특정 데이터가 있다고 해서 문제가 있는 것은 아닙니다. iostat 가능한 병목 현상은 항상 데이터를 캡처하고 분석해야 합니다. 대기 시간이 높으면 디스크가 채도 지점에 도달하고 있음을 나타낼 수 있습니다.
참고 항목
이 pidstat -d 명령을 사용하여 프로세스당 I/O 통계를 볼 수 있습니다.
네트워크 리소스
네트워크는 낮은 대역폭과 높은 대기 시간의 두 가지 주요 병목 상태를 경험할 수 있습니다.
대역폭 세부 정보를 라이브 캡처하는 데 사용할 vnstat 수 있습니다. 그러나 vnstat 모든 배포에서 사용할 수 있는 것은 아닙니다. 널리 사용 가능한 iptraf-ng 도구는 실시간 인터페이스 트래픽을 볼 수 있는 또 다른 옵션입니다.
네트워크 대기 시간
두 가지 시스템의 네트워크 대기 시간은 ICMP(인터넷 제어 메시지 프로토콜)의 간단한 ping 명령을 사용하여 확인할 수 있습니다.
[root@rhel78 ~]# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=5.33 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=5.24 ms
^C
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 5.240/5.291/5.339/0.035 ms
ping 작업을 중지하려면 Ctrl+C를 선택합니다.
네트워크 대역폭
와 같은 iperf3도구를 사용하여 네트워크 대역폭을 확인할 수 있습니다. 이 도구는 iperf3 서버에서 플래그를 지정하여 -s 애플리케이션이 시작되는 서버/클라이언트 모델에서 작동합니다. 그런 다음 클라이언트는 플래그와 함께 -c 서버의 IP 주소 또는 FQDN(정규화된 도메인 이름)을 지정하여 서버에 연결합니다. 다음 코드 조각은 서버 및 클라이언트에서 iperf3 도구를 사용하는 방법을 보여줍니다.
서버
root@ubnt:~# iperf3 -s ----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------클라이언트
root@ubnt2:~# iperf3 -c 10.1.0.4 Connecting to host 10.1.0.4, port 5201 [ 5] local 10.1.0.4 port 60134 connected to 10.1.0.4 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 5.78 GBytes 49.6 Gbits/sec 0 1.25 MBytes [ 5] 1.00-2.00 sec 5.81 GBytes 49.9 Gbits/sec 0 1.25 MBytes [ 5] 2.00-3.00 sec 5.72 GBytes 49.1 Gbits/sec 0 1.25 MBytes [ 5] 3.00-4.00 sec 5.76 GBytes 49.5 Gbits/sec 0 1.25 MBytes [ 5] 4.00-5.00 sec 5.72 GBytes 49.1 Gbits/sec 0 1.25 MBytes [ 5] 5.00-6.00 sec 5.64 GBytes 48.5 Gbits/sec 0 1.25 MBytes [ 5] 6.00-7.00 sec 5.74 GBytes 49.3 Gbits/sec 0 1.31 MBytes [ 5] 7.00-8.00 sec 5.75 GBytes 49.4 Gbits/sec 0 1.31 MBytes [ 5] 8.00-9.00 sec 5.75 GBytes 49.4 Gbits/sec 0 1.31 MBytes [ 5] 9.00-10.00 sec 5.71 GBytes 49.1 Gbits/sec 0 1.31 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 57.4 GBytes 49.3 Gbits/sec 0 sender [ 5] 0.00-10.04 sec 57.4 GBytes 49.1 Gbits/sec receiver iperf Done.
클라이언트에 대한 몇 가지 일반적인 iperf3 매개 변수는 다음 표에 나와 있습니다.
| 매개 변수 | 설명 |
|---|---|
-P |
실행할 병렬 클라이언트 스트림 수를 지정합니다. |
-R |
트래픽을 반대로 합니다. 기본적으로 클라이언트는 서버에 데이터를 보냅니다. |
--bidir |
업로드 및 다운로드를 모두 테스트합니다. |
메모리 리소스
메모리는 애플리케이션이 메모리의 일부를 사용할 수도 있고 사용하지 않을 수도 있기 때문에 확인할 또 다른 문제 해결 리소스입니다. 다음과 같은 free top 도구를 사용하여 전체 메모리 사용률을 검토하고 다양한 프로세스가 소비하는 메모리 양을 확인할 수 있습니다.
[root@rhel78 ~]# free -m
total used free shared buff/cache available
Mem: 7802 435 5250 9 2117 7051
Swap: 0 0 0
Linux 시스템에서는 일반적으로 99%의 메모리 사용률을 볼 수 있습니다. 출력에는 free 이름이 지정된 buff/cache열이 있습니다. Linux 커널은 사용 가능한(사용되지 않는) 메모리를 사용하여 더 나은 응답 시간을 위해 I/O 요청을 캐시합니다. 이 프로세스를 페이지 캐시라고 합니다. 메모리 부족(메모리가 부족한 시나리오) 동안 커널은 애플리케이션에서 해당 메모리를 사용할 수 있도록 페이지 캐시에 사용되는 메모리를 반환합니다.
출력에서 free 사용 가능한 열은 프로세스에서 사용할 수 있는 메모리 양을 나타냅니다. 이 값은 버프/캐시 메모리와 사용 가능한 메모리의 양을 추가하여 계산됩니다.
메모리 사용률별로 프로세스를 정렬하도록 명령을 구성할 top 수 있습니다. 기본적으로 top CPU 백분율(%)을 기준으로 정렬합니다. 메모리 사용률(%)을 기준으로 정렬하려면 실행할 때 Shift+M을 선택합니다.top 다음 텍스트는 명령의 출력을 top 보여줍니다.
[root@rhel78 ~]# top
top - 22:40:15 up 5:45, 2 users, load average: 0.08, 0.08, 0.06
Tasks: 194 total, 2 running, 192 sleeping, 0 stopped, 0 zombie
%Cpu(s): 12.3 us, 41.8 sy, 0.0 ni, 45.4 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 st
KiB Mem : 7990204 total, 155460 free, 5996980 used, 1837764 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1671420 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
45283 root 20 0 5655348 5.3g 512 R 99.7 69.4 0:03.71 tail
3124 omsagent 20 0 415316 54112 5556 S 0.0 0.7 0:30.16 omsagent
1680 root 20 0 413500 41552 5644 S 3.0 0.5 6:14.96 python
[...]
열은 RES 상주 메모리를 나타냅니다. 이는 실제 프로세스 사용량을 나타냅니다. 이 도구는 top KB(킬로 free 바이트)와 비슷한 출력을 제공합니다.
애플리케이션 에서 메모리 누수 발생 시 메모리 사용률이 예상보다 많이 증가할 수 있습니다. 메모리 누수 시나리오에서 애플리케이션은 더 이상 사용되지 않는 메모리 페이지를 해제할 수 없습니다.
다음은 상위 메모리 사용 프로세스를 보는 데 사용되는 다른 명령입니다.
ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
다음 텍스트는 명령의 예제 출력을 보여줍니다.
[root@rhel78 ~]# ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
PID COMMAND USER COMMAND %CPU %MEM
45922 tail root tail -f /dev/zero 82.7 61.6
[...]
다음 샘플 출력과 같이 OOM(메모리 부족) 킬 이벤트에서 메모리 압력을 식별할 수 있습니다.
Jun 19 22:42:14 rhel78 kernel: Out of memory: Kill process 45465 (tail) score 902 or sacrifice child
Jun 19 22:42:14 rhel78 kernel: Killed process 45465 (tail), UID 0, total-vm:7582132kB, anon-rss:7420324kB, file-rss:0kB, shmem-rss:0kB
RAM(실제 메모리)과 SWAP(디스크)를 모두 사용한 후에 OOM이 호출됩니다.
참고 항목
이 pidstat -r 명령을 사용하여 프로세스별 메모리 통계를 볼 수 있습니다.
리소스 제약 조건이 있는지 확인
이전 표시기를 사용하고 현재 구성을 파악하여 제약 조건이 있는지 여부를 확인할 수 있습니다. 제약 조건은 기존 구성과 비교할 수 있습니다.
디스크 제약 조건의 예는 다음과 같습니다.
D2s_v3 VM은 48MB/s의 캐시되지 않은 처리량을 수행할 수 있습니다. 이 VM에 200MB/s를 사용할 수 있는 P30 디스크가 연결됩니다. 애플리케이션에는 최소 100MB/s가 필요합니다.
이 예제에서 리소스 제한은 전체 VM의 처리량입니다. 애플리케이션의 요구 사항과 디스크 또는 VM 구성이 제공할 수 있는 요구 사항은 리소스를 제한했음을 나타냅니다.
애플리케이션에 measurement1><리소스>가< 필요하고 리소스>에 대한< 현재 구성이 측정값2>만 <제공할 수 있는 경우 이 요구 사항은 제한 요인이 될 수 있습니다.
제한 리소스 정의
리소스가 현재 구성의 제한 요소로 결정되면 변경될 수 있는 방법과 리소스가 워크로드에 미치는 영향을 식별합니다. 비용 절감 조치로 인해 리소스를 제한할 수 있는 상황이 있지만 애플리케이션은 여전히 문제 없이 병목 상태를 처리할 수 있습니다.
예시:
애플리케이션에 RAM(리소스)의 128GB(측정)가 필요하고 RAM(리소스)에 대한 현재 구성이 64GB(측정)만 제공할 수 있는 경우 이 요구 사항은 제한 요인이 될 수 있습니다.
이제 제한 리소스를 정의하고 해당 리소스에 따라 작업을 수행할 수 있습니다. 동일한 개념이 다른 리소스에 적용됩니다.
이러한 제한 리소스가 비용 절감 조치로 예상되는 경우 애플리케이션은 병목 상태를 해결해야 합니다. 그러나 동일한 비용 절감 조치가 있고 애플리케이션이 리소스 부족을 쉽게 처리할 수 없는 경우 이 구성으로 인해 문제가 발생할 수 있습니다.
가져온 데이터에 따라 변경
성능을 위한 디자인은 문제를 해결하는 것이 아니라 다음 병목 현상이 발생할 수 있는 위치와 해결 방법을 이해하는 것입니다. 병목 현상은 항상 존재하며 디자인의 다른 위치로만 이동할 수 있습니다.
예를 들어 애플리케이션이 디스크 성능에 의해 제한되는 경우 더 많은 처리량을 허용하도록 디스크 크기를 늘릴 수 있습니다. 그러나 네트워크는 다음 병목 상태가 됩니다. 리소스가 제한되어 있으므로 이상적인 구성은 없으며 정기적으로 문제를 해결해야 합니다.
이전 단계에서 데이터를 가져와서 측정 가능한 실제 데이터를 기반으로 변경할 수 있습니다. 또한 이러한 변경 내용을 이전에 측정한 기준과 비교하여 실질적인 차이가 있는지 확인할 수 있습니다.
다음 예시를 참조하세요.
애플리케이션이 실행되는 동안 기준을 얻었을 때 시스템에 두 CPU 구성에서 100% CPU 사용량이 일정한 것으로 확인되었습니다. 부하 평균이 4인 것을 확인했습니다. 이는 시스템이 요청을 대기하고 있음을 의미합니다. 8개 CPU 시스템을 변경하면 CPU 사용량이 25%로 감소하고 동일한 부하가 적용되었을 때 부하 평균이 2로 감소했습니다.
이 예제에서는 가져온 결과를 변경된 리소스와 비교할 때 측정 가능한 차이가 있습니다. 변경 전에 명확한 리소스 제약 조건이 있었습니다. 그러나 변경 후 부하를 늘릴 수 있는 충분한 리소스가 있습니다.
온-프레미스에서 클라우드로 마이그레이션
온-프레미스 설정에서 클라우드 컴퓨팅으로의 마이그레이션은 몇 가지 성능 차이의 영향을 받을 수 있습니다.
CPU
아키텍처에 따라 온-프레미스 설정은 클록 속도와 캐시가 더 큰 CPU를 실행할 수 있습니다. 그 결과 처리 시간이 줄어들고 IPC(주기별 지침)가 늘어나게 됩니다. 마이그레이션 작업을 수행할 때 CPU 모델 및 메트릭의 차이점을 이해하는 것이 중요합니다. 이 경우 CPU 수 간의 일대일 관계만으로는 충분하지 않을 수 있습니다.
예시:
3.7GHz에서 실행되는 4개의 CPU가 있는 온-프레미스 시스템에는 처리에 사용할 수 있는 총 14.8GHz가 있습니다. 2.1GHz CPU에서 지원되는 D4s_v3 VM을 사용하여 CPU 수에 해당하는 값을 만드는 경우 마이그레이션된 VM은 8.1GHz를 처리할 수 있습니다. 이는 성능이 약 44% 감소하는 것을 나타냅니다.
디스크
Azure의 디스크 성능은 디스크의 유형 및 크기(크기, IOPS 및 처리량에 대한 유연성을 제공하는 Ultra Disk 제외)에 의해 정의됩니다. 디스크 크기는 IOPS 및 처리량 제한을 정의합니다.
대기 시간은 디스크 크기 대신 디스크 유형에 종속된 메트릭입니다. 대부분의 온-프레미스 스토리지 솔루션은 DRAM 캐시가 있는 디스크 배열입니다. 이 유형의 캐시는 하위 밀리초(약 200 마이크로초) 대기 시간과 높은 읽기/쓰기 처리량(IOPS)을 제공합니다.
평균 Azure 대기 시간은 다음 표에 나와 있습니다.
| 디스크 유형 | 대기 시간 |
|---|---|
| Ultra disk/Premium SSD v2 | 3자리 μs(마이크로초) |
| 프리미엄 SSD/표준 SSD | 한 자리 ms(밀리초) |
| 표준 HDD | 두 자리 ms(밀리초) |
참고 항목
그렇지 않으면 대기 시간이 100밀리초 이상으로 급증할 수 있으므로 IOPS 또는 대역폭 제한에 도달하면 디스크가 제한됩니다.
온-프레미스(종종 밀리초 미만)와 프리미엄 SSD(한 자리 밀리초) 간의 대기 시간 차이는 제한 요소가 됩니다. 스토리지 제품 간의 대기 시간 차이를 확인하고 애플리케이션의 요구 사항에 더 적합한 제품을 선택합니다.
네트워크
대부분의 온-프레미스 네트워크 설정은 10Gbps 링크를 사용합니다. Azure에서 네트워크 대역폭은 VM(가상 머신)의 크기로 직접 정의됩니다. 일부 네트워크 대역폭은 40Gbps를 초과할 수 있습니다. 애플리케이션 요구 사항에 충분한 대역폭이 있는 크기를 선택해야 합니다. 대부분의 경우 제한 요소는 네트워크 대신 VM 또는 디스크의 처리량 제한입니다.
메모리
현재 구성된 것에 충분한 RAM이 있는 VM 크기를 선택합니다.
성능 진단(PerfInsights)
PerfInsights는 VM 성능 문제에 대한 Azure 지원 권장되는 도구입니다. CPU, 메모리 및 I/O에 대한 모범 사례 및 전용 분석 탭을 포함하도록 설계되었습니다. Azure Portal 또는 VM 내에서 OnDemand를 실행한 다음 Azure 지원 팀과 데이터를 공유할 수 있습니다.
PerfInsights 실행
PerfInsights는 Windows 및 Linux OS 모두에서 사용할 수 있습니다. Linux 배포판이 Linux용 성능 진단에 대해 지원되는 배포 목록에 있는지 확인합니다.
Azure Portal을 통해 보고서 실행 및 분석
PerfInsights가 Azure Portal을 통해 설치되면 소프트웨어는 VM에 확장을 설치합니다. 사용자는 VM 블레이드의 확장으로 직접 이동하여 성능 진단 옵션을 선택하여 PerfInsights를 확장으로 설치할 수도 있습니다.
Azure Portal 옵션 1
VM 블레이드를 찾아보고 성능 진단 옵션을 선택합니다. 선택한 VM에 옵션(확장 사용)을 설치하라는 메시지가 표시됩니다.
Azure Portal 옵션 2
VM 블레이드에서 문제 진단 및 해결 탭으로 이동하고 VM 성능 문제에서 문제 해결 링크를 찾습니다.
PerfInsights 보고서에서 찾을 내용
PerfInsights 보고서를 실행한 후 콘텐츠의 위치는 보고서가 Azure Portal을 통해 실행되었는지 또는 실행 파일로 실행되었는지에 따라 달라집니다. 두 옵션 중 하나에서 생성된 로그 폴더에 액세스하거나(Azure Portal에 있는 경우) 분석을 위해 로컬로 다운로드합니다.
Azure Portal을 통해 실행
PerfInsights 보고서를 엽니다. 결과 탭은 리소스 사용량 측면에서 이상값을 기록합니다. 특정 리소스 사용으로 인해 성능이 느린 인스턴스가 있는 경우 결과 탭은 각 결과를 높은 영향 또는 중간 영향으로 분류합니다.
예를 들어 다음 보고서에서 스토리지와 관련된 중간 영향 결과가 검색되었으며 해당 권장 사항이 표시됩니다. Findings 이벤트를 확장하면 몇 가지 주요 세부 정보가 표시됩니다.
Linux OS의 PerfInsights에 대한 자세한 내용은 Microsoft Azure에서 PerfInsights Linux를 사용하는 방법을 검토하세요.
자세한 정보
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.