day13_linux2

港控/mmm° 2023-06-01 06:12 34阅读 0赞

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 600

1.首先就top命令：

时间长可以看出负载越来越高，慢慢接近1

![1530544-20190630150622992-135306911.png][]

2.通过vmstat

procs: 负载=r+b      因为这里r一直有进程在执行，所以负载接近1.因为只有一个cpu在干活，所以负载没法到2

in：中断   cs: 上下文切换

![1530544-20190630150932134-1189557018.png][]

stress -i 1 --timeout 600

1.先top,可以看出负载升高，sy cpu升高。

这个系统的wait坏了，监控不出来。这里的wait应该是会升到10%左右。那就是iowait导致的(所以我们要看io的问题，iostat  pidstat)

解决这个问题可以用stress-ng：stress的升级版

![1530544-20190630152202002-2021038046.png][]

iostat -x  2      %util:代表磁盘的繁忙程度(超过了20%，可以看出是写操作导致的)

也可以用pidstat -d 1看（然后用pidstat -d可以看出具体是哪个消耗的）

![1530544-20190630171459386-1743152385.png][]

\--

![1530544-20190630172255689-89890297.png][]

stress -c 8 --timeout 600

可以看到负载慢慢会升到8，因为8个stress一直在消耗cpu

![1530544-20190630183312384-2003603544.png][]

通过vmstat可知，r+b=8

![1530544-20190630183433390-2100784219.png][]

pidstat也可以看：

这里面的wait是等待cpu临幸所消耗的百分比。等待cpu时间切片给他。所以和上面的wait数值不一样

![1530544-20190630183600433-1494406270.png][]

等待的话，说明上下文切换和中断会比较多。虽然没上10W,但是肯定也比平时高

![1530544-20190630183833736-1784560765.png][]

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高，所以，我们怀疑是磁盘出了问题

那么我就去看磁盘

![1530544-20190630211450150-71598742.png][]

看util可以看出cpu已经很繁忙了

await，也很大。这个一般不超过5

wkb/s:写也多  ------磁盘写操作，导致iowait繁忙

队列也多

![1530544-20190630211817402-511337561.png][]

procs：r+b

![1530544-20190630212136097-241916576.png][]

pidstat看出是python3           pidstat -d 1

![1530544-20190630212252766-1261481119.png][]

然后可以用strace命令跟着这个进程，strace -p pid

可以看出在写文件

![1530544-20190630212904859-90694635.png][]

我们进入这个目录，发现他确实在写文件

![1530544-20190630213033849-110580594.png][]

然后使用lsof可以查看文件谁在使用。   4w是正在写的意思

![1530544-20190630214222649-1627284029.png][]

分析到这之后，我们可以去看代码了

![1530544-20190630214507710-1118911432.png][]

和iostat对比一下，可以确认就是写的问题

![1530544-20190630214550056-427921942.png][]

总结：
    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给他装一下

![1530544-20190630220557074-102239525.png][]

运行：什么都不高，但就是访问web工程贼慢

![1530544-20190630223923339-775276106.png][]

spotlight:可以动态话的监督很多东西

![1530544-20190630225542134-1487446919.png][]

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

[1530544-20190630150622992-135306911.png]: /images/20230601/7764aa0b167f4a228ef489aae26ad209.png
[1530544-20190630150932134-1189557018.png]: /images/20230601/5e0f6e72c2784a46ab6c173162dc52bc.png
[1530544-20190630152202002-2021038046.png]: /images/20230601/3e05f7637d4146d983c35764c0f40daf.png
[1530544-20190630171459386-1743152385.png]: /images/20230601/34881d703adc4207935c4064cbb6f218.png
[1530544-20190630172255689-89890297.png]: /images/20230601/4a8378be644f49b8a090f529020a5f2c.png
[1530544-20190630183312384-2003603544.png]: /images/20230601/5d339ac4fb5c4df5a84b2490101b60e1.png
[1530544-20190630183433390-2100784219.png]: /images/20230601/3966a080b3b443c7a12d9e69c6e2e100.png
[1530544-20190630183600433-1494406270.png]: /images/20230601/5a98d6a3a52d4674ba8c35c54d900ec9.png
[1530544-20190630183833736-1784560765.png]: /images/20230601/f7d4ed3ae18845e9b6b15ad22366b9a7.png
[1530544-20190630211450150-71598742.png]: /images/20230601/3bfac60f0c964a6fa3cbbdc9a5ddc6f5.png
[1530544-20190630211817402-511337561.png]: /images/20230601/bde60c4f319449b88a89a40372f039de.png
[1530544-20190630212136097-241916576.png]: /images/20230601/396497a509f94d529687bfebee3483fe.png
[1530544-20190630212252766-1261481119.png]: /images/20230601/301872e7684b4984a15e56a705710aaa.png
[1530544-20190630212904859-90694635.png]: /images/20230601/840eb315e34549e1ad4079a3e28cdfde.png
[1530544-20190630213033849-110580594.png]: /images/20230601/cd42fd06b7044cad9eb3a871d7070f28.png
[1530544-20190630214222649-1627284029.png]: /images/20230601/210afae20a0b420988697a81d53304c0.png
[1530544-20190630214507710-1118911432.png]: /images/20230601/0ab88e9dec904f258b48c1276cc77b00.png
[1530544-20190630214550056-427921942.png]: /images/20230601/59daccdf19a04d92b14d349a9ec84f3e.png
[1530544-20190630220557074-102239525.png]: /images/20230601/d8086a9dc7444ce191645d9ecd5e6587.png
[1530544-20190630223923339-775276106.png]: /images/20230601/34593fc9054a4bcebde133e059515584.png
[1530544-20190630225542134-1487446919.png]: /images/20230601/8ad9dace62754471802d15c42ab36a50.png