|
| |
Preface —— Explain Why - 为何要写这篇教程帖? - 最近在问答帖中看到了很服主因服务器TPS低而求助，但他们中大多都不会分析Timings，而站内一些关于Timings分析的教程帖，不是对小白服主不友好就是说明的不够详细。因此突发写一篇分析Timings教程的念头 - 什么是Timings？ - Timings是spigot内置的允许服务器管理员监视服务器运行状况的工具，目前有Timings v1和Timings v2(仅对于Paper和Sponge)两个版本，Timings v2有图形化界面，对用户更友好，且不需要像Timings v1那样需要特殊手段(毕竟是国外网站)才能展开报告内容。 - 本篇文章适用于哪些服务端核心？我服务器核心能不能用？ - 适用于绝大部分主流核心，如spigot，paper，catserver，sponge，Uranium等，但对于mite这种魔改核心和官方原版核心不适用 - 其他须知 - 本教程重分析而轻优化，目的是为了让服主可以读懂timings而不是如何具体优化，而其他优化教程如喵的mod服优化教程帖、极光的插件服优化教程帖这两个教程是重优化而轻分析原因。如果你只想优化服务器增加tps而不想知道确切卡服原因，建议选择上方链接中的教程。另外本帖可能有很多单词翻译不当(如Tick，我实在想不出有什么翻译能通俗易懂还能表达正确意思了)，如果你翻译的更好可以在评论中指出，我会为你献上1人气+10金粒 另外请不要在本帖讨论以下内容
- 字数统计 汉字：3665 个 中文标点：268 个 汉字+标点：3933 个 英文：3762 个 （含英文状态下的数字、符号、标点） 数字：271 个 字符总数：11628 个字符 - 更新日志 2020/11/26: 优化排版， |
| ||||||||||||||||||||||||||||||||||||||
Course —— Solve How I.创建服务器的Timings报告 1.准备部分：确保在bukkit.yml中的plugin-profiling一项的布尔值为true，否则最终报告可能没有插件部分 2.生成报告：你需要在服务器或后台中输入命令/timings on(sponge端为/sponge timings on)。至少三分钟后输入命令/timings paste(sponge端为/sponge timings paste)。建议等待的时间长一些，时间短了获取的数据不够准确。输入/timings paste后如果成功的的提示应该是这样的 
如果出现了红色的提示，如 A.(只出现在Timings v2)
提示你需要等待至少3分钟才能获取报告，你需要等一会儿 B.
说明服务器的网络有问题，是你的服务商禁止了外网或者dns污染而导致的 3.复制生成的链接并用浏览器打开(打开速度可能会有点慢，特别是timings v2) II.分析Timings及解决方法 一、创建服务器的Timings报告 注：分析Timings的资源都以mcbbs内的问答帖中的链接为主，教程兼顾Timings v1与v2，分析方法相同 在Timings v1中，将会讲述如何分析timings 而Timings v2只是Timings v1的进阶版，只会补充一些新用法 Timings v1 除sponge和paper核心，都是使用Timings v1 Timings v1没有过多的分类，界面也很简陋粗糙 在开始学习分析Timings前，我们需要知道以下项 在报告的顶端，我们可以看到这些项
在事件部分，我们可以看到这些项
注释： ①TPS=tick per second,每秒游戏刻,最大值为20 ②如ResidencePlayerListener::onPlayerMove(PlayerMoveEvent)这个事件，关键词为Residence，PlayerListener，PlayerMove，说明是领地插件监听玩家移动的事件 ③Minecraft中，把每秒划分成等时长的20份即每份50毫秒，每份50毫秒就是一次游戏刻，而大约每50毫秒就会执行一次游戏刻，。实际上Minecraft会动态调整每次等待的时间，以尽量满足每秒执行20次游戏刻的目标 当了解了这些项后，就可以开始正式分析Timings了 分析Timings有三步：读报告，找到问题，解决问题 1.读报告 最上面的Minecraft Total是原版事件部分，包括实体，区块，玩家连接和mod物品等，通常这个部分也是占用最大的。 接下来是Plugins 插件事件部分，Timings v1将每个插件的事件分开了而不是窝在一起，有时候插件报错，玩家的滥用，编写插件的人水平有限等都会导致插件占用很高，所以常常插件占用可以比得上原版事件。 最下面是Minecraft整个部分，原版事件和插件事件的总和，推荐从这里入手分析！,在这部分，从上到下，最上方的就是占用最高的，而最下方的是占用低的,同时事件中占用情况分为红色，黄色和黑色。 红色：事件处理占用严重，建议必须优化 黄色：事件处理占用较严重，可选择优化 黑色：事件处理占用一般，不建议优化 2.找到问题 看到密密麻麻的数据时，很多人会不知所措，不清楚以哪种数据为基准。在此建议以Pct Total为主，Pct Tick为辅。Pct Total的意思就是处理了所有所有次该事件占时间的占比(一定小于等于100%)，Pct Tick的意思就是处理1次该事件占时间的占比(可以大于100%，甚至达到百分之几千)，他们的卡服的影响是不同的。Pct Total是持续，总体上的影响。Pct Tick是瞬间的影响，通常Count(处理事件数)数也很少。如果你的服务器TPS一直很低 应该主要注意Pct Total。如果你的服务器TPS突然降低又恢复，应该留心Pct Tick。因此我们根据之前的前面的图可以发现Activated Entities占用最大，Sync Tasks占用其次。还需留心的是VirtualMenu BetterRTP TPAPro等插件导致的突发卡服。这样Timings的分析就完毕了。 但是新手分析的时候很容易出现以下错误 A.把Full Server Tick认为是卡服原因 很多人看到Full Server Tick就认为是它导致卡服的，可是你翻译一下 就是服务器总事件计算 即服务器内处理所有事件之和，既然是全部事件之和了，怎么能看出原因呢？ B.重复分析一条事件链上的事件 绝大多数人会从占用多的往占用低的看，当分析完上面的事件后又会看下面事件，给出卡服原因的时候常常会这样写。
但是，这些人并不知道的是，EntityCat是TickEntity的子事件
通过树状图，我们可以看出EntityCat是TickEntity中的一部分。既然TickEntity已经包括了EntityCat，那也重复的意义和在呢?所以这句话应该改为 TickEntity中的EntityCat卡服 Timings v2 仅sponge和paper核心使用，但使用最广泛 Timings v2分为五个部分-----可视化数据图，timings主区，区块数据，配置文件和插件 1.可视化数据图 上面的文字部分是用来显示一些基本数据的 Uptime：服务器运行时间 Max Players：服务器玩家上限 Max Memory：服务器分配的最大内存值 Online Mode：正版验证模式 MOTD：服务器进入前界面的信息 Version：服务端核心版本 下面的Logging Period是显示一些重要性能数据 TPS：每秒游戏刻 TPS Loss：每秒游戏刻损失 Players：当前玩家数 Tile Entities：当前方块实体数 Entities：实体数(注：Timings 的实体计算方式和插件中计算实体的方式有很大差距，建议以插件为准) Chunks：区块 另外显示了折线图可以让你更好的知道服务器变化情况 *最近的Timings可以显示服务器内的GC(Garbage Collection,垃圾回收)的耗时情况 GC垃圾收集，Java提供的GC可以自动监测对象是否超过作用域从而达到自动回收内存的目的。 如果你看到GC的回收时间很长，服务器内存占用很高，这很可能是服务器内存泄漏了。 你可以在服务器启动参数内添加一些GC参数 或者使用这里的启动参数 2.Timings主区 从上往下是事件(在v1中已经解释了什么是事件)占用的情况，每个事件的下方会有一个Total(xx%,xxs,xx% of tick)，前面的%就是Pct Total，在左方有很多蓝色的小按钮，点击后会展开显示它的子事件，与v1同理，越靠前的占用越大，说明越导致服务器tps降低。如minecraft::world Chunks这个事件就是主世界区块计算的事件，由于timings v1已经细讲了，v2就不再多讲了。 3.区块数据 Regions(区域)不同于Chunks(区块)，一个Region占了512X256X512的方块，而一个Chunk只占了16X256X16的方块，比Region小很多。在这里面你可以看到每个Region中有多少实体，多少方块实体，还可以看出他们到底是什么实体(点击右方白色三角形展开即可)。但这里的数据并不准确，会比服务器内实体少 4.配置文件 你可以看到服务器中spigot.yml bukkit.yml paper.yml的配置，可以为你省去翻配置文件的烦恼，也可以让他人在分析Timings的时候可以更好地为你出谋划策。 5.插件 这个部分显示了插件的版本，插件作者和每个事件的占用情况，蓝色插件名右方为版本，Authors右方为作者。 如果没有这一栏，请将bukkit.yml中的plugin-profiling设置为true III.实例分析 学习了这么多，我们就要开始在实战中分析一些实例 实例1(插件服) 难度：0.5 服务器虽然已经超载但是情况不严重，TPS还可以保持在18-19左右，我们依然从Pct Total排名上看，实体类和区块类是事件处理占用的前两名，实体中占用较大是Spider蜘蛛和Villager村民，蜘蛛在正常情况下不可能占用很高，所以高概率是玩家在使用刷怪笼刷蜘蛛。 因此优化方法为 1.使用相关插件降低刷怪笼刷怪速度并减少实体碰撞箱 2.降低村民AI，如有必要可以限制繁殖 3.适当降低view-distance(可选) 实例2(mod服) 难度:2 服务器负载已经超过了200% 从timings底端的Pct Total排名可以看出，最严重的是TileEntityTick(方块实体的处理，方块实体指箱子，熔炉等可交互方块)，其次是Connection Handler(玩家做的事情都算这个事件)。细看方块实体我们可以看到是SpecialFlower和Hopper这两个东西导致的，SpecialFlower是植物魔法中的花(特别是产能话，卡服严重)，漏斗是原版物品(可能包括mod物品中的管道运输，卡服原因很简单，因为这种传输方块一直在传输物品) 因此对于该Timings的优化方法为： 1.删除植物魔法mod或者极大程度限制使用，比如设置专门产能的地方 2.限制玩家使用管道运输或增加管道响应时间 3.提升服务器配置，限制玩家多次登录，如多次登录卡服的禁止登录一段时间 IV.卡服事件大全及优化方法 原版类
Mod/插件类(持续更新)
|
| |
Epilogue —— Express Thanks 引用链接： 让喵来分析MOD服卡顿原因,手把手教你优化TPS! BoneStudio —— 插件服 从负基础萌新到大触 |入门|进阶|优化| & [机翻教程] Villager Optimiser —— 优化1.14.2以上的村民寻路以减少卡顿 [1.14.2-1.15] LagAssist —— 不可直视的九合一优化插件[1.8-1.14] https://www.mcbbs.net/thread-881861-1-1.htmlLaggRemoverPlus —— 优化清理 | 智能延迟清理系统 [全版本] NoSpawnChunks —— 老牌的服务器优化插件,给你区块来次降温吧 |
那1.15.2 Chunk provider tick - doChunkmap很高怎么优化
使用timings出现这种情况应该怎么办
