主页 / unix / 问题 / 793914
Accepted
AlanQ
Asked: 2025-04-19 01:53:00 +0800 CST

systemd-journald 平均每小时写入 16MB！

  • 772

操作系统：Ubuntu MATE 24.04.2 LTS

我在顶部面板添加了系统监视器，发现磁盘活动非常多。
起初我以为主要的“罪魁祸首”是jbd2——日志块设备。
但 jbd2（“一种在系统崩溃时保护文件系统免受元数据不一致影响的日志”）应该只会在响应其他写入磁盘的操作时才写入磁盘。
运行后sudo iotop -a，我发现 (*) 写入磁盘的主要对象是systemd-journald：在 3 小时 40 分钟内，它写入了 60MB！

我知道这是二进制数据，但是，如果它是文本，即使每个字符有 4 个字节，那么每 7 小时就会出现一次“战争与和平”！

  • 这是‘正常’的吗？
  • 写什么需要这么多数据？
  • 我应该担心我的 SSD 系统盘吗？
  • 我可以（安全地）减少写入数据的数量（和频率）吗？

(*) 尽管 Firefox 是个怪物

ubuntu

2 个回答

  1. Best Answer

    我想在你的问题下发表很多评论，但是 a) 那样就太多了，并且 b) 可能相当于你想从答案中知道的内容，即使它主要不是集中于回答你的离散问题。

    那么，下面是答案。

    sudo iotop -a[…] systemd-journald：经过 3 小时 40 分钟，写入了 60MB！

    你把吞吐量和累积数据混淆了。如果我的程序（这里是 Python，但任何编程语言都可以）

    f = open("somelogfile.bin", "wb")
while(True):
  f.seek(0)
  f.write(b"x")

    当您仅计算每秒写入的字节数时，该程序每秒会写入许多兆字节，但它实际上所做的就是一遍又一遍地更新第一个字节。ls -l somelogfile.bin会告诉您该文件有 1 B 大。

    systemd-journal 二进制日志格式的一个特点是

    • 可寻址和
    • 相对而言具有防撞安全性。

    为了实现这一点，即使没有添加新数据，它也可能会定期更新某些字段。（格式是公开文档，我懒得查了。）

    （请注意，写入缓冲区可能会进一步使更新文件和将文件写入磁盘之间的关系复杂化。）

    现在，首先检查一下：你的日志到底有多大？journalctl --disk-usage会告诉你大约 512 MB（至少在我的机器上是这样的）。这个数字会是一个循环常数，因为当日志足够旧并且你的运行超过了某个大小阈值时，systemd-journald 会清理之前的日志。

    接下来，检查记录的内容中到底发生了什么：

    journalctl -b0 -x -f -e
#          ^   ^  ^   ^
#          |   |  |   |
#          \———————————— 0: current boot's logging only
#              |  |   |  (ignore things that were logged during previous boots)
#              |  |   |
#              \———————— add a bit more explanation
#                 |   |
#                 \————— follow the output as it comes in live
#                     |
#                     \— scroll to end

    将显示你的系统日志。添加--user以查看你的用户服务日志。

    是否有东西高速滚动？如果没有，那么就没有新内容被记录。如果是，那就是问题所在，而不是你的日志系统！（别怪罪信使。）

    如果同时发生太多事情，可以获取一些统计数据，了解自上次启动以来记录了多少条消息

    journalctl -b0 --output=cat --output-fields=UNIT | sort | uniq --count | sort -n

    在该命令行中，您已经认识到-b0其含义为“当前启动”，--output=cat告诉journalctl它输出未格式化的文本，并--output-fields=UNIT告诉它仅输出记录消息的单元（不是消息，不是时间戳等）。sort按字母顺序排序，uniq -c获取排序后的输入并打印连续相同行的数量，最后sort -n按数字对输出进行排序。

    我应该担心我的 SSD 系统盘吗？

    我无法告诉你。但我的固态硬盘额定写入容量为 3PB，平均故障时间 (MTTF)，所以假设你有一个容量较小、内存质量较差的固态硬盘，它的额定 MTTF 为 0.5PB。这意味着，以 16MB/小时的速度，

    0.5·10¹⁵ B /（16·10⁶ B/h）= 31250000 小时 = 3567.4 一年；

    换句话说，如果有 1000 个磁盘经历这种写入负载，那么 3567 年后，其中 500 个磁盘将发生故障。

    你有一块磁盘。你需要假设一个硬盘故障时间的统计模型（显然，它们不会在 3567 年内的同一秒全部发生故障。有些会更早，有些会更晚，问题在于其分布*），而没有人知道具体时间（数据中心 SSD 制造商可能会与其知名客户分享他们的统计数据；谷歌自己也拥有足够的统计数据来估算这一点。我们只是无从得知。）

    设备故障的常见统计模型是指数模型（灯泡不可能两次故障）。这个模型在这里可能在细节上并不准确（这是由于磨损均衡，需要转换单个闪存单元的故障模型），但这是一个起点。它具有累积分布函数：

    F（t，λ）= 1- e - λt，

    其中t是时间，λ是速率，我们还不知道。

    但“平均故障时间”的含义是，

    F（t MTTF，λ）= 0.5，

    所以（log 是自然对数）

          0.5 = 1 - e - λt MTTF
          0.5 = e - λt MTTF
    log 0.5 = log e - λt MTTF
                = - λt MTTF · log e
                = - λt MTTF，

    认识到

    λ = - log 0.5 / t平均无故障时间，

    在我们的例子中，

    λ = - 0.693147 / 3567.4 [1/a] = 0.00019430 / a。

    代入原始累积密度函数，

    F（t）= 1- e- 0.00019430· t，

    这意味着在实际使用寿命t =15 年后，您的 SSD 仍能正常工作的概率为 0.99709；换句话说，如果您的低质量 SSD 以这种速率只进行日志写入，则在 15 年内，有 3/1000 的概率，它将因写入负载而失效。

    你很好。

    • 3

  2. 这不是什么问题systemd-journald，只是日志记录了太多内容。检查一下日志里的内容：

    journalctl -xef

    如果您不需要这些日志，请尝试在将它们发送到日志之前将其丢弃。

    如果重启后不需要日志，您可以将其添加Storage=volatil到您的日志/etc/systemd/journald.conf并重新启动日志：systemctl restart systemd-journald。

    • -1

相关问题