幻兽帕鲁服务器卡：先分清是哪一种卡
《幻兽帕鲁》专用服务器的「卡」是四件互不相干的事，修的地方也各不相同。先按谁在卡、什么时候卡分流，再读服务端自己的帧率把它定下来。
「服务器好卡」这一句里装着四件互不相干的毛病。在游戏里看起来都差不多，要修的地方却完全不同——所以才会有人为了家里 Wi-Fi 的问题去加内存，或者为了治内存泄漏把服务器搬到另一个地域。
这篇写的不是怎么修，是怎么找：两个问题在一分钟内分掉大部分情况，一个数字把剩下的定死，然后每种成因各自在哪儿修。每条岔路的尽头，都是专讲那件事的那一篇。
第一步：到底是不是服务器的事
动任何设置之前，先定这是谁的问题。两个问题就能分掉绝大多数：别人有没有跟着一起卡，以及是画面在跳，还是操作慢半拍。
| 你看到的 | 是谁的问题 | 在哪儿修 |
|---|---|---|
| 只有你的操作慢半拍，别人都正常 | 你的线路 | 延迟、地域与卡的三种成因 |
| 画面一顿一顿但操作跟手，别人都正常 | 你自己这台电脑 | 下面的「客户端掉帧是另一个数」 |
| 所有人在同一瞬间被拉回原地 | 服务器 | 下面的第二步 |
| 根本连不进去、列表里没有、有人随机掉线 | 这不是卡 | 连不上时的排查顺序 |
这篇真正处理的只有第三行。另外三行字面意义上就是服务器之外的事，服务端设置怎么调都动不了它们。
动手之前有条捷径值得先知道：重启之后立刻就好，说明机器并不小。 光这一个测试就能排掉最贵的那个错答案，并且直接指向引擎的内存泄漏。
第二步：读服务端自己的帧率
《幻兽帕鲁》服务端有自己的帧率，它就是「感觉很卡」和「数字是多少」之间的差别。值来自官方 REST 接口，服务端只把它开在 localhost 上（怎么启用，以及那条不能破的安全规则，在 REST 管理接口那篇）：
curl -s -u "admin:$PW" http://127.0.0.1:8212/v1/api/metrics
{"serverfps":13,"serverframetime":76.9,"currentplayernum":4,
"maxplayernum":16,"uptime":259200,"days":137,"basecampnum":11}
《幻兽帕鲁》专用服务端健康时跑的是每秒 30 帧，不是 60。 以为服务端会和自己的客户端一样的人看到这里都会愣一下，这也正是读到 28 完全不用担心的原因。数字的含义：
serverfps | 玩家的体感 |
|---|---|
| 25–30 | 正常。这儿没什么可修的，回第一步再看一遍 |
| 15–25 | 开始有人抱怨。战斗发黏，但说不清哪里不对 |
| 低于 15 | 所有人都感觉得到：被拉回原地、帕鲁干到一半僵住、打击延迟 |
| 个位数 | 已经不能玩了，而且通常离进程被系统杀掉只剩几分钟 |
同一份响应里还有三个值值得一起看：
serverframetime是一帧花掉的毫秒数，大致是帧率的倒数（30 帧约 33 ms）。它的价值在于尖刺会比平均帧率更早显形，所以「平均看着没事、每隔几秒顿一下」的服务器是靠它抓出来的。uptime是进程启动到现在的秒数。它是泄漏的证据：低帧率配上很长的运行时间，答案在量别的东西之前就已经有了。basecampnum是世界里的据点数。这个接口给的所有值里，它和帧率的联动最紧——世界不是因为人多了才变重，是因为建的东西多了才变重。
要在有人正在抱怨的时候去读。凌晨没人时抓到的数字，对周六晚上没有任何解释力。
第三步：把服务端帧率拉下去的四件事
按实际出现的频率排。每一件都有一个一分钟内能判生死的测试。
1. 运行时间——内存泄漏。 服务端内存只升不降，帧率跟着往下走，最后进程被系统杀掉。测试就是重启：立刻变好就是它。它是遥遥领先的第一名，加内存只是把崩溃的间隔拉长，真正的解法是定时重启——间隔、「公告→存档→停止→启动」的顺序和脚本都在内存泄漏与定时重启。
2. 世界变重了。 据点、建筑、干活的帕鲁和掉在地上的道具，在所有人下线之后仍然在被模拟，而且不会自己消失。测试是 basecampnum 加上进游戏绕一圈：十几个据点、每个据点都站满帕鲁，那是第一周好几倍的工作量。直接有效的设置有四个——bEnableInvaderEnemy、BaseCampWorkerMaxNum、BaseCampMaxNum、DropItemAliveMaxHours（参数设置详解）——第一个该关的是袭击。
3. 高峰时段——主线程。 物理、寻路、战斗和状态同步全挤在同一条线程上，所以决定天花板的是主频，不是核数。测试是曲线的形状：四个人时正常、十个人时往下垮、人走了又回来，那是人数对配置的问题，不是泄漏。该按什么来估在开服配置要求，人数上限为什么不只是一个数字在人数上限那篇。
4. 有规律的一顿一顿——磁盘。 所有人一起冻住极短的一下，间隔固定，而且和服务器忙不忙无关。测试是看表：顿的间隔如果和 AutoSaveSpan（默认 30 秒）对得上，那是自动存档撞上了慢盘。这一条被当成网络问题误判的次数多得惊人。换 SSD 就结束了。
两件同时成立的情况也有，开了几个月的服务器多半如此。顺序仍按上面走：重启不花钱，而且先排掉最大的那个。
托管这边，这条曲线已经画好了
空岛灵境的《幻兽帕鲁》专用服务器每分钟记录一次帧率和在线人数，画在会员中心的健康曲线里：两条 24 小时的线、平均帧率与最低帧率，还有一条画在满速一半的告警线，所以这款游戏里 13 算不算低，一眼就看得出来。把两条线对着看，就是不用 curl 的第三步：帧率跟着在线人数一起往下是主线程，人数不动而帧率往下是泄漏或世界变重。曲线上断掉的那几段是服务器停着的时间，其中也包括替你处理掉成因 1 的每日定时重启。
客户端掉帧是另一个数
两个帧率共用一个名字，搞混了就会去调一台根本没问题的机器。你的客户端帧率是显卡画出来的速度，服务端帧率是世界被模拟的速度。 两者各走各的。
分开只要问一句：操作还跟手吗？
| 症状 | 哪一个帧率 | 该做什么 |
|---|---|---|
| 画面在跳但挥砍和菜单都即时响应，朋友都没事 | 你的客户端 | 你自己电脑上的画质设置 |
| 画面很顺但打击延迟，而且大家都这么说 | 服务端 | 上面的第二步 |
| 两个一起，而且只在世界的某一块 | 两个都是——重的据点对谁都重 | 第三步的成因 2 |
值得记住的是最后一行。一个盖了好几百个建筑、站满干活帕鲁的据点，对服务端是模拟负担，对你的显卡是渲染负担，所以地图上同一个位置会让两个数字一起垮。玩家把它讲成「在我们据点那边服务器就卡」，然后开始查错那台机器。
客户端这一侧能动的全在自己电脑里：画质预设、分辨率缩放、还有正在跟游戏抢显卡的那些程序。专用服务器一项都帮不上。它能保证的是另外半边是健康的，而那正是这篇其余部分在讲的事。
调设置治不好的卡
有两种根本不属于服务器，设置怎么调都碰不到。
- 高延迟与丢包。《幻兽帕鲁》走 UDP，丢了的包不会重发，所以丢包率只要超过 1%，平均延迟再好看也会被拉回原地。怎么测、怎么读抖动、队友分散在几个城市时地域怎么定，都在延迟、地域与卡的三种成因。
- 版本不一致。 游戏更新之后，还停在旧版本的服务端不是变慢，是把所有人挡在外面，而且症状看着像网络问题。看不丢存档的更新顺序。
常见问题
幻兽帕鲁服务器为什么会卡？
先确认是谁在卡。只有你，那是你的线路或你这台电脑。所有人同时被拉回原地，就重启服务器：立刻变好就是引擎的内存泄漏，这是最常见的成因。重启没有改善的话，趁大家还在抱怨的时候用 REST 接口读 serverfps——跟着在线人数一起垮是 CPU 主线程，人数不动却在垮是世界变重了。
帕鲁服务端帧率多少才算正常？
专用服务端的满速是 30，所以 25 以上都算正常。15 到 25 之间开始有人抱怨；低于 15 时，拉回原地和干到一半僵住的帕鲁会让世界里的每个人都感觉到。值从 REST 接口的 /metrics 读，而且要在服务器忙的时候读，不是闲的时候。
画面卡是我的电脑还是服务器？
看操作还跟不跟手。画面在跳但操作跟手，那是你的显卡，而且别人不会有事。画面很顺但打击延迟，那是服务端，而且所有人在同一瞬间都会遇到。如果两个一起垮、又只发生在地图的某一块，那是一个重到同时吃掉服务端模拟和你显卡渲染的据点。
据点建多了会让服务器变卡吗？
一群人对自己服务器做过最重的事就是这个。据点、上面的建筑和放在那儿干活的帕鲁，在所有人下线之后仍然在被模拟，所以负载跟着建的量走，而不是跟着在线人数走。要盯的值是 /metrics 里的 basecampnum；限制据点数、限制每个据点的工作帕鲁数、关掉袭击，是最直接的三个开关。
没人能在当下去量的时候
上面所有做法都建立在一个前提上：有人能在大家抱怨的那一刻去读数字。而那个时刻通常正是没人方便连进去的时刻。服务器卡顿真正难的地方就在这里——证据只存在于当下，等有人去看的时候服务器已经闲下来，数字好看得很。
空岛灵境的《幻兽帕鲁》服务器已经替你量好了：每分钟一次的帧率和在线人数，存成带告警线的 24 小时曲线，「昨天晚上贼卡」是打开来看的，不是靠回想拼出来的。最常见的那个成因在你到场之前就处理掉了：每日定时重启会在你指定的时刻，先发游戏内公告、强制存档，再把泄漏清掉。其余成因背后的那些设置——袭击、据点上限、每个据点的工作帕鲁数——是游戏设置表单上的输入框，不是要连进机器去改的 .ini。