linux 性能自我学习 ———— cpu 高怎么办 [三]

前言

linux 性能分析自我学习。

正文

一般我们说cpu,一般是什么高呢? 一般是指cpu 使用率高。

那么什么是cpu 使用率呢?

cpu 使用率 = 1- 空闲时间/总cpu 时间

平均cpu 使用率 = 1 -(new空闲时间 - old 空闲时间)/ (new总cpu时间 - old总cpu时间)

我们可以使用top 查看:

那么来看下这些参数的意义:

  1. user (通常为us), 用户态的时间。(不包含nice的时间,但是包含guest的时间)

  2. nice (ni) 表示低优先级用户态cpu 时间,也就是进程的nice 值被调整为1-19 之间的cpu 时间。 nice 值可取-20-19,数值越大,优先级越低。

  3. system (sys), 表示内核态cpu 时间。

  4. idle, 代表空闲时间。 注意,它不包含等待 i/o 的时间。

  5. iowait (通常为wa), 表示等待i/o的cpu 时间。

  6. irq(通常为hi),表示处理硬中断的cpu 时间

  7. softtirq(si), 表示处理软中断的cpu时间

  8. steal(st),表示该系统运行在虚拟机中的时候,被其他虚拟机占用的cpu时间。

  9. guest(通常缩写为guest), 代表虚拟化运行其他操作系统的时间,也就是运行虚拟机的cpu时间

  10. guest_nice(通常缩写为gnice),表示低优先级运行虚拟机的时间。

然后下面是进程占用cpu的时间,但是其中间并没有分为用户态使用率和内核态使用率

那么就需要使用pidstat:

那么我们怎么定位cpu 高到底是怎么造成的呢?

一般使用perf 这个工具。

如果使用perf top 看下,那么是怎么样的呢?

第一行包含3个数据, 分别是采样数, 事件类型event, 事件总数量。

第二行:

overhead, 是该符号的性能事件在所有采样中的比例,用百分号来表示

shared, 是该函数或指令所在的动态共享对象(dynamic shared object), 如内核,进程名,动态链接库名, 内核模块名等。

object, 是动态共享对象的类型,比如. 表示用户空间的可执行程序或者链接库,而k 表示内核空间

symbol, 是符号名,也是函数名。当函数未知时候,用十六进制地址表示。

还可以直接使用perf record 和 perf report。

perf record 将信息收集起来。

然后perf report 就打开记录进行分析。

一般我们定位到具体的pid的时候,那么会使用:

perf -g -p xxx

这个-g 表示了,调用关系。

然后一般我们的web 服务会进行压测。

一般使用ab。

ab -c 10 -n 10000 http://10.254.0.5:10000

这样去压测,如果压测吞吐很低,那么就应该分析性能问题。

实验

实验:cpu 很高,但是找不到cpu高的应用。

运行nginx:

docker run --name nginx -p 10000:80 -itd feisky/nginx:sp

运行php代码:

docker run --name phpfdm -itd --network container:nginx feisky/php-fpm:sp

curl 一下:

 curl http://192.168.62.136:10000

发现成功. 压测一下:

ab -c 100 -n 1000 http://192.168.62.136:10000/

ab 安装:

yum -y install httpd-tools

结果为:

每秒60多,有点小低了。

ab -c 5 -t 600 http://192.168.62.136:10000/

通过top 看一下cpu情况:

发现top 很高,但是进程cpu不高,这怎么说?

难道还有进程不占用cpu?

通过pidstat 查看一下:

cpu 也不高啊。

通过task 这一行看下,发现就绪队列有6个:

诡异的事情出现了,这一排居然没有发现6个就绪进程。

那么可能原因是什么呢?

  1. 进程在不停的崩溃重启,比如因为段错误等。 这时候,进程在推出后又被监控系统自动重启了。

  2. 这些进程是短时进程,也就是在其他应用内部通过exec 调用的外部命令。这些命令一般都只运行很短时间就会结束,你很难用top这种间隔比较长的工具发现。

用ps tree 查看一下:

yum -y install psmisc

这里可以看到php-fpm 中启动了stress,那么是不是stress的问题呢?

这个时候可以看代码,其实一般看错误日志就知道了。

这种排查方式比较慢,直接用perf比较好。

的确看到了stree,但是cpu 使用高还是kernel,内核方法。

perf record -g

等一段时间看下情况:

perf report

那么有没有其他短时进程监控能马上能查看到的呢? execsnoop.

centos 怎么安装呢?

下载:

https://github.com/brendangregg/perf-tools

一般我会下载zip,然后解压。

然后运行:

./perf-tools/perf-tools-master/bin/execsnoop 

不可中断进程和僵尸进程。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章