【Linux】接口机磁盘读写极度不均衡的原因分析

在进行服务器接口机的资源梳理时&＃xff0c;发现一个现象——接口服务器的磁盘IO中&＃xff0c;数据写入的流量远大于读取流量&＃xff0c;实时的监控图表如下&＃xff1a;

实时在服务器使用iotop命令查看读写情况&＃xff0c;也能看到差异是非常大的&＃xff1a;

Total DISK READ : 75.31 K/s | Total DISK WRITE : 77.38 M/s
Actual DISK READ: 96.82 K/s | Actual DISK WRITE: 1117.56 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
19969 be/3 root 0.00 B/s 1061.48 K/s 0.00 % 78.56 % [jbd2/sdb1-8]
104428 be/4 root 39.45 K/s 0.00 B/s 0.00 % 75.63 % [kworker/u449:0]
158908 be/4 user 35.86 K/s 0.00 B/s 0.00 % 64.11 % sshd: user&＃64;internal-sftp
350 be/4 root 0.00 B/s 25.73 M/s 0.00 % 57.42 % [kswapd0]
178091 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.03 % [kworker/35:2]
226695 be/4 user 0.00 B/s 3.59 K/s 0.00 % 0.01 % java -Dzookeeper.log.dir&＃61;/data1/app/zookeeper~/zookeeper/zookeeper-3.5.9/bin/../conf/zoo.cfg
18862 be/4 user 0.00 B/s 50.55 M/s 0.00 % 0.01 % java -classpath /data1/app/nifi/nifi-1.16.3/.~app/nifi/nifi-1.16.3/logs org.apache.nifi.NiFi
19999 be/3 root 0.00 B/s 39.45 K/s 0.00 % 0.00 % auditd
138967 be/4 root 0.00 B/s 3.59 K/s 0.00 % 0.00 % rsyslogd -n


基于此问题&＃xff0c;还是需要进行一下分析&＃xff0c;理解一下为什么会出现这个现象。

数据写入磁盘的过程

针对这个现象&＃xff0c;第一个切入点其实不是进程的io占用&＃xff0c;因为监控和iotop的表现基本一致&＃xff0c;说明实际是有这么高的数据写入需求&＃xff1b;

然后另一个需要注意的特征点是&＃xff0c;在这样巨大差异的场景下&＃xff0c;业务数据也是正常传输的&＃xff0c;因此&＃xff0c;首先要去想清楚&＃xff0c;写入的数据和读取得数据是怎么发生的&＃xff1b;

根据iotop的信息显示&＃xff0c;发现pid为18862的进程会长期占用大量的Write资源&＃xff1a;

[root&＃64;hostname ~]# ps -ef|grep 18862
user 18862 18785 99 2022 ? 660-04:39:50 /usr/jdk64/jdk1.8.0_112/bin/java -classpath /data1/app/nifi/nifi-1.16.3/./conf:/data1/app/nifi/nifi-1.16.3/./lib/logback-core-1.2.11.jar:/data1/app/nifi/nifi-1.16.3/./lib/nifi-properties-1.16.3.jar:/data1/app/nifi/nifi-1.16.3/./lib/logback-classic-1.2.11.jar:/data1/app/nifi/nifi-1.16.3/./lib/jetty-schemas-5.2.jar:/data1/app/nifi/nifi-1.16.3/./lib/log4j-over-slf4j-1.7.36.jar:/data1/app/nifi/nifi-1.16.3/./lib/nifi-framework-api-1.16.3.jar:/data1/app/nifi/nifi-1.16.3/./lib/nifi-nar-utils-1.16.3.jar:/data1/app/nifi/nifi-1.16.3/./lib/nifi-runtime-1.16.3.jar:/data1/app/nifi/nifi-1.16.3/./lib/jcl-over-slf4j-1.7.36.jar:/data1/app/nifi/nifi-1.16.3/./lib/slf4j-api-1.7.36.jar:/data1/app/nifi/nifi-1.16.3/./lib/nifi-property-utils-1.16.3.jar:/data1/app/nifi/nifi-1.16.3/./lib/javax.servlet-api-3.1.0.jar:/data1/app/nifi/nifi-1.16.3/./lib/jul-to-slf4j-1.7.36.jar:/data1/app/nifi/nifi-1.16.3/./lib/nifi-server-api-1.16.3.jar:/data1/app/nifi/nifi-1.16.3/./lib/nifi-api-1.16.3.jar:/data1/app/nifi/nifi-1.16.3/./lib/nifi-stateless-bootstrap-1.16.3.jar:/data1/app/nifi/nifi-1.16.3/./lib/nifi-stateless-api-1.16.3.jar -Dorg.apache.jasper.compiler.disablejsr199&＃61;true -Xmx48g -Xms48g -Dcurator-log-only-first-connection-issue-as-error-level&＃61;true -Djavax.security.auth.useSubjectCredsOnly&＃61;true -Djava.security.egd&＃61;file:/dev/urandom -Dzookeeper.admin.enableServer&＃61;false -Dsun.net.http.allowRestrictedHeaders&＃61;true -Djava.net.preferIPv4Stack&＃61;true -Djava.awt.headless&＃61;true -XX:&＃43;UseG1GC -Djava.protocol.handler.pkgs&＃61;com.dtsw -Dnifi.properties.file.path&＃61;/data1/app/nifi/nifi-1.16.3/./conf/nifi.properties -Dnifi.bootstrap.listen.port&＃61;22995 -Dapp&＃61;NiFi -Dorg.apache.nifi.bootstrap.config.log.dir&＃61;/data1/app/nifi/nifi-1.16.3/logs org.apache.nifi.NiFi


