linux 调优

lunix 系统性能分析标准

image.png

cpu

  • cpu 项 显示了cpu的使用状态,此项是我们关注的重点
    vmstat 命令
[root@xxxxx ~]# vmstat 2 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 147752      0 2500812    0    0     1     4    0    0  0  0 100  0  0
 0  0      0 147728      0 2500848    0    0     0    41  350  696  0  0 99  0  0
 0  0      0 147356      0 2500848    0    0     0    10  393  778  1  0 99  0  0
 0  0      0 147356      0 2500848    0    0     0     0  294  630  0  0 100  0  0
 0  0      0 146968      0 2500848    0    0     0    11  382  755  1  0 99  0  0
  • id 表示cpu处于空闲状态的时间百分比
  • wa 表示的io等待的所占用的cpu时间百分比,wa越高,说明io等待越严重,根据经验,wa的参考值为20%,如果wa超过20%,说明io等待严重,引起io等待的原因可能是磁盘大量随机读写造成的,也可能是磁盘或者磁盘控制器的贷款瓶颈造成的(主要是块操作)
  • us 表示用户进程消耗的cpu时间百分比, us 数值比较高的时候,说明用户进程消耗cpu的时间比较多,如果长期大于 50%,就要考虑优化程序和算法
  • sy 列 代表内核进程消耗的cpu时间百分比。sy的数据值比较高时候,说明内核消耗的cpu资源的很多
  • 根据经验 us+sy的参考数值80%,如果us+sy大于80%,说明cpu的内存资源不足

磁盘 io

检测磁盘性能的命令有的,sar -d ,iostat , iotop

  • sar -d
[root@gaoruiling2 ~]# sar -d 2 3
Linux 3.10.0-1127.13.1.el7.x86_64 (gaoruiling2.cmp559.safe)     06/23/2021  _x86_64_    (4 CPU)

01:59:50 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
01:59:52 PM   dev11-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
01:59:52 PM    dev8-0      1.00      0.00      8.50      8.50      0.03     30.00     30.00      3.00

01:59:52 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
01:59:54 PM   dev11-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
01:59:54 PM    dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

01:59:54 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
01:59:56 PM   dev11-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
01:59:56 PM    dev8-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

Average:          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
Average:      dev11-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:       dev8-0      0.33      0.00      2.83      8.50      0.01     30.00     30.00      1.00
DEV  磁盘设备的名称,如果不加-p,会显示dev253-0类似的设备名称,因此加上-p显示的名称更直接
tps  每秒I/O的传输总数
rd_sec/s  每秒读取的扇区的总数
wr_sec/s  每秒写入的扇区的总数
avgrq-sz  平均每次次磁盘I/O操作的数据大小(扇区)
avgqu-sz  磁盘请求队列的平均长度
await  从请求磁盘操作到系统完成处理,每次请求的平均消耗时间,包括请求队列等待时间,单位是毫秒(1秒等于1000毫秒),等于寻道时间+队列时间+服务时间
svctm  I/O的服务处理时间,即不包括请求队列中的时间
%util  I/O请求占用的CPU百分比,值越高,说明I/O越慢

输出项说明: 
rd_sec/s: 每秒从设备读取的扇区数 
wr_sec/s: 每秒往设备写入的扇区数 
avgrq-sz: 发送给设备的请求的平均大小(以扇区为单位) 
avgqu-sz: 发送给设备的请求队列的平均长度 
await :服务等待I/O请求的平均时间,包括请求队列等待时间 (单位毫秒) 
svctm :设备处理I/O请求的平均时间,不包括请求队列等待时间 (单位毫秒) 
%util :一秒中有百分之多少的时间用于 I/O 操作,即被io消耗的cpu百分比。

判别标准

  • 正常情况下svctm应该是小于await的数值的,而svctm的大小和磁盘性能有关,cpu,内存的负荷也会对svctm的数值造成影响,过多的请求也会间接的导致svctm的数值的增加
  • await的数值大小取决于svctm的数值和I/O队列长度以及I/O请求模式,如果svctm的数值和await的数值很接近,代表几乎没有的I/O等待,磁盘性能很好,如果await的数值远高于的svctm的数值,则表示I/O等待时间过久,系统上运行的程序将会变慢,此时可以通过更换更快的硬盘来解决问题。
  • %util项也是衡量磁盘I/O性能的一个重要指标,如果%util的数值接近100%,表示磁盘产生的I/O的请求太多,I/O系统已经满负荷的在工作,该磁盘可能存在性能瓶颈。长期下去,势必影响系统的性能,可以通过优化程序或者通过更换更高,更快的的磁盘来解决此问题。
  • iostat 命令
    命令参数:
    -c: 显示CPU使用情况
    -d: 显示磁盘使用情况
    -N: 显示磁盘阵列(LVM) 信息
    -n: 显示NFS 使用情况
    -k: 以 KB 为单位显示
    -m: 以 M 为单位显示
    -t: 报告每秒向终端读取和写入的字符数和CPU的信息
    -V: 显示版本信息
    -x: 显示详细信息
    -p:[磁盘] 显示磁盘和分区的情况
linux # iostat -x -k -d 1
Linux 2.6.16.60-0.21-smp (linux)     06/13/12

……
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00  9915.00    1.00   90.00     4.00 34360.00   755.25    11.79  120.57   6.33  57.60
以上各列的含义如下:
rrqm/s: 每秒对该设备的读请求被合并次数,文件系统会对读取同块(block)的请求进行合并
wrqm/s: 每秒对该设备的写请求被合并次数
r/s: 每秒完成的读次数
w/s: 每秒完成的写次数
rkB/s: 每秒读数据量(kB为单位)
wkB/s: 每秒写数据量(kB为单位)
avgrq-sz:平均每次IO操作的数据量(扇区数为单位)
avgqu-sz: 平均等待处理的IO请求队列长度
await: 平均每次IO请求等待时间(包括等待时间和处理时间,毫秒为单位)
svctm: 平均每次IO请求的处理时间(毫秒为单位)
%util: 采用周期内用于IO操作的时间比率,即IO队列非空的时间比率
 

对于以上示例输出,我们可以获取到以下信息:

每秒向磁盘上写30M左右数据(wkB/s值)
每秒有91次IO操作(r/s+w/s),其中以写操作为主体
平均每次IO请求等待处理的时间为120.57毫秒,处理耗时为6.33毫秒
等待处理的IO请求队列中,平均有11.79个请求驻留
 

以上各值之间也存在联系,我们可以由一些值计算出其他数值,例如:

util = (r/s+w/s) * (svctm/1000)

对于上面的例子有:util = (1+90)*(6.33/1000) = 0.57603

网络

  • mtr 命令
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,711评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,932评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,770评论 0 330
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,799评论 1 271
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,697评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,069评论 1 276
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,535评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,200评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,353评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,290评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,331评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,020评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,610评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,694评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,927评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,330评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,904评论 2 341

推荐阅读更多精彩内容