上周我一直在加载。 这通常每天发生一次或两次。 我已经设法从iotop确定[jbd2 / md1-8]正在使用99.99％的IO。 在高负载时间内，服务器没有高stream量。
服务器规格是：
除了尖峰，负载通常最多在0.80左右。
我search了一下，但无法find[jbd2 / md1-8]究竟做了什么。 有没有人有这个问题或有没有人知道一个可能的解决scheme？
谢谢。
更新：
TIME TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 16:05:36 399 be/3 root 0.00 B/s 38.76 K/s 0.00 % 99.99 % [jbd2/md1-8] 这不是一个真正的答案，因为没有足够的上下文来给出确切的原因，但是这是我在发生这种事情时如何跟踪这个事件的描述。
我注意到我的jbd2/md0-8不断出现在iotop的顶部。 我在/sys/kernel/debug/tracing/events/jbd2中查看了哪些选项来确定jbd2在做什么。
注意1：要查看debugging跟踪事件的输出cat /sys/kernel/debug/tracing/trace_pipe – 在启用/禁用跟踪的同时，我在terminal中运行了此命令。
注意2：为跟踪使用事件，例如echo 1 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable 。 要禁用echo 0 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable 。
我通过启用/sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable – 但是在输出中没有什么特别有趣的东西。 我试了一些其他的事件来跟踪，当我启用/sys/kernel/debug/tracing/events/jbd2/jbd2_commit_flushing/enable我看到它每秒都在发生：
# cat /sys/kernel/debug/tracing/trace_pipe ... jbd2/md0-8-2520 [004] .... 658660.216492: jbd2_commit_flushing: dev 9,0 transaction 32856413 sync 0 jbd2/md0-8-2520 [001] .... 658661.334900: jbd2_commit_flushing: dev 9,0 transaction 32856414 sync 0 jbd2/md0-8-2520 [001] .... 658661.394113: jbd2_commit_flushing: dev 9,0 transaction 32856415 sync 0
这看起来像是有关sync(2) / fsync(2) / msync(2) ，所以我寻找一些方法来链接到一个进程，发现这一点：
# find /sys/kernel/debug/tracing/events/ | grep sync.*enable ... /sys/kernel/debug/tracing/events/ext4/ext4_sync_file_enter/enable ...
当我启用它时，我看到以下输出：
# cat /sys/kernel/debug/tracing/trace_pipe ... nzbget-17367 [002] .... 658693.222288: ext4_sync_file_enter: dev 9,0 ino 301924373 parent 301924357 datasync 1 jbd2/md0-8-2520 [001] .... 658693.284080: jbd2_commit_flushing: dev 9,0 transaction 32856465 sync 0 nzbget-17367 [000] .... 658693.334267: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1 jbd2/md0-8-2520 [002] .... 658693.334275: jbd2_commit_flushing: dev 9,0 transaction 32856466 sync 0 nzbget-17367 [001] .... 658694.369514: ext4_sync_file_enter: dev 9,0 ino 301924367 parent 301924357 datasync 1 jbd2/md0-8-2520 [002] .... 658694.414861: jbd2_commit_flushing: dev 9,0 transaction 32856467 sync 0 nzbget-17367 [001] .... 658694.470872: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1 jbd2/md0-8-2520 [002] .... 658694.470880: jbd2_commit_flushing: dev 9,0 transaction 32856468 sync 0
这给了我进程的名称/编号 – 并在做这个过程（ nzbget ）的一些更多的debugging后，我发现它nzbget做fsync(2) 。 当我改变它的configuration（ FlushQueue=no ，无证，我认为，发现它在源），以阻止它每秒这样做fsync(2)问题消失了。
我的内核版本是4.4.6-gentoo 。我认为我在某些时候在内核configuration中启用了一些选项（手动或者使用make oldconfig ）来获得/sys/kernel/debug这些事件 – 所以如果你不有没有它可能只是在互联网上查看有关启用它的更多信息。
这似乎是一个日记更新相关的事情。 软件RAID由多less个磁盘组成。 你能告诉我用来创build它的命令吗？
你也可以pastebin dumpe2fs输出。 首先，确定你看到负载的物理设备。 使用df知道这一点。 然后，
dumpe2fs /dev/sdaX > /tmp/dump
对于你的情况，它可能是/ dev / md0。
另外，运行这个。
iostat -xdk 1 25
在高IO问题的时候。
我不知道cloudlinux，而是它下面的工具blktrace。