Minecraft的工作原理(导致滞后的原因是什么?)
理解导致滞后的原因的关键是了解Minecraft的工作原理。Minecraft服务器软件的操作类似于一个关键问题:主游戏循环没有多线程或时间限制。当服务器进入tic时,它会运行每个TileEntity更新,实体更新,块更新,事件和其他进程,直到完成为止。这一切都发生在一个线程上,下一个循环无法启动,直到当前一个完成。世界不会更新,玩家似乎不会移动,实体将被冻结到位。理想情况下,每个tic应该不超过50ms,以维持每秒20 Tics(TPS)。对于18 TPS,这可以低至55.55ms,而问题最少。如果低于此值,您将开始看到延迟。
滞后的典型原因
有许多事情可能导致滞后,但其中一些将是大多数服务器最可能的罪魁祸首。
- 文件用法:任何不断从播放器文件中读取的插件,尤其是在移动,损坏或交互等事件上。一些例子是一些PVP标志或Glow插件,它们将不断从播放器文件中读取。
- 平面文件作为数据库:当你有使用大文件来跟踪大量数据的插件时,根据它的存储方式迭代通过该文件或内存需要很长时间。许多插件都这样做,并且没有采取预防措施来防止数据库变得膨胀时处理时间将如何影响服务器tic。在加载大型MagicSpells配置或使用使用YAML的权限系统而不是PEX和GroupManager等适当的数据库时,您会看到很多。
- 操作太多:当插件产生太多实体或尝试对诸如移动之类的事件执行复杂任务时,您将开始看到延迟。即使每次运行时间不到1毫秒,当您每秒处理20k次事件时,它也会成为指数。可能导致这种情况的插件是世界编辑插件,如VoxelSniper和WorldEdit; 或保护插件,如反作弊和世界保护。
- 加载了太多的块:一块是
16*16*256
。这可能听起来不是很多但是当相乘时,这意味着每个块有65,536个块。根据您的配置,每个玩家可以在其周围加载200多个块。多达13,107,200块。这占用了大量内存。此外,如果其中有1%是TileEntities,则需要更新每个tic的131,072个TileEntities。Mods因TileEntities的处理速度慢而臭名昭着。 - Cascading WorldGen:这是一个插件或mod在它给出的块之外生成结构的时候。这会导致下一个块加载,生成然后再次触发它,如果它也开始让结构溢出到下一个块中。这是代表创作者的糟糕设计,任何插件或mod都应该立即删除。
找到滞后的原因通常是一个简单的过程,因为大多数Minecraft服务器软件都是使用包含的分析工具构建的。
Timings报告了Spigot / PaperSpigot
要获取详细的计时报告,您可以使用以下命令。
/timings on
您需要等待几分钟,让它在您的计时运行时滞后。过一会儿,生成报告。
/timings paste
这将为您提供一个链接到一个网站,其中包含一个很好的报告细分,并提供了简单的选项来筛选您获得的所有数据。您可以在Spigot的计时维基上了解更多关于如何阅读这些内容的信息。
您将需要在之后关闭时间,因为您不希望垃圾数据堵塞您的下一次读数,并且时间增加了抽头的额外时间。
/timings off
海绵的时间报告
要获取详细的计时报告,您可以使用以下命令。
/sponge timings on
您需要等待几分钟,让它在您的计时运行时滞后。过一会儿,生成报告。
/sponge timings report
这将为您提供一个链接到一个网站,其中包含一个很好的报告细分,并提供了简单的选项来筛选您获得的所有数据。由于Sponge的计时系统基于Spigot,您可以在Spigot的计时维基上了解更多关于如何阅读这些内容的信息。
您将需要在之后关闭时间,因为您不希望垃圾数据堵塞您的下一次读数,并且时间增加了抽头的额外时间。
/sponge timings off
您也可以重置时间。
/sponge timings reset
减少滞后的步骤
- 使用适当的参数为您的脚本文件启动Minecraft。在此处了解有关适当Java参数的更多信息
- 使用LuckPerms或权限管理器使用适当的数据库而不是平面文件
- 完全避免使用大块装载机
- 删除任何导致世界级联的东西
- 限制反作弊插件不要过分热心
- 限制玩家的视距
server.properties
- 在一段时间后清除敌对的怪物
- 每天重新启动服务器以清除Java的泄漏
- 切勿重新加载服务器,这会导致泄漏和其他问题
- 使用FastAsync版本的插件,如WorldEdit和VoxelSniper
- 限制你的世界的大小,因此不会不断创建新的块
- 限制您使用的插件数量。并非所有的插件都能很好地构建,您遇到的问题就越多