☰

kjournald 使用率高的原因

tag-icon • tag-icon linux filesystems tuning kjournald
kjournald 使用率高的原因

我正在尝试弄清楚为什么kjournald我的机器会发疯。这是一个 8 核机器，内存很大。它的 CPU 负载约为 50%。

iotop 似乎没有指向任何特定的进程 - 这里和那里有一些写入突发（主要是 cron 启动、生成的一些监控统计数据等）当我过去sys/vm/block_dump收集写入统计数据时，我得到了如下列表：

kjournald(1352): 1909
sendmail(28934): 13
cron(28910): 12
cron(28912): 11
munin-node(29015): 3
cron(28913): 3
check_asterisk_(28917): 3
sh(28917): 2
munin-node(29022): 2
munin-node(29021): 2

其中的kjournald操作仅仅是写入。

为什么会发生这种情况？我还应该注意什么来稍微限制一下 kjournald 活动？这似乎与实际写入的内容不成比例。

答案1

kjournald负责 ext3（日志文件系统）的日志。众所周知，在某些负载下，它会占用大量 CPU。除了使用其他文件系统或禁用日志功能（实际上使 fs 成为 ext2）外，没有太多可做的事情。

理论上，您可以使用 ext3 日志的其他模式之一并检查 CPU 使用率是否下降，但请记住，每种方法都会对写入磁盘的数据的安全性产生影响。您有有序模式、写回模式和“全部”模式。

  1. 已订购：日志仅有元数据，但确保在将元数据更改提交到日志之前保存与元数据相关的数据。
  2. 回写：journal 仅有元数据，但不能保证在 journal 提交之前保存数据。
  3. 杂志：所有内容，包括数据和元数据，都已记录。速度可能很慢，但 YMMV。

data=您可以在挂载系统时使用选项设置模式，例如data=ordered。

答案2

默认情况下，您的 ext3 文件系统将在启用 atimes 的情况下挂载。每次读取/访问文件或目录时，文件系统都必须写回磁盘以更新此 atime 记录。这意味着即使您的工作负载主要是读取，您仍然需要访问磁盘来更新每个文件和目录的访问时间，这就是我猜测您的kjournald进程写入如此多块的原因。

关闭 atime 将大大提高性能，但会破坏 POSIX 兼容性。查看这篇维基百科文章围绕对 atime 的批评进行一些讨论。

要关闭 atimes，只需将其添加noatime到文件系统的挂载选项中，或者您可以按照 poige 的建议重新挂载。以下是您的根文件系统的示例：

mount -o remount,noatime /

答案3

如果数据的完整性并不重要：这样做

iostat -o -a

确保它确实是 kjournald。它导致我的服务器崩溃。

将硬盘更换为 SSD 即可。

当你看到 kjournald 写入 5-10MB 的数据时

http://ubuntuforums.org/showthread.php?t=56621

sudo tune2fs -O ^has_journal /dev/sda1
sudo e2fsck /dev/sda1

其中 sda1 是分区的名称

在评论中报告结果，以便我可以进一步检查。

答案4

没有按顺序做，只是提一下：

  1. mount -oremount,noatime /fs/being_over/journaled— 快速猜测一下（mount反正你也没告诉我们你长什么样子）
  2. 尝试减小日志大小 ( tune2fs -J …)
  3. 切换到瑞泽3（是的，很长一段时间都很强大。而且从来没有这么糟糕的日记。）

相关内容