☰

服务器负载过高 - [jbd2/md1-8] 使用 99.99% IO

tag-icon • tag-icon linux software-raid high-load
服务器负载过高 - [jbd2/md1-8] 使用 99.99% IO

过去一周，我的负载一直处于峰值状态。这种情况通常每天发生一两次。我设法从 iotop 中识别出 [jbd2/md1-8] 的 IO 使用率为 99.99%。在高负载期间，服务器的流量并不高。

服务器规格为：

  • AMD Opteron 8 核
  • 16 GB 内存
  • 2x2.000 GB 7.200 RPM HDD 软件 Raid 1
  • Cloudlinux + Cpanel
  • Mysql 已正确调整

除了尖峰之外，负载通常最多在 0.80 左右。

我搜索了好久，但还是找不到 [jbd2/md1-8] 的具体作用。有人遇到过这个问题吗？或者有人知道可能的解决方案吗？

谢谢。

更新：

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]

答案1

这不是一个真正的答案，因为没有足够的背景信息来给出确切的原因，但它描述了我在这件事发生在我身上时如何设法追踪它。

我注意到我的jbd2/md0-8一直出现在 的顶部iotop。我查看了/sys/kernel/debug/tracing/events/jbd2有哪些选项可以确定jbd2发生了什么。

注 1：要查看调试跟踪事件的输出cat /sys/kernel/debug/tracing/trace_pipe- 我在启用/禁用跟踪时在终端中运行它。

注 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

这给了我进程名称/ID - 在对此进程进行更多调试之后（nzbget），我发现它fsync(2)每秒都在执行。在我更改其配置（FlushQueue=no我认为没有记录，在源代码中找到）以阻止它每秒执行此操作后fsync(2)，问题就消失了。

我的内核版本是。我认为在内核配置的某个阶段4.4.6-gentoo我启用了一些选项（手动或使用）来处理这些事件 - 所以如果你没有它，也许只需在互联网上查找有关启用它的更多信息。make oldconfig/sys/kernel/debug

答案2

这似乎与日志更新有关。软件 RAID 由多少个磁盘组成。您能向我展示创建它的命令吗？

您也可以将 dumpe2fs 输出粘贴到 pastebin 中。首先，确定您看到负载的物理设备。使用 df 可以知道这一点。然后，

dumpe2fs /dev/sdaX > /tmp/dump

对于您的情况，它可能是 /dev/md0。

另外，运行这个。

iostat -xdk 1 25

出现高 IO 问题时。

我不知道 cloudlinux 但是它下面是否有可用的工具 blktrace。

相关内容