TPS 与 MSPT：服务器卡不卡看什么

三个人在服里挖矿，你这边看朋友的角色一顿一顿地平移，方块挖掉半秒才消失；切回概览，TPS 明明白白写着 20.0。又或者相反：什么都点不动，TPS 那里只有一个 --。

这两种情况都不是“手机不行”。卡有卡的来源，数字有数字的来路。先花五分钟把指标认清楚，你后面每一次改配置才知道自己在改什么。

这一页讲三件事：TPS 和 MSPT 分别是什么、概览上那个数字从哪来、以及数字掉下来之后怎么在半分钟内判断是 CPU、内存还是区块加载在拖后腿。

一秒钟被切成 20 份#

服务端不是“实时”跑的。它以每秒 20 次的固定节奏推进整个世界，这个节奏叫 tick（游戏刻，可以理解成服务端的心跳）。20 tick 等于 1 秒，所以每一刻的预算只有 50 毫秒：怪物寻路、方块更新、实体移动、玩家位置、区块加载，全部要在 50 ms 内算完，然后立刻进入下一轮。

一秒钟实际跑完多少刻，就是 TPS（ticks per second，每秒游戏刻数）。满分 20。

因为预算固定是 50 ms，“跑得动”和“跑不动”之间没有缓冲区：每刻花 45 ms，依然是 20 TPS；每刻花 100 ms，就只能跑到 10 TPS。

TPS 不会超过 20，也不会“负优化”到 0 —— 真到那个程度，服务端已经卡死或者被看门狗关掉了。

MSPT：比 TPS 更早报警的数字#

MSPT（milliseconds per tick，每刻耗时）是同一件事的另一面。TPS 是结果，MSPT 是原因，所以真正该盯的其实是后者。

换算关系很简单：每刻不超过 50 ms，TPS 就是 20；超过之后，TPS 大约是 1000 ÷ MSPT。

当 MSPT 从 20 ms 涨到 45 ms，TPS 还漂亮地显示 20，但余量只剩 5 ms —— 再来一个玩家跑图，就掉到 19、18 了。等你看到 TPS 掉下来，其实已经卡了一阵。

还有两个信号值得记住：

• 日志里出现 Can't keep up! Is the server overloaded?（服务端在说“我跟不上了，是不是过载了”），说明它已经在掉刻了，不用等 TPS 数字变。

• server.properties 里的 max-tick-time（最大 Tick 时间，配置页默认 60000 毫秒）：某一刻卡住超过这个时长，看门狗会判定卡死并强制关闭进程。你说的“服务器莫名其妙消失了”，有时就是它干的。

概览上那个 TPS 是怎么来的#

概览页 Hero 卡中间那个带一位小数的 TPS，不是应用估算的，而是解析服务端控制台输出得来的：Paper / Spigot 系的 tps 命令会打印最近 1 分钟、5 分钟、15 分钟的 TPS，应用取其中的 1 分钟值。

这带来三个必然结果：

1. 服务端没运行，显示 --。 没有控制台输出，就没有数字。

2. 刚启动、还没采到那一行，也会是 --。 等一两轮采集就有了。

3. 核心不打印这种格式的 TPS 行，数字就长期停在 --。 原版 Vanilla 没有 tps 命令，基岩系核心也不走这套回报。这不是坏了，只是这个核心不提供 TPS 数字，卡不卡只能靠体感和日志判断。

采集是自动的：前台大约每 15 秒一次，后台大约每 60 秒一次。点 Hero 右上角的刷新会立刻重采，并顺手向控制台发一次 list；Paper 系还会再发一次 tps。所以刚点完刷新，TPS 会跳到最新值。

想自己手动看，去 终端 的 MC 会话输入 tps（带不带开头的 / 都行，应用会去掉斜杠）。原版核心会回一句 Unknown command，那是没有这条命令，不是服务器坏了。

三种“卡”不是一回事#

这是新手最容易搞错的地方：把所有“不流畅”都归到服务器头上，然后开始重装。

三个快速判断：

• 你一个人站在出生点不动，TPS 就低 → 服务端的问题（插件、实体堆积、内存、发热降频）。

• 只有多人一起玩、或者有人跑图时才低 → 世界加载和实体压力。

• TPS 一直是 20，只有你觉得卡 → 网络或手机，跟服务端配置无关。

TPS 掉了，先分清是 CPU、内存还是区块加载#

同样是 TPS 从 20 掉到 12，原因可能完全相反。分不清就去加内存，多半白花功夫 —— 内存不够是一阵一阵，CPU 打满是一直低，手感差别很明显。

三条旁证，帮你确认猜得对不对：

• 内存不够：概览内存条长期在 90% 以上，日志里能搜到 OutOfMemoryError 或 GC 相关字样。

• IO / 区块加载：卡的时刻总跟“有人刚进新区域”“正在自动备份”重合，跑完那一段自己就恢复了。

• CPU 被占满：上面两条都不成立，手机还发烫 —— 那就是算力真的不够，先降视距。

内存怎么给，见 内存分配；区块加载怎么提前处理，见 综合优化。

先测量，再动手#

盲改配置的典型结局是：改了五处，卡顿没了，但你不知道是哪一处起的作用；下次再出问题，也无从下手。

• 采样窗口至少 5 分钟，而且要包含“卡的那段时间”。刚启动的头半分钟世界还在加载，这时候的数字没有代表性。

• 用性能分析工具。手机上最常用的是 spark：它不是 Minexa 自带的功能，需要你自己装（从 插件与模组 页装，或者上传 jar 放进插件目录），装完重启服务端，再在控制台输入它的命令采样。Paper 系早期版本还自带 timings，新版以 spark 为主，以你核心实际提供的命令为准。

• 看它给出的“谁最耗时”：是某个世界的区块生成、某类实体、某个插件，还是单纯的主线程被 GC 拖住。

常见原因，按“最容易改”排#

掉刻的原因就那么几类，按遇到频率和改动成本排下来：

1. 区块生成。 有人跑到没去过的地方，服务端要现场生成地形，单刻耗时瞬间飙升。这是手机服最常见的卡顿来源，解法是降视距 + 预生成。

2. 实体与掉落物。 刷怪塔、动物圈、掉落物堆、盔甲架和展示框，数量上到几千就开始拖慢每刻。

3. 红石与漏斗。 高频红石时钟、成排的漏斗和漏斗矿车，每一刻都在算。

4. 怪物 AI。 夜晚、洞穴、刷怪笼附近怪物密集时，寻路计算很重。

5. 插件。 尤其是那种“每刻扫描全服实体”的清理/优化类插件，本身就在制造负载；反作弊插件也一样有代价。

6. GC（垃圾回收）。 内存长期贴着上限，JVM 会频繁回收，每刻耗时跟着抖动。

7. CPU 降频。 手机发热、开省电模式、后台被系统限制，同样的世界会突然变卡。

8. 存储慢。 同步写盘、外置存储、或者正好在跑备份。

处理顺序建议是：先测量 → 检查散热和供电 → 视距和模拟距离 → 内存 → 插件和模组 → 预生成 → 换设备。完整清单在 综合优化 里。

多少算健康#

手机服没有“必须 20”这种标准，下面是经验区间：

除了绝对值，还要看趋势：每玩半小时 TPS 就往下掉一点，通常不是配置问题，而是发热降频或者实体/内存累积。这类“越玩越卡”的排查思路在 内存不足与 CPU 占用 里有展开。

下一步#

• 最有效的一次改动：视距与模拟距离

• 数字有了，内存怎么给：内存分配

• 按收益排序做一遍：综合优化