专栏首页皮振伟的专栏[linux][atop]atop的改进和在统计io上遇到的问题

[linux][atop]atop的改进和在统计io上遇到的问题

前言 互联网公司一般都会运行着几千到几万的服务器。一般的监控会采用类似ganglia/falcon类似的工具,在本地启动一个agent,把数据统计上报到集中式的服务器中,用来监控和分析系统的问题。 另外,有atop这样的工具,可以运行在服务器上,在本地写下record文件,atop命令本身也可以分析record文件,其中保存的数据的粒度更加细致,可以精确到线程级别,还有IPC,主频等等。 经验来看,atop每天生成的record文件大约500M左右,保存最近的一段时间,似乎也不是问题。用集中式的监控,配合上atop,对于问题分析来说,会有一些帮助。 分析 1,atop的改进 atop的代码量本身并不大,官方的代码在: https://github.com/Atoptool/atop.git 在使用atop的过程中,遇到了一些问题,作者也做了相应的修改: https://github.com/bytedance/atop 在bytedance-features分支上。作者把patch发送给maintainer,但是maintainer一直没有回复。在这里,列举一下改动的内容,如下。 2,smaps的优化 尝试使用smaps_rollup代替smaps,用来提高atop收集进程的PSS内存使用的效率。这个patch会在4.14上有所提升。一般情况下,建议在atop收集的时候不要加上-R选项。因为在atop读/proc/PID/smaps的时候,会walk整个PID进程的页表,期间会lock住内存页表的锁。如果在这期间PID进程发生了page fault,也需要lock,就会造成锁的进程。影响PID进程的性能。 3,数据破损问题 atop使用裸数据的方式保存record文件,其中包括三部分:raw record,就是头信息; scompbuf,是系统状态信息的数据; pcompbuf,是task级的状态信息数据,大小和task数量有关系。为了减小record文件的大小,对于 scompbuf和pcompbuf还采用了压缩。所以,数据必须完整的 rr,scompbuf,pcompbuf顺序写下去的,否则atop无法识别数据。 good case : ... rr,scompbuf,pcompbuf ... rr,scompbuf,pcompbuf ... bad case : ... rr,scompbuf[missing] ... rr,scompbuf,pcompbuf … 例如上面的例子,在写完rr,scompbuf之后,atop发生了crash,再重新启动,就会丢失后面的 pcompbuf,造成了整个record文件的不可用。 在patch中,作者使用writev进行写入数据,要么都写入成功,要么都写入不成功,用来防止这种case发生。 4,IPC造成的虚拟机性能抖动 IPC,instructions per cycle。可以用来衡量CPU运行的效率。通常是通过perf采集的数据。 提到perf,就要说明一下它的工作原理:intel的CPU上集成了PMU,用来采集硬件的信息。可以收集的硬件信息很多,可以通过perf list | grep Hardware来看。但是硬件的寄存器有数量限制,所以需要通过wrmsr指令告诉CPU收集哪些具体的事件,再通过rdpmc指令来读取对应的数据。 在虚拟化场景下,在虚拟机中使用PMU又复杂了一下,在虚拟机中执行wrmsr和rdpmc的时候,都需要虚拟机从none-root模式退出,影响了虚拟机的性能。 在patch中,作者让atop支持perfevents的配置,支持三种模式:enable模式,启用perf收集IPC。disable模式,禁用perf收集IPC。auto模式,在启动的时候,atop自动检查是否在虚拟机中运行,如果在虚拟机中,禁用;在物理级中,启用。默认是auto模式。 5,减小record文件 如果是大规格的服务器,40CPU,甚至到96CPU,通常运行大量的docker,里面运行了很多的task。其中很多task占用资源很少,但是依然会占用atop的record文件。 在patch中,支持了配置参数recordcputop & recordmemtop。用来配置收集cpu和内存的topN。其他的task可以忽略。作者测试线上的服务器36CPU, about 500 processes的场景,大约节省了40%的磁盘空间。 6,加速读record 一般在ganglia上看到系统抖动,例如下午三点十分,在对应的服务器上执行: atop -r / var/log/atop/atop_xxxx -b 15:10 如前文所述,因为rawrecord的原因,则会从头读到尾,直到匹配到对应的时间。对于log盘的使用,尤其是虚拟化场景,会限制IOPS。这样会让atop -r操作非常耗时,有时会在几分钟这个级别。 在patch中,作者通过posix_fadvise POSIX_FADV_SEQUENTIAL加大kernel的readahead buffer。同时会每次尽量读4M到page cache中,降低对IOPS的限制。作者的测试结果显示3595 records在30 IOPS的情况下,原来需要101.7s,现在需要3.4s。 7,其他的改进 原来的代码中有很多warning,作者都fix掉了。 用astyle format源代码,看着舒服一些。 8,io accounting问题 linux提供了io accounting能力,对应的就是在/proc/PID/io,如下:

