linux应用系统使用率,Linux性能优化实战:系统CPU使用率高,但为啥找不到高的应用(06)...
一、環(huán)境準(zhǔn)備
1、安裝軟件包
終端1
機(jī)器配置:2 CPU,8GB 內(nèi)存 預(yù)先安裝 docker、sysstat、perf等工具
1 [root@luoahong ~]#docker -v
2 Docker version 18.09.1, build 4c52b903 [root@luoahong ~]#rpm -qa|grep sysstat
4 sysstat-12.1.2-1.x86_64
終端2
機(jī)器配置:1 CPU,2GB 內(nèi)存 預(yù)先安裝ab 等工具
1 [root@nfs ~]#yum -y install httpd-tools
2 [root@nfs ~]#ab -V
3 This is ApacheBench, Version 2.3
4 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
5 Licensed to The Apache Software Foundation, http://www.apache.org/
2、實(shí)戰(zhàn)拓譜圖
3、環(huán)境模擬
終端一
docker run --name nginx -p 10000:80 -itd feisky/nginx:sp
$ docker run--name phpfpm -itd --network container:nginx feisky/php-fpm:sp
終端二
測(cè)試nginx是否啟動(dòng)
#192.168.118.97 是第一臺(tái)虛擬機(jī)的 IP 地址
$ curl http://192.168.118.97:10000/It works!
性能測(cè)試
#并發(fā) 100 個(gè)請(qǐng)求測(cè)試 Nginx 性能,總共測(cè)試 1000 個(gè)請(qǐng)求
$ ab -c 100 -n 1000 http://192.168.118.97:10000/Thisis ApacheBench, Version 2.3 Copyright1996Adam Twiss, Zeus Technology Ltd,
...
Requests per second:87.86 [#/sec] (mean)
Time per request: 1138.229[ms] (mean)
...
繼續(xù)壓力測(cè)試
ab -c 5 -t 600 http://192.168.118.97:10000/
二、定位問(wèn)題(top、pidstat、ps)
1、top定位
2、pidstat定位
1 [root@luoahong ~]#pidstat 1
2 Linux 3.10.0-957.5.1.el7.x86_64 (luoahong) 05/04/2019 _x86_64_ (2CPU)3
4 03:41:55 PM UID PID %usr %system %guest %wait %CPU CPU Command5 03:41:56 PM 0 3 0.00 2.94 0.00 0.00 2.94 0 ksoftirqd/06 03:41:56 PM 0 9 0.00 6.86 0.00 27.45 6.860 rcu_sched7 03:41:56 PM 0 14 0.00 15.69 0.00 9.80 15.69 1 ksoftirqd/1
8 03:41:56 PM 0 7500 4.90 2.94 0.00 0.98 7.840 vmtoolsd9 03:41:56 PM 0 9451 0.00 1.96 0.00 0.00 1.96 1dockerd10 03:41:56 PM 27 9928 0.00 0.98 0.00 0.00 0.980 mysqld11 03:41:56 PM 0 10133 0.98 0.00 0.00 0.00 0.98 1 containerd-shim12 03:41:56 PM 0 10804 0.00 0.98 0.00 4.90 0.98 1 kworker/1:013 03:41:56 PM 0 10835 0.98 3.92 0.00 0.00 4.90 1 containerd-shim14 03:41:56 PM 101 10891 0.00 5.88 0.00 15.69 5.880 nginx15 03:41:56 PM 1 84378 0.98 2.94 0.00 3.92 3.92 0 php-fpm16 03:41:56 PM 1 84388 0.00 1.96 0.00 3.92 1.96 1 php-fpm17 03:41:56 PM 1 84395 0.98 0.98 0.00 4.90 1.96 1 php-fpm18 03:41:56 PM 1 84411 0.00 0.98 0.00 3.92 0.98 0 php-fpm19 03:41:56 PM 1 84413 0.00 1.96 0.00 8.82 1.96 1 php-fpm20 03:41:56 PM 0 102735 0.00 0.98 0.00 0.00 0.98 1 pidstat
3、top再次定位
你有沒(méi)有發(fā)現(xiàn),nginx和所有的PHP-FPM都處于sleep狀態(tài),二真正處于Running(R)狀態(tài)的,卻是幾個(gè) stress 進(jìn)程,這幾個(gè)stree比較奇怪,需要我們做進(jìn)一步的分析
4、pidstat再次定位
1 [root@luoahong perf-tools]#pidstat -p 24226
2 Linux 3.10.0-957.5.1.el7.x86_64 (luoahong) 05/04/2019 _x86_64_ (2CPU)3
4 03:47:45 PM UID PID %usr %system %guest %wait %CPU CPU Command
奇怪、居然沒(méi)有任何輸出。難道是pidstat命令出問(wèn)題了嗎?在懷疑西能工具出問(wèn)題前,最好還是先用其他工具交叉確認(rèn)一下
5、ps定位
[root@luoahong perf-tools]#ps aux|grep 24226
root 66566 0.0 0.0 112708 980 pts/0 S+ 15:46 0:00 grep --color=auto 24226
還是沒(méi)有輸出,現(xiàn)在終于發(fā)現(xiàn)問(wèn)題,原來(lái)這個(gè)進(jìn)程已經(jīng)不存在了,所以pidstat就沒(méi)有任何輸出,既然進(jìn)程都沒(méi)了
那西能問(wèn)題應(yīng)該跟著沒(méi)了吧。我們?cè)趖op命令確認(rèn)一下;
top
...%Cpu(s): 80.9 us, 14.9 sy, 0.0 ni, 2.8 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0st
...
PID USER PR NI VIRT RES SHR S%CPU %MEM TIME+COMMAND6882 root 20 0 12108 8360 3884 S 2.7 0.1 0:45.63 docker-containe6947 systemd+ 20 0 33104 3764 2340 R 2.7 0.0 0:47.79nginx3865 daemon 20 0 336696 15056 7376 S 2.0 0.2 0:00.15 php-fpm6779 daemon 20 0 8184 1112 556 R 0.3 0.0 0:00.01stress
...
可是,剛剛看到的stree進(jìn)程不存在了,怎么還在運(yùn)行呢?原來(lái)這次stree進(jìn)程的pid跟前面不一樣了,原來(lái)的pid不見(jiàn)了現(xiàn)在的是6779
進(jìn)程的 PID 在變,這說(shuō)明什么呢?在我看來(lái)要么是這些進(jìn)程在不停地重啟,要么就是全新的進(jìn)程,這無(wú)非也就兩個(gè)原因
第一原因:進(jìn)程在不停地崩潰重啟,比如因?yàn)槎五e(cuò)誤、配置錯(cuò)誤等等這時(shí),進(jìn)程在退出后可能又被監(jiān)控系統(tǒng)自動(dòng)重啟了。
第二原因:這些進(jìn)程都是短時(shí)進(jìn)程,也就是在其他應(yīng)用內(nèi)部通過(guò) exec 調(diào)用的外面命令。這些命令一般都只運(yùn)行很短的時(shí)間就會(huì)結(jié)束,你很難用 top 這種間隔時(shí)間比較長(zhǎng)的工具發(fā)現(xiàn)(上面的案例,我們碰巧發(fā)現(xiàn)了)
6、用pstree | grep [xx],這樣定位到具體的調(diào)用方法里。
[root@luoahong ~]#pstree | grep stress
| | | |-2*[php-fpm---sh---stress---stress]| | | |-php-fpm---sh---stress
三、定位到具體的代碼
1、用grep [xx] -r [項(xiàng)目文件]
查找是不是代碼在調(diào)用stree命令
#拷貝源碼到本地
$ docker cp phpfpm:/app .#grep 查找看看是不是有代碼在調(diào)用 stress 命令
$ grep stress -r app
app/index.php:// fake I/O with stress (via write()/unlink()).
app/index.php:$result = exec("/usr/local/bin/stress -t 1 -d 1 2>&1", $output, $status);
2、找到具體代碼位置
找到了,果然是app/index.php
cat app/index.php<?php // fake I/O with stress (via write()/unlink()).
$result= exec("/usr/local/bin/stress -t 1 -d 1 2>&1", $output, $status);if (isset($_GET["verbose"]) && $_GET["verbose"]==1 && $status !=0) {
echo"Server internal error:";
print_r($output);
}else{
echo"It works!";
}
?>
3、給請(qǐng)求加入 verbose=1 參數(shù)后,就可以查看 stress的輸出
[root@nfs ~]#curl http://192.168.118.97:10000/?verbose=1
Server internal error: Array
(
[0]=> stress: info: [103660] dispatching hogs: 0 cpu, 0 io, 0 vm, 1hdd
[1] => stress: FAIL: [103661] (563) mkstemp failed: Permission denied
[2] => stress: FAIL: [103660] (394) stress: WARN: [103660] (396) now reaping child worker processes
[4] => stress: FAIL: [103660] (400) kill error: No such process
[5] => stress: FAIL: [103660] (451) failed run completed in0s
)
從這里我們可以猜測(cè),正式由于權(quán)限錯(cuò)誤,大量的stress進(jìn)程在啟動(dòng)是初始化失敗,進(jìn)而導(dǎo)致用戶CPU使用率的升高
4、perf驗(yàn)證定位是否準(zhǔn)確
1、perf record -g 記錄
perf record -g
docker cp perf.data phpfpm:/tmp
dockerexec -i -t phpfpm bash
2、 用perf report查看是否可以定位到問(wèn)題
cd /tmp/apt-get update && apt-get install -y linux-perf linux-tools procps
perf_4.9 report
四、execsnoop和實(shí)驗(yàn)過(guò)程中遇到的問(wèn)題
1、execsnoop查看短時(shí)進(jìn)程詳細(xì)信息
execsnoop 就是一個(gè)專(zhuān)為短時(shí)進(jìn)程設(shè)計(jì)的工具它通過(guò) ftrace 實(shí)時(shí)監(jiān)控進(jìn)程的 exec() 行為,并輸出短時(shí)進(jìn)程的基本信息,
包括進(jìn)程 PID、父進(jìn)程 PID、命令行參數(shù)以及執(zhí)行的結(jié)果。
用 execsnoop 監(jiān)控上述案例,就可以直接得到 strress 進(jìn)程的父進(jìn)程 PID 以及它的命令行參數(shù),并可以發(fā)現(xiàn)大量的 stress 進(jìn)程在不停啟動(dòng):
git clone --depth 1 https://github.com/brendangregg/perf-tools
cd perf-tools/[root@luoahong perf-tools]#./bin/execsnoop
Tracing exec()s. Ctrl-C to end.
Instrumenting sys_execve
PID PPID ARGS70342 70322 gawk -v o=1 -v opt_name=0 -v name= -v opt_duration=0 [...]70344 50765 <...>-70344 [001] d... 2372.510629: execsnoop_sys_execve: (SyS_execve+0x0/0x30)70343 70341 cat -v trace_pipe70340 0 /usr/local/bin/stress -t 1 -d 1
70346 70339 /usr/local/bin/stress -t 1 -d 1
70347 70344 /usr/local/bin/stress -t 1 -d 1
70351 50796 <...>-70351 [000] d... 2372.553884: execsnoop_sys_execve: (SyS_execve+0x0/0x30)70352 50775 <...>-70352 [000] d... 2372.555010: execsnoop_sys_execve: (SyS_execve+0x0/0x30)70353 70351 /usr/local/bin/stress -t 1 -d 1
70355 50776 <...>-70355 [000] d... 2372.557869: execsnoop_sys_execve: (SyS_execve+0x0/0x30)70357 70355 /usr/local/bin/stress -t 1 -d 1
70356 70352 /usr/local/bin/stress -t 1 -d 1
execsnoop所用的ftrace是一種常用的動(dòng)態(tài)追蹤技術(shù),一般用于分析linux內(nèi)核的運(yùn)行時(shí)為
2、pstree的安裝
yum install psmisc
3、小結(jié)
如果碰到不好解釋的CPU問(wèn)題時(shí),比如現(xiàn)象:
通過(guò)top觀察CPU使用率很高,但是看下面的進(jìn)程的CPU使用率好像很正常,通過(guò)pidstat命令查看cpu也很正常。但通過(guò)top查看task數(shù)量不正常,處于R狀態(tài)的進(jìn)程是可疑點(diǎn)。
首先要想到可能是短時(shí)間的應(yīng)用導(dǎo)致的問(wèn)題,如下面的兩個(gè):
(1)應(yīng)用里直接調(diào)用了其他二進(jìn)制程序,這些程序通常運(yùn)行時(shí)間比較短,通過(guò)top等工具發(fā)現(xiàn)不了
(2)應(yīng)用本身在不停地崩潰重啟,而啟動(dòng)過(guò)程的資源初始化,很可能會(huì)占用很多CPU資源
總結(jié)
以上是生活随笔為你收集整理的linux应用系统使用率,Linux性能优化实战:系统CPU使用率高,但为啥找不到高的应用(06)...的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: spy导入数据到oracle,运用Sch
- 下一篇: linux超级密码,找回Linux超级用