从一次Minecraft服务器卡顿排查，看容器化部署的正确性

引言

最近我给服务器安装了杀毒软件ClamAV，随后Minecraft服务器出现了一个奇怪的症状：每隔几分钟就会出现一次明显的卡顿，有时会直接崩溃。作为一名服务器管理员，这种破问题可以说烦得要死。当然Linux经验丰富的我直接锁定了”元凶”——系统安全软件ClamAV。这次问题的解决过程让我深刻体会到了1Panel选择容器化部署的技术路线是多么明智的决定。

问题现象与排查过程

症状描述

• 周期性卡顿：大约每5-10分钟出现一次，持续10-30秒
• TPS下降：从稳定的20TPS骤降到5以下
• 无错误日志：服务器日志中没有明显的错误信息
• 资源占用正常：CPU和内存使用率都在合理范围内（已在MCSManager后端限制内存开销并指定使用的CPU核心）

排查之旅

第一阶段：从MC服务器内部排查

正如同上面说的那样，我限制了性能开销，但问题没有解决。

第二阶段：直接锁定”元凶”！

当MC容器内部排查无果后，我立刻联想到最近用1Panel脚本安装的两个杀毒软件，即ClamAV和FreshClam，其中FreshClam是手动查杀软件，不必排查。

关键证据：ClamAV的实时扫描进程clamd与Minecraft服务器的自动保存操作（每5分钟一次）完全同步！

解决方案：停用ClamAV（或添加为Minecraft文件夹白名单）

在日志中明显可以看到ClamAV查杀了Minecraft的存档文件夹，然而，Minecraft玩家都明白，Minecraft在运行时会频繁地读写这些存档文件，这意味着ClamAV会查验Minecraft对存档文件夹的每一次读写操作，占用了大量的系统资源，这就是病因所在。

1Panel部署MCSManager的另一个重要细节

在分享这次经验的同时，我想补充一个在1Panel中部署MCSManager时容易踩的坑。

问题：面板无法正确识别容器内的服务状态

MCSManager部署在Docker容器中，而1Panel的监控机制默认无法直接穿透容器边界获取内部服务的真实运行状态。这可能导致：

• 面板显示服务”运行中”，但实际容器内进程已崩溃
• 无法准确获取容器内服务的CPU/内存占用
• 日志查看受限，需要手动进入容器排查

解决方案

建议在部署MCSManager时，额外配置一个简单的健康检查脚本，定期检测容器内服务状态，并通过容器暴露的API或日志文件向宿主机反馈。

结语

这次排查让我深刻体会到容器化部署的优势：隔离性让问题定位更精准，不会因为宿主机上的某个软件（如ClamAV）而影响容器内的服务。同时，也提醒我们在部署时要充分考虑容器与宿主机之间的交互细节，避免踩坑。