我正在尝试弄清楚为什么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 使用率是否下降，但请记住，每种方法都会对写入磁盘的数据的安全性产生影响。您有有序模式、写回模式和“全部”模式。
- 已订购：日志仅有元数据，但确保在将元数据更改提交到日志之前保存与元数据相关的数据。
- 回写：journal 仅有元数据，但不能保证在 journal 提交之前保存数据。
- 杂志：所有内容，包括数据和元数据，都已记录。速度可能很慢，但 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
没有按顺序做，只是提一下：
mount -oremount,noatime /fs/being_over/journaled— 快速猜测一下（mount反正你也没告诉我们你长什么样子）- 尝试减小日志大小 (
tune2fs -J …) - 切换到瑞泽3（是的，很长一段时间都很强大。而且从来没有这么糟糕的日记。）