为何atop中systemd --user实例短时间磁盘占用达数百MB？

刚用atop -r /var/log/atop/atop_20180216抓到systemd --user在10分钟内有几百MB磁盘占用，还包含数十MB写入和300MB读取，这种情况其实挺常见的，大概率是下面这些场景之一：

• 用户级日志的轮转与归档
  systemd --user会管理你个人会话里的所有服务日志，要是你开了不少桌面后台服务或者自启动程序，这些服务的日志会不断累积。systemd默认的日志轮转机制会定期读取旧日志文件、压缩归档，这就对应了你看到的大读取量（读旧日志）和写入量（写压缩后的归档文件）。你可以用journalctl --user --disk-usage看看用户日志的磁盘占用情况，再用journalctl --user --list-boots检查有没有频繁的日志轮转记录。

• 用户服务的状态监控与同步
  systemd --user的核心工作就是维持你会话里的服务生命周期，它会定期扫描服务的配置文件、状态文件来确保服务正常运行。如果有服务频繁重启、配置文件被修改，或者某些服务会频繁更新状态文件，systemd就会反复读取这些文件，累积起来就有了300MB的读取量。要是有服务异常崩溃，systemd还会写入详细的状态记录到磁盘，带来额外的写入量。

• 用户缓存与临时文件的管理
  很多桌面应用会把缓存文件存在~/.cache目录，而systemd --user可能会参与这些缓存的清理、整理工作——比如定期删除过期的临时文件、合并碎片化的缓存数据。这个过程中需要扫描大量文件（产生读取IO），同时删除或写入新的缓存文件（产生写入IO），也会造成可观的磁盘占用。

• 用户journal日志的持久化刷写
  如果你的系统配置了用户级journal日志持久化到磁盘（默认是存在内存里，重启就丢），systemd --user会周期性地把内存里的日志刷写到~/.local/share/journal目录下。这个过程不仅有写入操作，要是journald在做日志索引、合并，还会读取已有的日志文件，这也能解释你看到的读写数据。

进一步排查的小技巧 #

• 用journalctl --user -b查看当前会话的用户级systemd日志，找一找有没有频繁的服务重启、日志轮转相关的报错或提示；
• 用strace -p $(pgrep -u $USER systemd)跟踪systemd --user的系统调用，直接看它在读写哪些文件，能快速定位到具体原因；
• 检查~/.local/share/systemd和~/.cache目录，看看有没有最近生成的大文件或者频繁变动的文件。

内容的提问来源于stack exchange，提问作者sourcejedi