性能的目标
从应用负载方面来看,系统应该做到:
从系统资源方面来看:
如何优化
系统响应变慢了,可以从CPU、内存、磁盘、网络四个维度来分析
第一步,先来看系统整体资源使用情况
(1)相关命令
- top命令可以查看CPU平均负载、系统任务情况、每个CPU的使用率、内存使用率
- df命令可以查询文件系统的使用情况:
- df -h的%usr可以查看整体的文件系统使用情况;如果正常,那么用df -i查询是不是大量的小文件引起的
(2)举个例子:
# 按下数字 1 切换到所有 CPU 的使?情况,观察?会?按 Ctrl+C 结束
$ top
top - 05:56:23 up 17 days, 16:45, 2 users, load average: 2.00, 1.68, 1.39
Tasks: 247 total, 1 running, 79 sleeping, 0 stopped, 115 zombie
%Cpu0 : 0.0 us, 0.7 sy, 0.0 ni, 38.9 id, 60.5 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 0.0 us, 0.7 sy, 0.0 ni, 4.7 id, 94.6 wa, 0.0 hi, 0.0 si, 0.0 st
---
KiB Mem : 8169348 total, 6871440 free, 267096 used, 1030812 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7607492 avail Mem
...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4340 root 20 0 44676 4048 3432 R 0.3 0.0 0:00.05 top
4345 root 20 0 37280 33624 860 D 0.3 0.0 0:00.01 app
4344 root 20 0 37280 33624 860 D 0.3 0.4 0:00.01 app
1 root 20 0 160072 9416 6752 S 0.0 0.1 0:38.59 systemd
- 第一行是平均负载,主要关注两点:
- (1)趋势:正常情况下趋势应该是平稳的
- (2)取值,正常情况下取值和CPU个数相同,如果取值超过CPU个数70%那么需要调试
- 第二行是任务情况,主要关注两点:
- (1)有多少个运行的进程,正常取值应该小于等于CPU个数(如果个数超过CPU个数,那么会有大量进程切换导致CPU升高)
- (2)有多少个僵尸进程,正常取值应该是0,如果非0,说明有子进程没有被清理,这样可能导致资源耗尽
- 第三行是每个CPU的使用率
- (1)主要关注四个方面:用户CPU使用率(us、ni)、内核CPU使用率(sy)、等待IO的CPU使用率(wa)、中断CPU使用率
- 用户CPU使用率(用户态CPU使用率%usr、低优先级CPU使用率%nice)太高,说明应用程序比较繁忙
- 内核CPU使用率(%sys)太高,说明内核调度比较繁忙
- 等待IO即(iowait)太高,说明系统频繁和硬件设备打交道
- 软中断和硬中断CPU太高,说明发生了大量的中断
- (2)CPU使用率异常分三种情况(可能需要计算出每一个CPU的整体使用率)
- 某个CPU的使用率远远高于其他CPU使用率。又分为两种情况:
- iowait高而其他低,那么就是因为IO密集型任务引起的,需要查看进行的IO使用情况
- iowait低而sys高,那么可能是因为CPU密集型任务,接下来的排除方向是进程的CPU使用
- 如果所有CPU的使用率都将近打满,那么可能是因为大量进程切换导致的
- 如果所有CPU的使用率很低(小于%10),有可能是因为中断比较多导致的,实际情况中,如果是中断引起的,那么基本上都是因为网络接收的软中断引起的
- 第四行是系统内存的整体使用情况(这个我不怎么关注,对于内存,会使用另外的工具)
- 有两行:总物理内存Mem和交换分区Swap
- 有5列,包括total总内存大小、free未使用内存大小、used已用内存大小、buff/cache缓存和缓冲区大小
- Buffer是对磁盘数据的缓存,而Cache是对文件数据的缓存。
- 在读写普通文件时,会经过文件系统,由文件系统负责和磁盘交互;而读写磁盘或者分区时,会跳过文件系统,也就是所谓的“裸IO”
- 最后注意:指标太多了,应该找到最可疑的,不要纠结细节
第二步:如果确定是CPU异常
(1)CPU平均负载出问题了
- 表现形式:超载
- 可能原因有三个:
- CPU密集型(%usr)应用导致某个CPU超载
- IO太过繁忙(%sys)缓冲区频繁刷新导致某个CPU超载
- 进程太多大量切换也会导致CPU升高,则是所有的CPU的使用率都会接近满载
- 如果需要调试,那么:
- 先使用mpstat -P ALL监控所有CPU
- 然后使用pidstat查看所有进程,找出到底是哪个进程的什么行为导致了CPU超载(即CPU的使用率(%CPU))
- 先竖着看,找出%cpu最高的哪一行
- 然后横着看,看到时是因为%usr、%system等引起%CPU升高的
(2)CPU的使用率出问题:
- 分析到底是 IO密集型线程引起的、还是CPU密集型线程引起的、还是进程太多切换引起的
- 然后具体类型具体分析
(3)CPU上下文切换出问题了(任务异常)
- top查看就绪队列长度:
- running任务个数远远超过了系统CPU的个数,那么会有大量的CPU竞争,导致大量上下文切换
- 如果某个CPU的%sys远高于其他
- 那么可能是一个进程里有很多个线程在争抢CPU
- 此时就绪队列也是异常的,因为上下文切换需要系统调度
- 如果所有CPU的使用率都上去了,那么基本上是多个进程争抢CPU
- 可以使用vmstat查看每秒上下文切换次数:
- 数值是正确的呢?这取决于系统性能。所以我们应该关注趋势
- 如果系统的上下文切换次数比较稳定,那么应该是正常的;
- 如果出现指数级异常增长,那么说明异常
- 还需要使用pidstat -wt查看每个进程的CPU使用率情况以及每个进程、线程(linux调度的基本单位实现上是线程)的自愿( cswch/s)和非自愿上下文切换次数( cswch/s)。
- 如果某个进程的CPU使用率远远高于其他进程,那么说明它是可疑的
- 自愿上下文切换变多了,说明进程都在等待资源,有可能已经发生了IO等其他问题
- ??愿上下?切换变多了,说明进程都在被强制调度,也就是都在争抢 CPU,说明 CPU 的确成了瓶颈
(4)CPU中断出问题了
- (%hi为irq处理程序的CPU时间,si为软中断的处理时间)
- 原因:
- 中断只发生在内核态
- 中断次数变多了,说明 CPU 被中断处理程序占?,还需要通过查看 /proc/interrupts ?件来分析具体的中断类型
(5)CPU缓存命中率出问题了
|