[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。