Spark性能分析插件官方wiki翻译——找出你的服务器延迟高的原因吧！

Spark性能分析插件官方wiki翻译——找出你的服务器延迟高的原因吧！

作者: 深渊小恶魔

时间: 2019-08-01 01:44:00

版块: 联机教程

本帖最后由 深渊小恶魔 于 2019-8-1 10:29 编辑

spark是高版本服务端（特别是sponge）服务端很常用的一个性能分析插件。当你的服务器因为未知原因tps特别低的时候，就可以用该插件监测服务器状况并试图找出心爱的服务器哪里出了问题。原插件站内搬运地址：https://www.mcbbs.net/forum.php?mod=viewthread&tid=823209

不过对于新手来说，spark给出的性能分析报告也许并不是那么的直观易懂，所以我在这里为大家简单解析一下该插件的官方wiki,希望能帮到大家。有错误欢迎指正。要想熟练地使用spark插件进行服务器状况分析，tick的相关概念是你首先需要了解的。

Tick的概念

几乎所有的视频互动游戏（包括Minecraft）都是由一个大进程循环驱动的。而服务端和客户端游戏后台的进程执行步骤被分解为很多个“Tick”。基本上，你可以把ticks理解为一个时间单位。每次发生一个“Tick”时，游戏服务器都会做很多事情，包括：处理来自玩家的传入数据包（例如移动，放置/中断块，攻击其他实体、动物）。更新玩家和其他实体（动物）的位置。向所有玩家发送有关服务器上发生的事件的传出数据包（阻止更改，实体移动和操作）。生成怪物、动物，处理生物AI，村民寻路等。处理红石逻辑的更新。

甚至更多。Minecraft服务器的理想目标是每秒运行这些“Tick”中的20个，或者换句话说，每50毫秒一个Tick。

服务器正常运行时的状态：当服务器正常运行时，执行完整tick所需的时间应小于（或等于）50毫秒。如果执行一个tick所花费的时间少于50毫秒，则服务器在接下来的剩余时间将进行短暂的“休眠”，直到它准备好执行下一个tick。例如服务器花费15毫秒执行一个tick。在开始执行下一个tick之前，ticks循环控制器将会“休眠”（不执行任何操作）35毫秒。

当服务器滞后时的状态：

如果执行一个Tick超过50毫秒，则必须延迟执行下一个tick，因为tick是不能并行执行的。当这种情况发生时，玩家的游戏体验就会开始恶化（例如游戏延迟很大、常常丢失链接等。），因为这个时候服务器的事件处理将不再那么“敏感”和及时。

这些信息在spark给出的分析报告中是怎么样的呢？我们首先知道，spark插件的基本用法就是在后台或者游戏里输入/spark sampler开始进行服务器进程分析，然后通过/spark sampler --stop指令停止分析，接着在后台给出的网址中打开分析报告，如下图。

在上面的示例图中，我们可以看到java.lang.Thread.sleep()占“服务器线程”上CPU活动的72％。这很健康！这意味着平均而言，服务器能够花费大约70％的50毫秒分配给每个tick，绝对不做任何事情。这很好，因为它表明服务器具有足够的备用容量。如果服务器上的进程活动在某些时刻出现峰值（例如，更多玩家加入，更多实体/块正在更新），服务器应该能够（有余力）处理它。通常：睡眠（sleep）比例越高是好事如果您的睡眠时间少于20％（因此超过80％），您的服务器工作非常困难，并且可能在一些tick声中滞后（请记住这些值是平均值！）如果您的睡眠时间少于5％（因此超过95％），您的服务器可能滞后，并且没有备用容量。至今为止我们所提到的服务器滞后最直观的表现是什么呢？想必很多腐竹都见过这样的后台信息吧？

[14:26:48 WARN]: Can't keep up! Is the server overloaded? Running 79294ms or 1585 ticks behind

[14:28:38 WARN]: Can't keep up! Is the server overloaded? Running 79840ms or 1596 ticks behind

[14:30:31 WARN]: Can't keep up! Is the server overloaded? Running 82937ms or 1658 ticks behind

最后要记住的一点：spark给出的分析表上的各项值往往是一段时间的平均值！而这个时间段取决于你输入指令开始监测服务器状态直到你再次输入指令停止监测的时长。有时候您的服务器可能只花费20毫秒处理大多数tick（大多数时间都很健康），但偶尔花费300毫秒处理一些tick。（部分时间、偶尔的延迟与卡顿）。在这种情况下，通过简单地spark数据监测是很难发现具体问题所在的。因为你所得到的数据监测值是一整段监测时间内所取到的平均值orz。

