性能测试实战 30 讲
高楼
前 HP 高级性能专家,7DGroup 创始人
45941 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 37 讲
性能测试实战 30 讲
15
15
1.0x
00:00/00:00
登录|注册

18丨CentOS:操作系统级监控及常用计数器解析(下)

Swap监控及建议
Swap相关参数
中断和上下文切换
三次握手和四次挥手
Recv_Q和Send_Q
内存泄露分析
OOM Killer
内存监控
iotop工具
iostat工具
I/O基本逻辑过程
Swap
System
NetWork
Memory
I/O
操作系统监控数据的必要性
分析链路的重要性
监控平台的重要性
操作系统级监控及常用计数器解析
性能测试分析思考题
性能测试分析主题总结
性能测试分析

该思维导图由 AI 生成,仅供参考

在上一篇文章中,我们已经讲了监控系统层面的分析思路以及 CPU 分析,今天我们分析一下操作系统中其他的层面。
首先是 I/O。

I/O

I/O 其实是挺复杂的一个逻辑,但我们今天只说在做性能分析的时候,应该如何定位问题。
对性能优化比较有经验的人(或者说见过世面比较多的人)都会知道,当一个系统调到非常精致的程度时,基本上会卡在两个环节上,对计算密集型的应用来说,会卡在 CPU 上;对 I/O 密集型的应用来说,瓶颈会卡在 I/O 上。
我们对 I/O 的判断逻辑关系是什么呢?
我们先画一个 I/O 基本的逻辑过程。我们很多人嘴上说 I/O,其实脑子里想的都是 Disk I/O,但实际上一个数据要想写到磁盘当中,没那么容易,步骤并不简单。
这个简化的图是思虑再三的结果。
I/O 有很多原理细节,那我们如何能快速地做出相应的判断呢?首先要祭出的一个工具就是iostat
在这张图中,我们取出一条数据来做详细看下:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz
vda 0.00 0.67 18.33 114.33 540.00 54073.33 823.32
avgqu-sz await r_await w_await svctm %util
127.01 776.75 1.76 901.01 7.54 100.00
我解释一下其中几个关键计数器的含义。
svctm代表 I/O 平均响应时间。请注意,这个计数器,有很多人还把它当个宝一样,实际上在 man 手册中已经明确说了:“Warning! Do not trust this field any more. This field will be removed in a future sysstat version.” 也就是说,这个数据你爱看就爱,不一定准。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入介绍了CentOS操作系统级监控及常用计数器解析的相关内容。首先讨论了I/O性能分析,重点介绍了使用iostat和iotop工具来定位I/O性能问题。其次,强调了内存管理和监控的重要性,特别是关注available内存和内存泄露导致的性能问题。此外,还涉及了网络分析的内容,包括Recv_Q和Send_Q的判断以及网络瓶颈的定位。文章通过实际案例和工具的介绍,帮助读者了解了操作系统性能监控和分析的方法和技巧。 在讨论TCP的三次握手和四次挥手时,强调了半连接队列和全连接队列的重要性,以及与其相关的参数和操作系统内核参数。此外,对System的计数器和Swap进行了解释和分析,提出了关于Swap的建议。总结时强调了监控平台的重要性,以及性能分析需要全面的分析链和操作系统提供的监控数据的重要性。 总的来说,本文内容丰富,涵盖了操作系统性能监控和分析的多个方面,为读者提供了全面的技术知识和实用建议。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《性能测试实战 30 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(24)

  • 最新
  • 精选
  • 罗辑思维
    当操作系统中配置了vm.swappiness是 30%,那么当内存用到1-30%=70%的时候,就会发生 Swap。 高老师,文中对swappiness参数设置值描述跟倪鹏飞老师在专栏讲解有不一样的地方。个人还是认同swappiness不是内存的百分比。下面这段是摘自是倪鹏飞老师《Linux性能分析实战》第19讲。 --------------------------- /proc/sys/vm/swappiness 选项,用来调整使用 Swap 的积极程度。 swappiness 的范围是 0-100,数值越大,越积极使用 Swap,也就是更倾向于回收匿名页;数值越小,越消极使用 Swap,也就是更倾向于回收文件页。 虽然 swappiness 的范围是 0-100,不过要注意,这并不是内存的百分比,而是调整 Swap 积极程度的权重,即使你把它设置成 0,当剩余内存 + 文件页小于页高阈值时,还是会发生 Swap。

    作者回复: 仔细检查了一下。这个直接说是内存的百分比,确实不够精确。我之前看到过一些文章应该就是直接写的内存使用率百分比。 多谢指正,可以联系我,拿200块钱红包。 在这里更正如下: 在操作系统中,vm.swappiness是用来定义使用swap的倾向性。官方说明如下: swappiness This control is used to define how aggressive the kernel will swap memory pages. Higher values will increase agressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone. The default value is 60. 1. 值越高,则使用swap的倾向性越大。 2. 值越低,则使用swap的倾向性越小。 但这个倾向性是谁跟谁比呢?简单地说,在内存中有anon内存(匿名而链表,分为:inactive/active)和file内存(映射页链表,也分为:inactive/active),而swappiness是定义了对anon页链表扫描的倾向性。在linux源码vmscan.c中有这样的定义: /* * With swappiness at 100, anonymous and file have the same priority. * This scanning priority is essentially the inverse of IO cost. */ anon_prio = swappiness; file_prio = 200 - anon_prio; 也就是说如果swappiness设置为100时,则anon和file内存会同等的扫描;如果设置为0时,则file内存扫描的优先级会高。但是这并不是说设置为了0就没有swap了,在操作系统中还有其他的逻辑使用swap。 以后我会找个时间专门写一下这个逻辑。这里面涉及到几个部分的源代码逻辑,还是有点小复杂。

    2020-04-05
    2
    21
  • 木剑温华
    一个 TCP 连接大概占 3KB,创建 10 万个连接,才100000x3KB≈300M左右,何况最多才 65535 呢?服务器有那么穷吗? 这里感觉老师说的有一点问题,一个tcp链接由四元组组成:sip:sport---cip:cport,单机最多65535个端口,但是可以根据公式可以看到只影响了sport的数量,但是cip和cport的组合是无穷尽的,所以单机理论最大连接数远大于65535,我之前在iot项目和消息推送项目做过相关的压测,成功地把单机最大长连接数提高到100w以上。

    作者回复: 这里的描述有问题。我修改一下。 对客户端来说,会受到65535的端口数限制,对服务端来说不受端口数限制。

    2021-08-31
    9
  • SeaYang
    使用Linux服务器作为压力机,TPS达到比较高的时候压力机会大量报无法分配请求地址的错误,从而导致TPS直接降为0,命令看了下TIME_WAIT的数量很多,调整了一下几个内核参数,就解决了

    作者回复: 一看就是高手。

    2020-10-27
    3
  • aoe
    老师硬核调优!测试、开发、运维后期在操作系统、网络上都这么强了!

    作者回复: 性能是一个工程,从前到后。在我的思路中,不受职位限制。只看要达到的目标。哈哈。

    2020-10-14
    3
  • 月亮和六便士
    高老师,看完您的课程,有一些思路了,但是我发现思路和实战之间有一道鸿沟,我已经掉到沟里了,比如 分析的起点拆分响应时间,但是不知道怎么拆分,开发更是一头雾水。应用又是部署在docker里面,好不容易配置了个Tomcat监控,结果重启了一下配置又没了,运维说docker里没法暴露监控端口,真是寸步难行啊

    作者回复: 你这个是管理和沟通的问题,和技术无关。docker里当然可以暴露监控端口。 即使不这样,也得有其他的监控docker的手段。 技术角度来说,没有收拾不了的系统。

    2020-03-27
    3
  • 黑脸龙猫酱
    老师可否说下对于云服务器,io有些时间段不稳定的情况应该如何处理?

    作者回复: 云服务器都是虚拟机,如果你是被无良厂商超卖的话,那只能去骂街了。

    2020-03-16
    3
  • 小老鼠
    由于上下文切换过多引起性能降低的情形多吗?

    作者回复: 在我的工作经验中,上下文切换的问题排不到前五名。但是前十名还是有可能的。

    2020-02-18
    3
  • 悦霖
    高老师问一下,每次性能测试看io较高基本都是jbd2这个进程占用大量的IO,怎么进一步分析,而且这个jdb2是个啥?

    作者回复: 后面文章里会写到它。

    2020-02-18
    2
  • 闲鱼超人
    监控平台为什么不重要呢? 监控平台的主要用途是为了提供运行时状态数据给我们的,利用这些数据,我们分析性能情况。所以关键是数据、是证据链,是这些数据反馈出来的问题,这是核心。所以从这个角度来说,监控平台是不重要的,因为只要能提供这些你需要的数据,哪个平台都可以。

    作者回复: 是的。理解的很对。

    2021-02-24
    1
  • David.cui
    高老师讲的还是很透彻的,能分析到非常细微的差别。 高手!

    作者回复: 只有落地才是正道。

    2020-12-03
    1
收起评论
显示
设置
留言
24
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部