排查卡顿问题
卡顿会在一小部分滴答（有些时候甚至只有一个滴答）花费很长时间进行计算时出现。
卡顿发生的频率可长可短，小到每 20 刻，大到每分钟。当然，这些都和玩家的行为有关。
在一般的性能报告中寻找卡顿根源会让人焦头烂额，因为数据经过平均化处理。正常抽样的加入会“削去”占用波峰，这会导致它们看起来不那么像会卡服的东西。
还好，spark 为你提供了排查问题的两个工具。
第一步：使用命令 /saprk tickmonitor 检测高占用
若要在报告中找出卡顿的原因，我们需要将这些“卡顿”的滴答从其他正常的滴答中筛选出来。
所以，这就是我们使用命令 /spark tickmonitor 的目的。
这个命令会先检测服务器的平均滴答速率，然后再：
- 检测每个后续的滴答耗时；
- 计算最近执行的滴答耗时与平均耗时的差异（百分比）；
- 在差异超过设定值时发送在聊天栏并提醒管理员。
若要启动滴答监控，只需执行命令 /spark tickmonitor
默认情况下，设定值为 100%（100% 表示这次滴答耗时是平均耗时的两倍）。
你可以指定设定值为耗时而不是百分比，例如命令 /spark tickmonitor --threshold-tick 50 会报告任何耗时超过 50 毫秒的滴答（这个值是服务器开始卡顿的临界时间）。
这之后，你只需要等待。若你正经历的卡顿能在游戏里感受到，那么尝试在监视器的输出与游戏实际体验相结合，找到问题所在。
如果输出的内容还不够明显，试试将检测值调低。例如，/spark tickmonitor --threshiold-tick 70。
为了在这里解释，我在这里应用 WorldEdit“制造”了一次卡顿。😃
如你所见，WorldEdit 在本次操作中的滴答耗时甚至超过了 1000%！
第二步：在命令 /spark profiler 中使用参数 --only-ticks-over 找到问题
参数 --only-ticks-over 意味着监视器只会记录超过指定值的滴答。这可以将“正常”的内容过滤掉，留下需要仔细排查的滴答。
你可以使用第一步提及的命令来设置指定值，我推荐使用 50 到 100 毫秒之间的值——但应该总是比那些明显卡顿的滴答短，否则 spark 就不能为你过滤它们。
例如，在第一步中用于展示的卡顿操作的滴答耗时已经超过了 300 毫秒，但为了确保它们能被检测到，我会选择低于 150 毫秒的数为检测值。
然后，执行命令 /spark profiler --only-ticks-over 150。
这会运行一个新的报告检测，但只会记录那些耗时超过 150 毫秒的滴答。
在完成之后，打开报告浏览器并检查内容。希望我们能马上就发现那卡顿的部分。
例如...
