linux性能：cpu/内存/io/网络
cpu:负载/cpu使用率
负载：系统正在运行以及正在等待io的进程的一个数量，大概可以反应系统是否紧张 vmstat中的r跟b列 r(运行和等待的进程) b(中断不可恢复的进程)
cpu使用率：用户态和内核态 hi si st（软硬中断和steal也算在cpu使用率中） nice和ideal不算cpu使用率
用户态：
内核态：底层操作都是内核态
ni:0～-20，越小级别越大
wait:等待磁盘操作所消耗的cpu,全称叫iowait
硬中断：硬件外设产生的中断
软中断：软件本身产生的中断
上下文：上文-从哪取数据，下文-下面要执行啥操作
上下文切换：1.进程与进程之间(消耗cpu是这几种中最高) 2.进程内部（us->sy） 3.线程跟线程 4.中断导致的
内存：物理内存和虚拟内存和交换内存(swap) 进程先在虚拟内存中运行，然后不够，溢出到物理内存。最后实在不行，才到交换内存
物理内存和虚拟内存用的其实都是物理内存
buffer:缓冲的是要写的数据，文件系统到内存的读写数据
cache:缓存的是要读的数据，磁盘到内存的裸io数据
磁盘：好坏看读写的速度，使用程度
io:
网络：网络先触发的是硬中断，然后是软中断
下面开始讲一些案例：
命令不懂的就自己--help查看
stress --cpu 1 --timeout 6001.首先就top命令：
时间长可以看出负载越来越高，慢慢接近1
2.通过vmstat
procs: 负载=r+b 因为这里r一直有进程在执行，所以负载接近1.因为只有一个cpu在干活，所以负载没法到2
in：中断 cs: 上下文切换
stress -i 1 --timeout 600
1.先top,可以看出负载升高，sy cpu升高。
这个系统的wait坏了，监控不出来。这里的wait应该是会升到10%左右。那就是iowait导致的(所以我们要看io的问题，iostat pidstat)
解决这个问题可以用stress-ng：stress的升级版
iostat -x 2 %util:代表磁盘的繁忙程度(超过了20%，可以看出是写操作导致的)
也可以用pidstat -d 1看（然后用pidstat -d可以看出具体是哪个消耗的）
--
stress -c 8 --timeout 600
可以看到负载慢慢会升到8，因为8个stress一直在消耗cpu
通过vmstat可知，r+b=8
pidstat也可以看：
这里面的wait是等待cpu临幸所消耗的百分比。等待cpu时间切片给他。所以和上面的wait数值不一样
等待的话，说明上下文切换和中断会比较多。虽然没上10W,但是肯定也比平时高
sysbench --threads=10 --max-time=300 threads run //sysbench --threads=10 --time=300 threads run
1.top sy比较高 （下一步分析谁占用的内核态， wait hi si st[虚拟化]都没有）
2.vmstat 上下文比较高(cs)
3.进程上下文切换低
4.发现原来是线程上下文切换高 pidstat -w // pidstat -wt
pidstat是按不同维度进行了排序，所以我们今天会一直看pidstat。这样找起来会很快
cswch:主动上下文切换，指进程无法获取所需资源，导致的上下文切换
nvcswch:被动上下文切换，指进程由于 时间片已到 等原因，被系统强制调度，进而发生的上下文切换
问题：为什么pidstat看的上下文切换不高，而vmstat特别高 因为pidstat默认看的是进程的 因为进程的最小单位是线程，我们可以pidstat -wt 1 这样就看的线程的
下午：
先运行app.py文件
发现负载较高，且iowait高。这个时候因为iowait高，所以，我们怀疑是磁盘出了问题
那么我就去看磁盘
看util可以看出cpu已经很繁忙了
await，也很大。这个一般不超过5
wkb/s:写也多 ------磁盘写操作，导致iowait繁忙
队列也多
procs：r+b
pidstat看出是python3 pidstat -d 1
然后可以用strace命令跟着这个进程，strace -p pid
可以看出在写文件
我们进入这个目录，发现他确实在写文件
然后使用lsof可以查看文件谁在使用。 4w是正在写的意思
分析到这之后，我们可以去看代码了
和iostat对比一下，可以确认就是写的问题
总结： 1.先观察系统，负载比较高 2.然后看vmstat的r+b,确实是r+b导致的。b比较多，b是中断不可恢复（io操作最常见的） 3.继续top，负载高，cpu不算太高，但是iowait高，hi si软硬中断都不高（这步我们就怀疑是磁盘了） 4.iostat -x 2 发现在疯狂的写操作，导致我们的高负载（然后我们就要去看是什么进程导致的大量写） 5.pidstat -d 1(可以以进程维度去排序cpu io 磁盘 cs等等)，发现是python进程大量的写 6.strace -p pid（应用程序我们需要定位到具体的原因），strace跟踪内核 7.发现是在写文件 8.我们用lsof fileName 去确认了一下，发现确实是这个样子9.cat 代码。确实是在写这个文件。ok?至此结束
接下来，我们执行另外一个文件，运行另外一个例子
没有flask文件，我们pip给他装一下
运行：什么都不高，但就是访问web工程贼慢
spotlight:可以动态话的监督很多东西
3个有道云笔记，看课件
cpu热点火焰图，大牛会用这个
平均负载高，我们就要去看vmstat(r+b)
如果b列高，大概率是io导致的，我们就去看iostat -x 2 或 sar -d 1 或 pidstat -d 1
如果us高，那我们就看用户cpu
如果sy高，看perf(perf跟踪cpu)
iowait高看iostat 或 pidstat ---用strace(strace跟踪io)
上下文切换vmstat pidstat
上下文切换要看是自愿还是非自愿
软硬中断都可以用cat看 cat/proc/soft...
软中断大概率网络导致的sar netstat tcp
cpu
～～～～～～～～～～～～～～～
～～～～～～～～～～～～～～～
内存
一般遇到内存问题比较少。遇到的基本都是jvm的内存
sar -b：缺页异常
缓冲：读写，文件到设别块。把分散的读写操作合并成一次磁盘的写操作
缓存：读写，内存到设备块，设备块到内存
swap基本不用，可以直接设置为0
内存：虚拟内存 物理内存 交换内存
一般虚拟内存和物理内存大小是一样的，如果不配置的话
系统已用/可用/剩余内存：free vmstat sar cat/proc/meminfo
进程虚拟内存/常驻内存/共享内存：ps top
进程缺页异常：sar ps top
缓冲/缓存：top sar
缓存/缓冲区命中率：cachet op
内存
～～～～～～～～～～
～～～～～～～～～～
磁盘（io）
系统调用-->文件系统-->磁盘
指标：主要看使用率 %util，同时结合看读写速率
sar pidstat -d
iostat -x
响应时间：await（分w和r）
top wait io的wait等待io消耗的
pidstat wait 等待cpu所花费的百分比
磁盘 wait 包括磁盘本身操作的时间和等待的时间
看队列
文件系统空间容量/使用量以及剩余空间：df
索引节点容量/使用量以及剩余量：df -i
页缓存和可回收slab缓存：/proc/meminfo sar -r vmstat
缓冲区：/proc/meminfo sar -r vmstat
目录项/索引节点以及文件系统的缓存：/proc/slabinfo slabtop
磁盘i/o使用率/iops/吞吐量/响应时间/io平均大小以及队列等待长度：iostat -d -x sar -d
进程io大小以及延迟：pidstat iotop
思路：top
wait高 pidstat ---看那个进程
缓存或缓冲高 vmstat
跟踪strace
怀疑网络的话netstat tcp -dump
转载于:https://www.cnblogs.com/Charles2625/p/11110826.html
