| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 | 31 |
- script
- java
- 리눅스
- PostgreSQL
- 설정
- 3.0
- 데이터베이스
- node
- Windows
- JS
- 윈도우
- 파이썬
- hamonikr
- 자바스크립트
- DATABASE
- Atlassian
- 하모니카
- install
- 노드
- Linux
- python
- ubuntu
- javascript
- DB
- postgres
- 설치
- 스크립트
- 아틀라시안
- 자바
- 우분투
- Today
- Total
LukeHan 의 잡다한 기술 블로그
리눅스 서버 60초안에 상황파악하기 본문
성능 문제가있는 Linux 서버에 로그인합니다. 첫 1 분 동안 무엇을 확인합니까?
Netflix에는 대규모 EC2 Linux 클라우드와 성능을 모니터링하고 조사 할 수있는 수많은 성능 분석 도구가 있습니다. 여기에는 클라우드 전체 모니터링을위한 Atlas 및 주문형 인스턴스 분석을위한 Vector 가 포함됩니다. 이러한 도구는 대부분의 문제를 해결하는 데 도움이되지만 인스턴스에 로그인하여 표준 Linux 성능 도구를 실행해야하는 경우가 있습니다.
처음 60 초 : 요약
이 게시물에서 Netflix Performance Engineering 팀은 사용 가능한 표준 Linux 도구를 사용하여 명령 줄에서 처음 60 초 동안 최적화 된 성능 조사를 보여줍니다. 60 초 안에 다음 10 가지 명령을 실행하여 시스템 리소스 사용 및 프로세스 실행에 대한 높은 수준의 아이디어를 얻을 수 있습니다. 해석하기 쉬운 오류 및 채도 메트릭을 찾은 다음 리소스 사용률을 찾으십시오. 포화는 자원이 처리 할 수있는 것보다 더 많은로드를 갖는 곳이며 요청 큐 길이 또는 대기 시간으로 표시 될 수 있습니다.
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
이러한 명령 중 일부에는 sysstat 패키지가 설치되어 있어야합니다. 이 명령이 제공하는 메트릭은 성능 병목 현상을 찾기위한 방법론 인 USE 방법 중 일부를 완료하는 데 도움이됩니다 . 여기에는 모든 리소스 (CPU, 메모리, 디스크 등)의 사용률, 채도 및 오류 메트릭 확인이 포함됩니다. 또한 제거 과정에 따라 연구 대상이 좁아지고 조사를 따르도록 지시하기 때문에 자원을 확인하고 제거 할 때주의하십시오.
다음 섹션에서는 이러한 명령을 프로덕션 시스템의 예제와 함께 요약합니다. 이러한 도구에 대한 자세한 내용은 해당 매뉴얼 페이지를 참조하십시오.
1. uptime
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02로드 평균을 보는 빠른 방법으로, 실행하려는 작업 (프로세스) 수를 나타냅니다. Linux 시스템에서이 숫자에는 CPU에서 실행하려는 프로세스와 인터럽트 불가능한 I / O (일반적으로 디스크 I / O)로 차단 된 프로세스가 포함됩니다. 이는 리소스로드 (또는 수요)에 대한 높은 수준의 아이디어를 제공하지만 다른 도구 없이는 제대로 이해할 수 없습니다. 빨리 볼만한 가치가 있습니다.
3 개의 숫자는 1 분, 5 분 및 15 분 상수로 지수 적으로 감쇠 된 이동 합계 평균입니다. 세 개의 숫자는 시간이 지남에 따라 부하가 어떻게 변하는 지에 대한 아이디어를 제공합니다. 예를 들어, 문제점 서버를 점검하도록 요청했고 1 분 값이 15 분 값보다 훨씬 낮은 경우 너무 늦게 로그인하여 문제점을 놓쳤을 수 있습니다.
위의 예에서로드 평균은 15 분 값의 19에 비해 1 분 값의 30에 도달하는 최근 증가를 보여줍니다. 숫자가 크다는 것은 많은 것을 의미합니다. 아마도 CPU 수요; 이 순서에서 명령 3과 4 인 vmstat 또는 mpstat가 확인됩니다.
2. dmesg | tail
$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.마지막 10 개의 시스템 메시지가있는 경우 표시됩니다. 성능 문제를 일으킬 수있는 오류를 찾으십시오. 위의 예제에는 oom-killer와 TCP가 요청을 삭제하는 것이 포함됩니다.
이 단계를 놓치지 마십시오! dmesg는 항상 확인할 가치가 있습니다.
3. vmstat 1
$ vmstat 1
procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0
32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0
32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0
^C가상 메모리 통계 (virtual memory stat)의 약자 인 vmstat (8)는 일반적으로 사용 가능한 도구입니다 (수십 년 전에 BSD를 위해 처음 개발 된 도구). 각 줄에 주요 서버 통계 요약을 인쇄합니다.
vmstat는 1의 인수로 실행되어 1 초 요약을 인쇄합니다. 첫 번째 출력 행 (이 버전의 vmstat)에는 이전 초가 아닌 부팅 이후 평균을 표시하는 일부 열이 있습니다. 어떤 열이 어느 열인지 배우고 기억하지 않으려면 지금은 첫 번째 줄을 건너 뛰십시오.
확인할 열 :
- r : CPU에서 실행되고 회전을 기다리는 프로세스 수. 이것은 I / O를 포함하지 않기 때문에 CPU 포화를 결정하기 위해로드 평균보다 더 나은 신호를 제공합니다. 해석하려면 : CPU 수보다 큰 "r"값은 채도입니다.
- free : 킬로바이트 단위의 사용 가능한 메모리. 계산할 숫자가 너무 많으면 사용 가능한 메모리가 충분합니다. 명령 7에 포함 된 "free -m"명령은 사용 가능한 메모리의 상태를보다 잘 설명합니다.
- si, so : 스왑 인 및 스왑 아웃. 이것이 0이 아닌 경우 메모리가 부족한 것입니다.
- us, sy, id, wa, st : 모든 CPU에서 평균적으로 CPU 시간의 분석입니다. 사용자 시간, 시스템 시간 (커널), 유휴, I / O 대기 및 도난 시간 (다른 게스트 또는 게스트 자체의 격리 된 드라이버 도메인 인 Xen 사용)입니다.
CPU 시간 분석은 사용자 + 시스템 시간을 추가하여 CPU가 사용 중인지 확인합니다. 일정한 수준의 대기 I / O는 디스크 병목 현상을 나타냅니다. 대기중인 디스크 I / O를 기다리는 작업이 차단되므로 CPU가 유휴 상태입니다. 대기 I / O를 다른 형태의 CPU 유휴로 취급 할 수 있는데, 유휴 이유에 대한 단서를 제공합니다.
I / O 처리에는 시스템 시간이 필요합니다. 20 %가 넘는 높은 시스템 시간 평균은 더 탐색하기에 흥미로울 수 있습니다. 아마도 커널이 I / O를 비효율적으로 처리하고있을 것입니다.
위의 예에서 CPU 시간은 거의 전적으로 사용자 수준이며 응용 프로그램 수준 사용을 가리 킵니다. CPU는 평균적으로 90 % 이상 활용됩니다. 이것이 반드시 문제는 아닙니다. "r"열을 사용하여 채도를 확인하십시오.
4. mpstat -P ALL 1
$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99
07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03
[...]이 명령은 불균형을 확인하는 데 사용할 수있는 CPU 당 CPU 시간 분석을 인쇄합니다. 단일 핫 CPU는 단일 스레드 응용 프로그램의 증거가 될 수 있습니다.
5. pidstat 1
$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java
07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat
07:41:03 PM UID PID %usr %system %guest %CPU CPU Command
07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave
07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java
07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java
07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass
07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat
^CPidstat는 프로세스 별 요약과 비슷하지만 화면을 지우지 않고 롤링 요약을 인쇄합니다. 이 기능은 시간이 지남에 따라 패턴을보고 조사한 기록에보고 (복사-붙여 넣기)를 기록하는 데 유용 할 수 있습니다.
위의 예제는 CPU 소비를 담당하는 두 개의 Java 프로세스를 식별합니다. % CPU 열은 모든 CPU의 총계입니다. 1591 %는 Java 프로세스가 거의 16 개의 CPU를 소비하고 있음을 보여줍니다.
6. iostat -xz 1
$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
73.96 0.00 3.73 0.03 0.06 22.21
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09
xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25
xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26
dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04
dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00
dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03
[...]
^C이는 적용된 워크로드와 결과 성능 모두에서 블록 장치 (디스크)를 이해하는 데 유용한 도구입니다. 찾다:
- r / s, w / s, rkB / s, wkB / s : 장치에 전달 된 읽기, 쓰기, 읽기 바이트 및 초당 쓰기 바이트입니다. 워크로드 특성 분석에 사용하십시오. 과도한 부하가 적용되어 성능 문제가 발생할 수 있습니다.
- await : I / O의 평균 시간 (밀리 초)입니다. 대기 시간과 서비스 시간이 모두 포함되어 있기 때문에 애플리케이션이 겪는 시간입니다. 예상 평균 시간보다 큰 시간은 장치 포화 또는 장치 문제의 지표 일 수 있습니다.
- avgqu-sz : 장치에 발행 된 평균 요청 수입니다. 1보다 큰 값은 포화의 증거가 될 수 있습니다 (단, 디바이스는 일반적으로 요청에서 병렬로 작동 할 수 있지만, 특히 여러 백엔드 디스크를 전면에 배치하는 가상 디바이스 일 수는 있음).
- % util : 장치 사용률. 이것은 실제로 사용량이 많으며 초당 장치가 작업을 수행 한 시간을 보여줍니다. 60 %보다 큰 값은 일반적으로 장치에 따라 다르지만 성능이 저하됩니다 (대기 중에 표시). 100 %에 가까운 값은 일반적으로 채도를 나타냅니다.
스토리지 장치가 많은 백엔드 디스크를 향한 논리 디스크 장치 인 경우 100 % 사용률은 일부 I / O가 100 % 처리되고 있음을 의미 할 수 있지만 백엔드 디스크는 포화 상태가 아닐 수 있습니다. 훨씬 더 많은 작업을 처리 할 수 있습니다.
성능이 떨어지는 디스크 I / O가 반드시 응용 프로그램 문제는 아니라는 점에 유의하십시오. 대부분의 기술은 일반적으로 I / O를 비동기 적으로 수행하는 데 사용되므로 응용 프로그램이 대기 시간을 직접 차단하지 않으며 (예 : 읽기를위한 미리 읽기, 쓰기를위한 버퍼링)
7. free -m
$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0오른쪽 두 열에는 다음이 표시됩니다.
- buffers : 버퍼 캐시의 경우 블록 장치 I / O에 사용됩니다.
- cached : 파일 시스템에서 사용되는 페이지 캐시 용.
크기가 거의 0이 아닌지 확인하여 디스크 I / O가 증가하고 (iostat 사용 확인) 성능이 저하 될 수 있습니다. 위의 예는 각각에 많은 MB가있는 것으로 보입니다.
“-/ + buffers / cache”는 사용 된 메모리와 사용 가능한 메모리에 대해 덜 혼란스러운 값을 제공합니다. Linux는 캐시에 사용 가능한 메모리를 사용하지만 응용 프로그램에 필요한 경우 신속하게 회수 할 수 있습니다. 따라서 캐시 된 메모리는이 행이 수행하는 사용 가능한 메모리 열에 포함되어야합니다. 이 혼란에 관한 웹 사이트 linuxatemyram 도 있습니다 .
ZFS에는 free -m 열에 제대로 반영되지 않는 자체 파일 시스템 캐시가 있기 때문에 일부 서비스에서와 같이 Linux에서 ZFS를 사용하면 추가로 혼란 스러울 수 있습니다. 실제로 필요에 따라 ZFS 캐시에서 해당 메모리를 사용할 수있는 경우 시스템의 여유 메모리가 부족한 것으로 보일 수 있습니다.
8. sar -n DEV 1
$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00
12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00
12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
^C이 도구를 사용하여 워크로드를 측정하는 네트워크 인터페이스 처리량 (rxkB / s 및 txkB / s)을 확인하고 한계에 도달했는지 확인하십시오. 위의 예에서, eth0 수신은 22Mbytes / s에 도달하는데, 이는 176Mbits / sec (즉, 1Gbit / sec 제한 미만)입니다.
이 버전에는 또한 장치 사용률에 대한 % ifutil (전이중의 경우 최대 양방향)이 있습니다. 이는 Brendan의 nicstat 도구 를 사용 하여 측정합니다. 그리고 nicstat와 마찬가지로, 이것은 올바르게 이해하기 어렵고이 예제 (0.00)에서는 작동하지 않는 것 같습니다.
9. sar -n TCP,ETCP 1
$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00
12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00
12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00
12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00
^C이것은 일부 주요 TCP 메트릭의 요약 된보기입니다. 여기에는 다음이 포함됩니다.
- active / s : 초당 로컬로 시작된 TCP 연결 수 (예 : connect ()를 통해).
- passive / s : 초당 원격으로 시작된 TCP 연결 수 (예 : accept ()를 통해).
- retrans / s : 초당 TCP 재전송 횟수입니다.
활성 및 수동 수는 서버로드의 대략적인 척도 인 새 허용 연결 수 (수동) 및 다운 스트림 연결 수 (활성)로 종종 유용합니다. 액티브를 아웃 바운드로, 패시브를 인바운드로 생각하면 도움이 될 수 있지만 이는 사실이 아닙니다 (예 : 로컬 호스트와 로컬 호스트 연결을 고려).
재전송은 네트워크 또는 서버 문제의 표시입니다. 신뢰할 수없는 네트워크 (예 : 공용 인터넷)이거나 서버에 과부하가 걸리고 패킷이 삭제 된 것일 수 있습니다. 위의 예는 초당 하나의 새로운 TCP 연결 만 보여줍니다.
10. top
$ top
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java
4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave
66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top
5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java
4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java
1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0
5 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:06.94 kworker/u256:0
8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_schedtop 명령에는 앞서 확인한 많은 메트릭이 포함됩니다. 로드가 가변적임을 나타내는 이전 명령과 사물이 다르게 보이는지 확인하는 것이 편리 할 수 있습니다.
단점은 시간이 지남에 따라 패턴을보기가 어렵다는 것인데, 이는 롤링 출력을 제공하는 vmstat 및 pidstat와 같은 도구에서 더 명확 할 수 있습니다. 출력을 충분히 빨리 일시 정지하지 않으면 (Ctrl-S를 일시 정지하고, Ctrl-Q를 계속하여) 화면이 사라지면 간헐적 문제의 증거를 잃을 수도 있습니다.
후속 분석
더 깊게 훈련하기 위해 적용 할 수있는 더 많은 명령과 방법이 있습니다. 관찰 성, 벤치마킹, 튜닝, 정적 성능 튜닝, 프로파일 링 및 추적을 다루는 40 개 이상의 명령을 통해 작동하는 Velocity 2015 의 Brendan의 Linux Performance Tools 튜토리얼을 참조하십시오.
참고
- b.luavis.kr/server/linux-performance-analysis
- netflixtechblog.com/linux-performance-analysis-in-60-000-milliseconds-accc10403c55