Minecraft 日志中最常见的三种卡顿信息并不是一回事：Can't keep up! Is the server overloaded? 表示你的服务器还在运行，但已经跟不上节奏。A single server tick took 60.00 seconds 表示内置的紧急刹车机制已经强制结束了它。Exception in server tick loop 表示某个具体的程序错误把游戏循环搞崩了。如果把这三种情况都当成同一个问题处理，通常会修错方向。
区分这三条信息
Minecraft 每秒会计算游戏世界 20 次。这样的一个计算周期叫做 Tick，最多只能持续 50 毫秒。你感受到的所有卡顿，本质上都是偏离这个数字。
| 日志信息 | 实际发生了什么 | 服务器还在运行吗？ |
|---|---|---|
Can't keep up! Is the server overloaded? Running 5074ms or 101 ticks behind |
Tick 超过 50 ms，服务器正在追赶积压的计算 | 是，但明显变慢 |
A single server tick took 60.00 seconds + Considering it to be crashed |
单个 Tick 超过了 max-tick-time；Watchdog 结束了进程 |
否，已被强制结束 |
Exception in server tick loop |
一个错误一路传到了主循环 | 否，通常会有崩溃报告 |
Dispatched async TPS command（Paper 警告） |
我们自己的 TPS 测量从外部查询服务器 | 是，这是正常的 |
最后一行经常让人困惑：Paper 会把每个来自外部的查询都记录为警告。这是我们大约每五分钟进行一次的计划内性能测量，不是错误，也不会干预你的游戏。
最重要的动作：遇到 Watchdog 信息时往上读
Watchdog 强制结束是一个症状，不是原因。它只说明：有东西把服务器线程阻塞得超过了允许时间。真正阻塞它的东西写在别处。
这里有两种情况，它们对应完全不同的处理方式：
情况 1 — Watchdog 先出现。 Watchdog 行之前是正常游戏运行日志。此时 Tick 时间本身就是关键信息：某个东西在运行中冻结了服务器。
情况 2 — Watchdog 后出现。 Watchdog 行之前已经出现 Stopping server 或 Preparing crash report。这说明服务器在之前就已经崩溃或正在关机，Watchdog 只是清理了一个卡住的退出过程。
第二种情况并不少见。在 2026 年 8 月 22 日的一个支持案例中，服务器线程在 13:20:15 崩溃，开始正常执行 Stopping server，直到 60 秒后 Watchdog 才触发。如果这时把 Tick 时长解释为根因，就会让服主错过真正的错误信息，而那条信息其实在上方一分钟的位置。正因为如此，我们的控制台分析会有意最后再评估 Watchdog 命中：如果同一段日志中有更具体的特征，你看到的是那条具体结论，而不是“某个 Tick 很慢”。
一步步找到原因
1. 在面板中检查 TPS 曲线
在面板中打开你的服务器。在 “性能（最近 24 小时）” 下可以看到 TPS 曲线；只要服务器在运行，大约每五分钟测量一次。曲线形状已经能说明很多问题：
- 某个具体时间点突然大幅下跌 → 一次事件。把时间和日志对上：世界生成、备份、玩家进入未探索区域、某个插件任务。
- 长期处于低值 → 结构性过载。重启解决不了，需要减负。
- 锯齿形曲线 → 通常是内存压力：服务器在工作，垃圾回收打断它，然后不断重复。
如果数值在较长时间窗口内一直偏低，面板会自动提示 “TPS 持续偏低”。
2. 测量 MSPT，光看 TPS 不够
在控制台输入 /spark tps。这个命令会给出两个数字，其中第二个更重要：
- TPS — 每秒 Tick 数，最大 20。
- MSPT — 每个 Tick 的毫秒数。50 ms 以内是健康的。
为什么要看 MSPT？ Bukkit、Spigot 和 Paper 会限制服务器进程，避免直接崩溃。因此界面可能显示稳定的 20 TPS，但服务器实际上早已接近极限。45 ms 的 MSPT 表示：你离明显卡顿只差一个刷怪塔，哪怕 TPS 显示仍然完美。
在 Paper 1.21 及以上版本中，spark 已经内置，你不需要额外安装。
3. 用 Profiler 找出元凶
不要猜哪个插件有问题，直接测：
/spark profiler start --timeout 120
在这两分钟里复现会卡顿的场景。之后打开服务器输出的结果链接。报告会按耗时占比排序，显示 Tick 时间花在了哪里：某个 Mod、某个插件任务、区块加载、实体处理，或垃圾回收。
这正是本指南和“多买点 RAM”建议的分界点。Profiler 能回答推荐表回答不了的问题：你的服务器上到底是什么在消耗时间？
4. 有针对性地减负
Profiler 显示什么，就采取对应措施：
| Profiler 显示 | 有效措施 |
|---|---|
| 区块加载、世界生成 | 降低 simulation-distance（默认 10，最低 3）— 比 view-distance 更有效，因为只有被模拟的区块会消耗计算时间 |
| 实体处理 | 限制刷怪塔，把动物圈起来而不是任其四处跑，清理物品堆积 |
| 红石 / 方块 Tick | 用侦测器制作红石时钟，避免中继器循环，关闭持续运行的装置 |
| 单个插件或 Mod | 暂时禁用后重新测量；寻找替代品或更新版本 |
| 垃圾回收 | 这时增加 RAM 才是正确答案，之前不是 |
最后一点很重要：RAM 只解决内存问题。如果是一组红石时钟吃掉 Tick 时间，更大的套餐不会让服务器变快。我们的 Minecraft RAM 计算器 可以帮你计算玩家数量和 Modpack 大小适合多少内存。
5. max-tick-time — 例外情况，不是解决方案
这个值位于 server.properties 中，用来规定 Watchdog 从多长的 Tick 开始介入。默认值是 60000 毫秒，也就是 60 秒。一旦超过这个值，服务器会自行结束。
网上很多教程会建议在这里用 -1 关闭 Watchdog。不要把它当成标准解法。 Watchdog 是唯一能发现真正死锁的内置机制。设为 -1 后，一个已经死掉的服务器可能会在端口上挂几个小时：玩家进不去，日志里没有解释原因，也没有人收到警报。你只是移除了提示，不是解决了问题。
只有一种合理的提高理由：某个已知操作确实会合法地耗时很久。 典型例子是大型 Modpack 第一次启动，世界生成和 Mod 初始化可能在一个 Tick 中合计超过一分钟。此时设置为例如 180000（三分钟）是可以接受的，但应该是临时的，并且要在第一次成功启动后把它改回去。
如果日志中出现 Exception in server tick loop
这是三种信息中最简单的一种，因为它会一起给出原因。它下面或后面几行通常会有一行 Caused by:，那里写着真正的错误，通常还包含负责的 Mod 或插件名称。
处理步骤：
- 搜索
Caused by:并记下类名。 - 如果其中包含 Mod 或插件名，元凶就已经被点名了。
- 如果错误发生在一次改动之后（新 Mod、更新、新世界），先回滚这次改动。
- 如果错误仍不清楚，把完整日志段发给支持，并附上时间。
你服务器的控制台分析会自动识别这些行，并用清楚的文字解释每条识别到的信息，包括出现频率。如果你只有别处的一段日志，也可以把它粘贴到我们的 崩溃报告分析器 中，即使服务器不在我们这里也能用。
我们会自动帮你处理什么
- 无需手动操作的性能测量。 TPS 大约每五分钟记录一次，并在面板中保留 24 小时；你不需要为此安装插件。
- 持续性能偏弱时提醒。 如果性能在一个可靠时间窗口内保持低位，你会收到提示，而不用自己碰巧发现。
- 解释过的日志行。 识别到的信息会用你的语言说明原因和解决方式；如果存在合适的指南，还会给出对应链接。
- 症状让位于原因的规则。 如果同一段日志中存在比 Watchdog 强制结束更有意义的错误信息，我们会优先显示那条信息。
故障排查：症状、检查、解决方案
| 症状 | 检查 | 可能的解决方案 |
|---|---|---|
| 只在探索新区域时卡顿 | 玩家进入未探索区域时是否出现？ | 世界生成；降低 simulation-distance，预生成世界 |
| 固定时间点卡顿 | 将时间与计划任务对照 | 调整备份或重启计划的时间 |
| 服务器无错误停止，日志突然结束 | 末尾是否有 A single server tick took？ |
Watchdog 强制结束；阅读前一分钟日志 |
| TPS 显示 20，但仍然卡顿 | /spark tps — 查看 MSPT |
TPS 限制器掩盖了负载；按 MSPT 判断 |
| 添加 Mod 后出现问题 | 移除 Mod 并重新测量 | Mod 冲突或高负载 Mod |
| TPS 曲线呈锯齿状 | 用 Profiler 检查垃圾回收 | 内存压力；增加 RAM |
| 日志中出现 “Dispatched async TPS command” | 只有这一行，其他正常 | 无需处理，这是我们的测量 |
FAQ
TPS 低到多少玩家会有感觉？
大约到 18 TPS 之前，游戏里通常感觉不到。低于 15 时会明显变慢。但不要只依赖它：还要检查 MSPT，因为 TPS 限制器可能显示健康数值，而服务器其实已经接近极限。
增加 RAM 能解决卡顿吗？
只有在内存确实是瓶颈时才可以。如果 Profiler 显示垃圾回收是主要耗时项，那可以。如果它显示是红石时钟或刷怪塔，增加 RAM 没用。先测量，再购买。
我该关闭 Watchdog 吗？
不要，至少不要长期关闭。-1 会让你失去唯一的自动冻结检测。对于已知的慢操作，比如大型 Modpack 首次启动，临时提高 max-tick-time 可以接受，但之后要改回去。
为什么 Watchdog 信息出现在 “Stopping server” 之后？
因为服务器已经在关机过程中，并且在关机时卡住了。Watchdog 清理的是一个卡住的退出过程，而不是杀掉一个仍在运行的服务器。原因在 Stopping server 之前。
重启有帮助吗？
对当前积压有帮助，对根因没有帮助。如果每次重启后不久卡顿又回来，那就是结构性问题，接下来只能靠测量继续定位。
view-distance 和 simulation-distance 有什么区别？
view-distance 决定玩家能看多远；simulation-distance 决定世界实际会计算多远。两者默认都是 10 个区块。因为只有被模拟的区块会消耗计算时间，降低 simulation-distance 通常能在视觉损失较小的情况下带来更明显的减负。
如果仍然卡顿
在发起支持请求前，先收集三样东西：上次问题发生的准确时间、你的 spark Profiler 报告链接，以及最近新增了哪些 Mod 或插件。这样就能有针对性地检查日志中的对应片段，而不是做一轮泛泛的优化。
跨所有游戏通用的调节点，包括重启计划、套餐选择、网络，可以在指南 提升 Gameserver 性能 中找到。如何干净地安装和移除 Mod 与插件，见 安装 Minecraft Mod 和插件。
你想要一台自带 TPS 测量、日志解释和警告，而且无需额外折腾的服务器？在 租用 Minecraft-Server 页面可以找到合适的套餐。
来源与测试基准
max-tick-time、Tickrate 和距离： PaperMC — server.properties。记录了 60000 毫秒的默认值、超过后的强制结束、用-1禁用，以及view-distance和simulation-distance的默认值 10。- spark 已内置于 Paper： PaperMC — Profiling。从 Paper 1.21 开始不需要单独下载。
- MSPT 优先于 TPS： spark — TPS and MSPT。解释了为什么 TPS 限制器可能显示稳定 20，而服务器实际运行更慢。
- Profiler 命令： spark — Command Usage。
/spark profiler start --timeout <sekunden>和/spark profiler stop的来源。
测试基准： 2026 年 8 月 24 日。默认值和命令可能随新的服务器版本变化；不确定时请查看链接中的厂商文档。