atop也是从/proc/PID/io目录下收集数据,做差计算出来io的情况。atop -d的展示中,

需要注意的是,DSK列的比例,指的是在这段时间内的io情况占比,对应的就是图中的144K,20K,20K的和中占比情况,并不代表消耗磁盘IO的能力的情况。

如图,统计的是3s时间间隔的数据。左图中的DSK sdb消耗还好,但是dd的io已经到达了1G。右图中的DSK sdb消耗已经到达了100%,但是dd的io是695.7M。而且均大于sdb的上限的写入带宽。可见io accounting的统计数据,并非是落盘的数据,而是发生io的数据,因为page cache的原因,异步落盘导致io发生的时间和最后落盘的时间不一致。

如右图所示,bash进程统计到了3.1G的io。那么问题来了,bash什么都没有做。那么io从哪里来的呢?

这里,我们需要纠结一下io accounting的统计逻辑,代码选自linux-4.14/fs/proc/base.c

可见,在统计进程的io accounting的时候,会统计task->signal->ioac之后,再遍历所有的thread,进行加和加算。 再结合linux-4.14/kernel/exit.c来看,在子进程退出的时候,父进程wait的操作中,会把子进程的IO情况统计到父进程的task->signal->ioac中。那么就是,dd进程执行之后,bash执行了wait,把dd的io accounting统计到了bash的task->signal->ioac中。 在服务器上,通常会以daemon的方式启动,也就是说,systemd进程作为daemon的父进程。在daemon退出或者被杀掉的时候,systemd的io有一次暴涨,但是实际上并没有发生io。

本文分享自微信公众号 - AlwaysGeek(gh_d0972b1eeb60),作者:AlwaysGeek

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-04-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Linux实用监控工具 atop

    atop就是一款用于监控Linux系统资源与进程的工具,它以一定的频率记录系统的运行状态,所采集的数据包含系统资源(CPU、内存、磁盘和网络)使用情况和进程运行...

    Ronald-Leung
  • [linux][system]atop的介绍和使用

    前言 Linux上运行大量的后端的业务程序,往往希望得到更快的响应速度,更小的延迟,甚至有严格的PCT 99的指标。而操作系统的复杂度很高,多个因子之间可能会互...

    皮振伟
  • 腾讯云cvm的关于监控指标的相关解释

    平常处理服务器的问题遇到的最多的是负载高了,内存高了,io高了等问题,这里最明显的表现就是相关的监控指标了,对于诊断这种问题起到事半功倍的效果。

    云售后焦俊成
  • 每天学一个 Linux 命令(117):atop

    atop 命令是一款监控 Linux 系统资源与进程的工具,非内部命令,需要安装。

    民工哥
  • atop使用介绍

    atop用来监控系统资源与进程的工具,默认是以10s为间隔,来记录系统的运行状态,并且会以每隔10分钟记录一次采集数据到日志中。

    dogfei
  • Linux性能回溯工具-sysstat、atop、oswatch、nmon

    在企业应用中,除了经常会用到企业级的性能监控和告警工具(如nagios、zabbix、Prometheus),还会在服务器设备出现性能问题时,可以通过部署一些可...

    start.zhou
  • Linux atop监控

    atop是一个功能非常强大的linux服务器监控工具,它的数据采集主要包括:CPU、内存、磁盘、网络、进程等,并且内容非常的详细,特别是当那一部分存在压力它会以...

    sunsky
  • [Linux][kernel]sched delay和steal time的原理分析以及atop的监控改进

    前言 在虚拟化场景下,经常会用到steal time来判断虚拟机的vCPU执行是否被抢占,进而来衡量虚拟机的性能指标。同时,在延迟敏感型的业务上(例如redis...

    皮振伟
  • [Linux][mm]TLB shootdown和读取smaps对性能的影响 ​

    作者遇到了业务的一个性能抖动问题,在这里介绍一下它的原因和解决办法。 分析 1,page fault 在Linux上,进程分配到的内存是虚拟内存,经过内核...

    皮振伟

扫码关注云+社区

领取腾讯云代金券