如何解决 Minecraft 服务器卡顿

服务器卡顿、网络卡顿还是客户端卡顿？

最快的判断方法是问一句：是不是所有人在同一时刻都卡？服务器跟不上时，所有玩家会一起卡住；网络差或电脑慢只影响它的主人。本指南接下来讨论的都是服务器卡顿。

先测量：TPS、MSPT 和 spark

Minecraft 服务器每秒运行 20 个 tick，因此每个 tick 必须在 50 ms 内完成。有两个数字反映它的运行状况：

• TPS（每秒 tick 数）：20 表示服务器跟得上；低于 20，世界就会变慢。
• MSPT（每个 tick 的毫秒数）：每个 tick 花了多长时间。低于 50 ms 说明还有余量；超过 50 ms 服务器就会落后。

Paper 自带 /tps 和 /mspt，但官方文档推荐使用 spark。从 1.21 起它已内置于 Paper，也可以作为 Fabric、Forge 和 NeoForge 的模组使用：

/spark tps
/spark health
/spark ping

/spark tps 显示最近几秒和几分钟的 TPS，更有用的是它会给出 tick 耗时的最小值、中位数、第 95 百分位和最大值。/spark ping 显示玩家的延迟，可以直接判断是“服务器还是网络”的问题。/spark health 还会显示 CPU、内存和磁盘情况。

用 spark 性能分析找出原因

数字告诉你服务器在卡；性能分析告诉你为什么卡。在卡顿发生时启动分析，让它运行几分钟：

/spark profiler start --timeout 300

完成后，spark 会发出一个网页查看器的链接。在查看器中：

1. 打开 Server thread——也就是运行世界的主线程。卡顿就出在这里。
2. 展开百分比最高的条目：tick 时间就花在那里。
3. 切换到 Sources 视图，查看按插件或模组划分的耗时。如果某个插件或模组占用了主线程的很大一部分，通常答案就是它。

对于时有时无的卡顿，还有两个工具可以帮忙：/spark tickmonitor 会报告每一个耗时过长的 tick，/spark profiler start --only-ticks-over 100 只记录慢 tick，这样偶发的尖峰就不会被平均值掩盖。

真正有效的优化，按优先顺序

1. 视距与模拟距离

在 server.properties 中，simulation-distance 决定玩家周围多远范围内的世界会被真正模拟——生物、作物、红石，而 view-distance 决定向玩家发送多远的区块。两者默认都是 10。降低 simulation-distance 往往是效果最大的一项：试试 6 到 8，同时让 view-distance 稍高一些，让世界看起来依然开阔。这些只是起点，不是官方数值；调整前后都要测量。

2. 预生成世界

生成新区块是服务器最耗资源的工作之一，而玩家朝不同方向探索会让它不停地生成。Chunky 插件（或模组）可以提前生成地图：

chunky radius 5000
chunky start
chunky pause
chunky continue

请在没人游玩时运行——预生成进行中时服务器本来就会报告“Can't keep up”——有玩家加入时暂停它。

3. 实体与农场

刷怪塔、村民大厅和成堆的掉落物是最常见的持续性负担。在 Paper 和 Spigot 上，spigot.yml 中的 entity-activation-range 控制玩家要多近实体才会被完整 tick，merge-radius 会合并掉落物和经验球。用插件或规则限制刷怪塔的规模，并清理被遗忘的掉落物堆。

4. 漏斗与红石

大型漏斗链开销很大。在 spigot.yml 中，ticks-per.hopper-transfer 决定漏斗搬运物品的频率；Paper 的 hopper.disable-move-event 能大幅提速——但会破坏依赖该事件的保护类插件。红石方面，Paper 的 misc.redstone-implementation: ALTERNATE_CURRENT 可以大大减少红石粉造成的卡顿，但它会改变红石粉的行为，所以请先测试你的机械装置。

5. 性能分析中指出的插件或模组

如果 spark 分析指向某一个插件或模组，那解决办法就在它身上：更新它、调低它的配置，或者替换它。再多的 RAM 也不能让写得差的插件变快。

“TPS 是 20，但还是卡”

这是最令人困惑的情况，几乎总是tick 卡顿：大多数 tick 都很快，但偶尔会有一个耗时几百毫秒。平均值仍然是 20，但所有人都会感觉到一次卡住。

• 检查 tick 的最大耗时：看 /spark tps，或运行 /spark tickmonitor。出现几百毫秒的尖峰即可确认。
• 常见原因是某个插件在主线程上等待——从网上获取玩家皮肤或头颅、向 webhook 发送消息、检查更新或许可证，或者同步保存文件或数据库。等待期间服务器什么也做不了。
• 要分析等待，而不只是计算。普通的性能分析显示的是 CPU 工作；正在等待的线程看起来是空闲的。使用 /spark profiler start --thread * 记录包括等待在内的时间去向，并在 Server thread 上查找网络或文件调用。

解决办法在插件本身——改用异步调用，或换一个插件。更多 RAM、更快的 CPU 或更好的网络都没用，因为服务器并不缺任何资源；它只是在等待。

什么时候答案真的是 RAM 或 CPU

Minecraft 在一个主线程上模拟世界。这带来两个结果：

• 单核 CPU 速度最重要。如果 spark 显示 Server thread 忙于正常的世界运算——实体、区块、方块 tick——并且 MSPT 很高，那么更快的 CPU 会有帮助，而更多核心则不会。
• RAM 只在不够用时才有帮助。迹象：服务器在达到内存上限时重启，或者垃圾回收暂停在性能分析中占主导。超出世界和模组所需之后，更多 RAM 对 tick 速度毫无作用——而且过大且未调优的堆反而会让垃圾回收暂停更长。

服务器需要多少 RAM，以及能让垃圾回收保持简短的启动参数，请参阅 Minecraft 服务器需要多少 RAM。如何在 Paper、Purpur 等之间选择，请参阅 最佳 Minecraft 服务器软件。

卡顿与你的 HytHost 服务器

HytHost 的每个 Minecraft 套餐都运行在相同的硬件上：Ryzen 7 和 Intel i9 CPU，睿频最高 5.0 GHz，DDR4 内存和 NVMe 存储——正是 Minecraft 所依赖的单线程性能。spark 已经是 Paper 的一部分，你可以直接在控制台中进行性能分析。

如果分析显示服务器确实缺少运行其世界和模组所需的内存，可以在面板中升级套餐；世界会原样保留。如果分析指向某个插件或农场，请先解决它——这不花钱，而且在任何套餐上都有效。请查看 Minecraft 主机，或 高级 Minecraft 主机上的更大套餐，低至 €11.65/月。