根据ps查询的结果&＃xff0c;这是一个nifi进程&＃xff0c; 那么它应该就是产生数据流向的主要进程了&＃xff1b;

接下来从这个进程出发&＃xff0c;我们继续探寻IO差异的原因&＃xff1b;

在这里&＃xff0c;我们首先要知道Linux进行数据读写时的流程&＃xff0c;这将有助于我们进一步定位这个问题&＃xff0c;首先&＃xff0c;让我们思考一个问题&＃xff1a;

当我们在Linux写入一个文件的时候&＃xff0c;文件是直接写入磁盘的吗&＃xff1f;

既然我问出来这个问题&＃xff0c;那么你一定会回答“不是”&＃xff0c;既然不是的话&＃xff0c;这个流程应该是怎样的&＃xff1f;

实际上&＃xff0c;对于操作系统的操作而言&＃xff0c;提高文件写入性能的一个简单方法是让操作系统缓存数据&＃xff0c;这个时候会告诉应用程序文件是写入了的&＃xff0c;然后再异步的执行写入操作&＃xff1b;

这样如果同时有其他磁盘活动将会非常高效&＃xff0c;操作系统可以优先读取并稍后执行写入操作。并且在极端情况下还可以完全消除实际写入的需要&＃xff0c;例如&＃xff0c;在临时文件很快被删除的情况下。

当然&＃xff0c;像这样的缓存也有缺点&＃xff0c;我们可以想象到&＃xff0c;极端情况下&＃xff0c;我还没有在终端确认保存操作&＃xff0c;那么有些数据可能在真正保存之前就丢失了。

如果编辑器告诉用户写入成功&＃xff0c;但文件实际上不在磁盘上&＃xff0c;在业务逻辑上一定是不正确的。这就是为什么会有fsync()之类的系统调用&＃xff0c;在向用户报告写入成功之前&＃xff0c;文件操作程序可以使用它来确保数据正常。

NIFI使用本地磁盘的特性

ok&＃xff0c;了解了文件的读写大致流程&＃xff0c;我们现在可以顺理成章的给出一个能够和nifi特性匹配的推测&＃xff1a;

在配置了本地磁盘作为Content Repository之后&＃xff0c;当nifi从A服务器拉取一个数据的时候&＃xff0c;在本地会落盘一次&＃xff0c;于是数据会写入缓存&＃xff0c;下游的nifi推送组件&＃xff08;或者别的需要使用这个文件的流程&＃xff09;可以直接从缓存中拿到这个文件&＃xff0c;而不需要产生新的IO操作&＃xff1b;

这里的大前提就是nifi的nifi.content.repository.implementation配置项使用的默认值org.apache.nifi.controller.repository.FileSystemRepository&＃xff1a;

# Content Repository
nifi.content.repository.implementation&＃61;org.apache.nifi.controller.repository.FileSystemRepository
nifi.content.claim.max.appendable.size&＃61;50 MB
nifi.content.repository.directory.content1&＃61;/data1/app/nifi/nifi_repository/content_repository
nifi.content.repository.directory.content2&＃61;/data2/app/nifi/nifi_repository/content_repository


