甲骨文免费服务器开宝塔就卡死？教你调教 journalctl 进程

如果你也有一台甲骨文（Oracle Cloud）免费服务器，大概率经历过这种绝望：刚装好宝塔面板，兴冲冲地点进去准备大干一场，结果面板上的 CPU 监控瞬间爆红，卡顿无比。不仅后台转圈圈，连服务器上托管的网站也跟着“原地去世”，整个服务器仿佛在机房里“冒烟”了，重启大法也只能管一会儿。

别急，这可能不是服务器性能不行，而是被某个“日志狂魔”给拖累了。

第一步：捉贼拿脏，看看是谁在捣鬼？

当你的服务器卡到怀疑人生时，首先要做的就是登录 SSH 终端（比如 Termius 或 Putty），用 top 命令看看是谁在后台“吃独食”。

💡 小科普：怎么看 top？
在终端输入 top 并回车，你会看到一个实时更新的列表。
看 CPU 占用：关注 %CPU 这一列，看看排在最前面的是哪个进程。
看运行状态：如果某个进程的百分比超过了 100%（多核情况下会叠加），那它就是罪魁祸首。
退出方式：按键盘上的 q 键即可退出查看模式。

很多小伙伴发现，那个排在第一、疯狂压榨 CPU 的进程叫：journalctl。

这个 journalctl 本来是 Linux 用来管日志的，但如果你的 Docker 容器比较多，或者系统报错频繁，它就会在后台拼命读写日志。每次你一进宝塔面板，它就想把那些陈年旧账都翻出来给你看，直接把 CPU 跑冒烟了。

第二步：对症下药，三步搞定卡顿

既然知道了是日志太多导致的，那我们就给它“瘦个身”，限制一下它的胃口。

1. 修改配置文件，立规矩

我们要告诉系统，别什么陈芝麻烂谷子的事都记，而且占用的地盘不能太大。

在宝塔面板侧边栏点击“文件”，在地址栏输入 /etc/systemd/，找到 journald.conf 这个文件，双击打开，在 [Journal] 下方加入以下四行代码：

[Journal]
MaxLevelStore=warn       # 只存警告及以上级别的日志，琐事别记
MaxLevelSyslog=warn      # syslog 也一样
SystemMaxUse=100M        # 硬盘最大占用 100M，多出的一律删掉
RuntimeMaxUse=100M       # 内存占用也限制在 100M

2. 清空旧账，立刻止损

规矩立好了，现在把以前那些臃肿的垃圾日志清一清。在终端输入以下两条命令：

sudo journalctl --rotate
sudo journalctl --flush

3. 重启服务，重获新生

最后，重启一下日志服务让配置生效：

sudo systemctl restart systemd-journald

搞定，流畅起飞！

做完这一切，你再试着刷新一下宝塔面板。你会惊喜地发现，CPU 曲线终于冷静下来了，网站访问也恢复了往日的丝滑。甲骨文的“免费午餐”终于又能香喷喷地吃下去了。

参考出处： 本文解决方法参考自张洪Heo 的博客 - 宝塔journalctl占用大量CPU解决方法，感谢博主的经验分享！