那么，面对这种情况，我们该怎么办呢？在下一页我将介绍spark更为高端的监测方法。

试着用spark插件找出造成延迟峰值的原因吧！

当少量tick（或有时只是一个tick）需要很长时间才能执行时，会出现延迟峰值现象（指的就是在短时间内发生的短暂服务器延迟）。这类现象可以非常频繁地发生，例如每20个tick中只有1个，或者很少发生，例如每分钟一次。他们通常与玩家的某些行为有关（例如输入一次back指令）。通过查看正常的分析数据来查找造成延迟峰值的原因可能很因为，因为数据是平均的。所有同一时间段的其他数据样本将“抵消”峰值，并掩盖其影响。幸运的是，spark有两个有用的工具来解决这个问题。第1步：确定峰值阈值为了在分析报告中确定延迟峰值的原因，我们需要能够将“峰值”数据与所有其他报告分开。我们可以使用该/spark monitoring命令来执行此操作。此命令的工作原理是首先确定服务器的平均tick速率，然后：监控每个后续tick所花费的时间计算执行最新一次计时所花费的时间与平均值之间的差异（以百分比表示）如果差异超过某个阈值，则在后台发送通知消息

默认情况下，触发这个信息警报的阈值为100％（100％增加意味着刻度线的平均值为平均值的两倍）。要启用监控，只需执行 /spark monitoring指令即可。输入指令后，你只需要等待。如果您遇到的峰值在游戏中相当突出，那么尝试使用监视输出将游戏中的峰值效果排成一行。如果你的后台出现峰值信息输出过于频繁的情况，可能是因为100％的阈值太低。如果有明显的增值值，请尝试调整命令以仅捕获这些值。例如 /spark monitoring --threshold 200另一方面，如果后台输出信息不够灵敏，请尝试降低这个阈值。为了解释这里，我将使用WorldEdit（创世神插件）“创建”延迟峰值。:)如您所见，WorldEdit操作执行时的tick增加了1000％！

第2步：在特定的延迟数范围内执行监测指令由spark输出的报告显示，创世神插件两个指令动作都需要500毫秒才能完成，但为了确保它们被数据监测器包含在内，我将使用400毫秒的较低阈值。然后我可以运行/spark start --only-ticks-over 400- 这个指令将启动一个新的分析器，但只包含超过400ms执行的tick样本。然后我再次执行相同的WorldEdit指令（以生成延迟峰值），并停止了监测器的工作。如您所见，spark监测器给出的结果可以准确地将尖峰追溯到WorldEdit命令执行，并且不包含来自其他ticks的任何数据。在报告中你可以很很直观的看到造成这些延迟峰值的原因是由于插件worldedit，同理，如果你的服务端中有其他插件会造成你的服务器卡顿，你也可以用同样的方法定位出这个“问题插件”是哪个。在分析报告中，你只需要不断的点开高占用百分比数据项目的派生项目，找到最里层的数据项，通过数据项的名称就可以找到指明某个插件的文字，例如上图中鼠标指向的那行数据项中就提到了worldedit。

基本上spark插件的用法就是这样啦!部分翻译有参考谷歌翻译，本人也加入了一定量的通俗化语言修改，希望能帮到你。如果你发现了什么错误，请在评论里指出，非常感谢！

回复:

深渊小恶魔

深渊小恶魔

本帖最后由 深渊小恶魔 于 2019-8-2 14:43 编辑

在这里补充一下tps的说明。

tps指的是每秒事务处理量，通常用于表达系统处理能力的性能指标，每秒处理的消息数（Ticks Per Second）。

如果你已经安装好了spark插件，你可以输入/spark tps来查看你的服务器当前的tps情况。一般来说，tps为20或者19.X的时候，你的服务器是想当健康的。如果tps在某些时候掉到了10甚至10以下，说明你的服务器当前有着较大的延迟卡顿，这个时候你就需要试着用spark或者其他分析插件找找原因了。

2019-08-01 02:26:00

鬼畜畜

鬼畜畜

深渊小恶魔 发表于 2019-8-1 10:26

在这里补充一下tps的说明。

tps指的是每秒事务处理量，通常用于表达系统处理能力的性能指标，每秒处理的消 ...

tps应该是 ticks per second

2019-08-01 05:28:00

深渊小恶魔

深渊小恶魔

Ghost_chu 发表于 2019-8-1 13:28

tps应该是 ticks per second

好的，已经改正。

2019-08-02 06:43:00

怕一笑丶

怕一笑丶

期待楼主下次更新

2020-04-20 06:03:00

小军最帅

小军最帅

感谢楼主分享

2020-04-30 03:42:00