个别的环境可能这个值配置成了VolatileContentRepository&＃xff0c;按照现在的推测&＃xff0c;这种配置下不会出现write远大于read的情况&＃xff0c;因为write本身也不会落盘&＃xff0c;所有操作都在内存中进行&＃xff1b;当然&＃xff0c;如果出发了极端操作&＃xff0c;也可能会产生上述现象&＃xff0c;具体的需要进一步测试&＃xff0c;暂且不提&＃xff1b;

PageFaults带出的缓存使用

现在我们有了一个大概的推测&＃xff0c;接下来我使用pidstat命令针对nifi的进程进行进一步的排查&＃xff1a;

这里注意几个值&＃xff0c;一个是minflt/s还有一个是kB_rd/s&＃xff1b;

后者可以很好的理解&＃xff0c;是从磁盘读的数据量&＃xff0c;单位kB&＃xff0c;和监控的情况保持一致&＃xff0c;基本没有读&＃xff0c;只有写&＃xff08;kB_wr/s&＃xff09;&＃xff1b;

那么minflt这个值为什么要关注呢&＃xff1f;这个指标的含义是什么&＃xff1f;

minflt即minor page faults&＃xff0c;通过man文档我们可以查询到这个指标的解释&＃xff1a;

Total number of minor faults the task has made per second, those which have not required loading a memory page from disk.

直译过来就是每秒发生的次要错误总数&＃xff0c;这些错误不需要从磁盘加载内存页&＃xff1b;这里的错误指的就是页面错误&＃xff0c;想要理解这个指标的含义&＃xff0c;我们就要多了解一下页面错误是什么。

我们知道&＃xff0c;操作系统使用分页在主存储器和辅助存储器之间传输数据&＃xff08;主存储器就是RAM内存&＃xff0c;CPU可以直接访问&＃xff0c;辅助存储器通俗来说就是我们常说的磁盘&＃xff09;以实现高效的内存管理&＃xff1b;

页(内存/虚拟页)是正在运行的进程的一部分&＃xff0c;表示一个逻辑内存单元&＃xff1b;内存中包含单个进程页的物理部分称为帧&＃xff1b;所有帧都是固定长度&＃xff0c;允许非连续(非共享)分配物理内存地址空间&＃xff1b;

而我们所说的页错误&＃xff08;page fault&＃xff09;是由内存管理单元引发的异常&＃xff0c;当进程需要访问其地址空间内的数据时&＃xff0c;它无法加载物理内存&＃xff1b;

异常通常指示计算机在虚拟内存中找到该数据块&＃xff0c;这样它就可以从存储设备发送到物理内存&＃xff1b;page fault其实很常见&＃xff0c;通过提高程序的内存分配&＃xff0c;通常有助于提高性能&＃xff1b;

minor page faults&＃xff0c;也称为软错误&＃xff0c;发生在内存页由多个程序共享时&＃xff0c;其中一些程序已经将该页带到主内存中&＃xff1b;也就是说&＃xff0c;在访问一个地址时&＃xff0c;与之绑定的虚拟内存空间对应的地址空间已经被内核加载到了Page Cache中&＃xff0c;那么此时只需要把该Page映射到vma中即可&＃xff1b;

现在&＃xff0c;让我们回到pidstat的跟踪排查结果上来&＃xff0c;minflt发生的非常频繁&＃xff0c;说明需要操作的数据总是能从缓存中找到&＃xff0c;所以&＃xff0c;实际上并不会产生大量的磁盘io读操作。

问题的最终定论

现在&＃xff0c;我们需要使用一些小手段&＃xff0c;手动的介入缓存的使用&＃xff0c;尽可能的在数据读入缓存后清理除去&＃xff0c;我们使用sync命令调用响应的页回刷的函数&＃xff0c;同时观察到磁盘的读操作一下变多了&＃xff1a;

这样看可能并不直观&＃xff0c;让我们结合已有的监控进行观察&＃xff1a;

尽管只有很短的时间&＃xff0c;但是我们可以看到磁盘的读写流量基本是持平了&＃xff1b;

这就是因为我们手动介入&＃xff0c;尽可能的在nifi将数据拉取过来时&＃xff0c;从内存中把对应的数据刷写磁盘并清空缓存&＃xff0c;导致下游的读取需要再走一次磁盘&＃xff1b;由此产生了大量的read流量&＃xff0c;并且&＃xff0c;随着程序运行&＃xff0c;缓存会逐渐增多&＃xff0c;所以后续read流量越来越少&＃xff0c;逐渐变成之前的状态了。

极端状态下&＃xff0c;如果没有缓存机制&＃xff0c;真正意义上read和write是持平的。