26. 60s 빠른 포지셔닝 서버 성능 문제
1、uptime
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
이것은 시스템의 평균 부하를 신속하게 보는 방법으로 시스템에서 실행해야 할 작업 (프로세스) 이 얼마나 많은지를 나타낸다.Linux 시스템에서 이러한 숫자는 CPU에서 실행해야 하는 프로세스와 입출력을 기다리는 프로세스(일반적으로 디스크 입출력)를 포함합니다.그것은 단지 시스템 부하에 대한 대략적인 전시일 뿐, 조금만 보면 된다.너는 구체적인 상황을 한층 더 이해하기 위해 다른 도구가 필요하다.
이 세 개의 숫자는 1분, 5분, 15분 동안 시스템의 부하 총량 평균치를 지수 비율에 따라 압축한 결과를 보여준다.그 중에서 우리는 시스템의 부하가 어떻게 시간에 따라 변화하는지 볼 수 있다.예를 들어 문제를 검사한 후에 1분에 대응하는 값이 15분보다 훨씬 적은 것을 보면 이 문제가 이미 지나갔고 제때에 관찰하지 못했다는 것을 설명할 수 있다.
위의 예에서 시스템 부하는 시간이 증가함에 따라 증가한다. 왜냐하면 최근 1분의 부하치가 30을 넘었고 15분의 평균 부하는 19에 불과하기 때문이다.이렇게 현저한 차이는 CPU 부하와 같은 여러 가지 의미를 포함하고 있다.더 확인하려면 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
vmstat(8)은 가상 메모리 통계의 약칭으로 몇 십 년 전에 BSD를 위해 만들어진 일반적인 도구이다.각 행에 중요한 서버의 통계 요약을 인쇄합니다.
vmstat 명령은 매 초의 통계 요약을 출력하기 위해 매개 변수 1을 지정합니다.(이 버전의 vmstat) 출력된 첫 줄의 열은 1초 전의 값이 아니라 켜진 후의 평균 값입니다.지금 우리는 네가 모든 열을 이해하고 기억하고 싶지 않으면 첫 번째 줄을 건너뛴다.
다음 열을 확인합니다.
CPU 분해 시간은 사용자 시간과 시스템 시간을 통해 CPU가 분주한 상태인지 확인합니다.입출력을 기다리는 시간이 변하지 않으면 디스크 병목이 표시됩니다.이것이 바로 CPU의 유휴입니다. 작업이 디스크 I/O를 끊을 때까지 막혀 있기 때문입니다.너는 I/O를 기다리는 것을 CPU가 유휴된 또 다른 형식으로 여길 수 있다. 이것은 왜 CPU가 유휴되었는지에 대한 단서를 제공한다.
입출력 처리에 있어 시스템 시간은 매우 중요하다.평균 시스템 시간의 20%를 초과하여 더욱 연구할 필요가 있다. 아마도 코어가 I/O를 처리할 때 효율이 너무 낮을 것이다.
위의 예에서 CPU 시간은 거의 사용자 등급에 완전히 걸렸고 응용 프로그램이 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
^C
pidstat 명령은 top 명령이 모든 프로세스에 대한 통계 요약과 비슷하지만, top의 도배를 대체하기 위해 스크롤된 통계 요약을 순환적으로 출력합니다.이것은 실시간으로 볼 수 있을 뿐만 아니라, 당신이 본 것을 조사 기록에 복사하여 붙일 수도 있다.
위의 예에서는 두 Java 프로세스가 CPU를 소비하고 있음을 나타냅니다.%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
이것은 작업 부하든 성능 표현이든 블록 장치 (디스크) 의 상황을 보는 데 아주 좋은 도구이다.열 보기:
스토리지 디바이스가 많은 백엔드 디스크를 위한 논리적 디스크 디바이스인 경우 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
오른쪽의 두 열 표현식:
우리는 단지 0에 가깝지 않은 크기를 검사하고 싶을 뿐, 더 높은 디스크 I/O (iostat 확인), 더 나쁜 성능을 초래할 수 있다.위의 예는 보기에 그런대로 괜찮다. 각 열마다 M개의 크기가 매우 많다.
첫 줄보다 -/+buffers/cache가 제공하는 메모리 사용량이 더 정확합니다.Linux는 잠시 사용할 수 없는 메모리를 캐시로 사용하고 필요할 때 바로 다시 분배합니다.그래서 일부 캐시로 사용되는 메모리도 사실 빈 메모리라고 할 수 있다.이 점을 설명하기 위해 심지어 어떤 사람들은 전문적으로 사이트인 linuxatemyram을 만들었다.
만약 당신이 Linux에 ZFS를 설치했다면, 이 점은 더욱 곤혹스러울 것이다. 왜냐하면 ZFS는 자신의 파일 시스템 캐시가free-m에 포함되지 않기 때문이다.때때로 시스템에서 사용할 수 있는 빈 메모리가 많지 않은 것을 발견하지만, 사실 메모리는 모두 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와 같이sar가 표시한 이 값은 정확하게 얻기 어려운데, 이 예에서 정상적인 작업(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 지표의 요약 보기이다.여기에는 다음이 포함됩니다.
재전송은 네트워크와 서버 문제가 발생한 징조이다.신뢰할 수 없는 네트워크 (예를 들어 공공 네트워크) 때문일 수도 있고, 서버가 과부하되어 가방을 잃어버릴 수도 있다.위의 예는 초당 하나의 새로운 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_sched
top 명령은 우리가 이전에 검사한 지표를 많이 포함하고 있다.이전의 명령 출력에 비해 부하가 변할 수 있다는 것을 보여 주기 위해 편리하게 실행할 수 있다.
top의 단점 중 하나는 데이터가 시간에 따라 변동하는 추세를 보기 어렵다는 것이다.vmstat과pidstat가 제공하는 스크롤 출력은 더 잘 알 수 있습니다.만약 당신이 충분한 속도로 출력을 멈추지 않는다면, (Ctrl-S가 멈추고, Ctrl-Q가 계속된다) 간헐적인 문제의 단서도 화면이 정리되어 잃어버릴 수 있습니다.
소프트웨어 테스트 왕 주소 소프트웨어 테스트 왕 블로그 주소
위챗 공중번호: 소프트웨어 테스트 왕에 관심을 가져 주십시오.소프트웨어 테스트 커뮤니케이션 그룹: 809111560
전재 출처 주의하세요, 협조해 주셔서 감사합니다
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
다양한 언어의 JSONJSON은 Javascript 표기법을 사용하여 데이터 구조를 레이아웃하는 데이터 형식입니다. 그러나 Javascript가 코드에서 이러한 구조를 나타낼 수 있는 유일한 언어는 아닙니다. 저는 일반적으로 '객체'{}...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
