我们在AWS EC2上有T2实例（Linux 4.9.20-11.31.amzn1.x86_64），由于读取磁盘而耗尽了他们的I / O信用。 这可能是因为我们在这些节点上有过多的读取，所以对它本身并没有什么奇怪的，但是节点上的进程的结果是相当奇特的。 atop （v。1.27）捕捉到一个正常的，预期的小读数stream，直到i / o信用被耗尽，当atop -d 30开始长时间地看起来像这样：
PID TID RDDSK WRDSK WCANCL DSK CMD 10616 - 432.2M 0K 0K 24% consul 27629 - 313.3M 0K 0K 17% chef-client 27795 - 306.5M 0K 0K 17% python 27803 - 132.6M 0K 0K 7% crond
consul或crond （以及其他named dhclient甚至init样本）突然决定要读取数百MB的MB，似乎不大可能。 这种行为持续了大约一个小时，各个进程在这段时间内读取了100多MB。
什么可以解释这些高数字通常行为良好的过程？ 我认为读/proc/X/io read_bytes这些数字应该是相当准确的实际EBS活动？