本帖最后由 EmptyLava 于 2021-11-7 17:45 编辑 
来自群组: Complex Studio
| 
 | 
| 
 | |
| 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是瞬间的影响,如果Pct Tick的数值大,通常Count(处理事件数)数也少。 如果你的服务器TPS一直很低,应该主要注意Pct Total。如果你的服务器TPS突然降低又恢复,应该留心Pct Tick。因此我们根据之前的前面的图可以发现Activated Entities占用最大,Sync Tasks占用其次。还需留心的是VirtualMenu BetterRTP TPAPro等插件导致的突发卡服。这样Timings的分析就完毕了。 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.html LaggRemoverPlus —— 优化清理 | 智能延迟清理系统 [全版本] NoSpawnChunks —— 老牌的服务器优化插件,给你区块来次降温吧 | 
2021.12 数据,可能有更多内容
| 
 | 
| 
 | |
| 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 个字符纯文本:31516 字节 - 更新日志 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后如果成功的的提示应该是这样的    II.分析Timings及解决方法一、创建服务器的Timings报告注:分析Timings的资源都以mcbbs内的问答帖中的链接为主,教程兼顾Timings v1与v2,分析方法相同在Timings v1中,将会讲述如何分析timings而Timings v2只是Timings v1的进阶版,只会补充一些新用法Timings v1除sponge和paper核心,都是使用Timings v1Timings v1没有过多的分类,界面也很简陋粗糙   
 在事件部分,我们可以看到这些项 
 
 注释:①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是瞬间的影响,如果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.重复分析一条事件链上的事件绝大多数人会从占用多的往占用低的看,当分析完上面的事件后又会看下面事件,给出卡服原因的时候常常会这样写。 TickEntity和EntityCat导致卡服 但是,这些人并不知道的是,EntityCat是TickEntity的一部分  TickEntity中的EntityCat卡服 Timings v2仅sponge和paper核心使用,但使用最广泛Timings v2分为五个部分-----可视化数据图,timings主区,区块数据,配置文件和插件1.可视化数据图  GC垃圾收集,Java提供的GC可以自动监测对象是否超过作用域从而达到自动回收内存的目的。 垃圾回收可有效使用内存和防止内存泄露。垃圾回收器通常是作为一个单独的低优先级线程运行,不可预知的情况下对内存堆中已死亡或长久无使用的对象进行清除和回收。 回收机制:分代复制垃圾回收、标记垃圾回收、增量垃圾回收等方式。 如果你看到GC的回收时间很长,服务器内存占用很高,这很可能是服务器内存泄漏了。你可以在服务器启动参数内添加一些GC参数或者使用这里的启动参数2.Timings主区  3.区块数据   5.插件  III.实例分析学习了这么多,我们就要开始在实战中分析一些实例实例1(插件服) 难度:0.5   实例2(mod服) 难度:2   IV.卡服事件大全及优化方法原版类 
 
 | 
| 
 | |
| Epilogue —— Express Thanks 引用链接:让喵来分析MOD服卡顿原因,手把手教你优化TPS!https://www.mcbbs.net/thread-939322-1-1.htmlBoneStudio —— 插件服 从负基础萌新到大触 |入门|进阶|优化| & [机翻教程]https://www.mcbbs.net/thread-916822-1-1.htmlVillager Optimiser —— 优化1.14.2以上的村民寻路以减少卡顿 [1.14.2-1.15]https://www.mcbbs.net/thread-876653-1-1.htmlLagAssist —— 不可直视的九合一优化插件[1.8-1.14]https://www.mcbbs.net/thread-881861-1-1.html LaggRemoverPlus —— 优化清理 | 智能延迟清理系统 [全版本]https://www.mcbbs.net/thread-715006-1-1.htmlNoSpawnChunks —— 老牌的服务器优化插件,给你区块来次降温吧https://www.mcbbs.net/thread-733901-1-1.html冥想了一夜的服务器启动参数https://www.mcbbs.net/thread-839828-1-1.html | 
来支持一下,问答区脸熟人员之一hh。
咋没人呢
咋没人呢
很实用
辛苦大佬了! 受益颇丰
还想问大佬一件事.. 请问 doTick 是什么意思呀
还想问大佬一件事.. 请问 doTick 是什么意思呀
ParalyzedZero 发表于 2020-3-2 18:36
辛苦大佬了! 受益颇丰
还想问大佬一件事.. 请问 doTick 是什么意思呀
Tick的定义:Minecraft中,把每秒划分成等时长的20份即每份50毫秒,每份50毫秒就是一次游戏刻,而大约每50毫秒就会执行一次游戏刻,。实际上Minecraft会动态调整每次等待的时间,以尽量满足每秒执行20次游戏刻的目标
dotick就是执行游戏刻呗,相当于执行游戏内的事件
EmptyLava 发表于 2020-3-2 18:41
Tick的定义:Minecraft中,把每秒划分成等时长的20份即每份50毫秒,每份50毫秒就是一次游戏刻,而大约每50 ...
谢谢大佬 如果doTick过高 优化什么好呢~
ParalyzedZero 发表于 2020-3-3 20:25
谢谢大佬 如果doTick过高 优化什么好呢~
...dotick一般不作为判断卡顿的依据
dotick和full server tick性质一样的,意义不大
要看下面的dotick里面的子事件
顶一下
顺便多谢
顺便多谢
特别详细 弄好了就才能够好
详细,通俗易懂,支持一下
栗子:https://timings.aikar.co/?id=6a4c4a9f669545abb0e6a53e99b80920
本人表示不玩服务器 
Fur_Xia 发表于 2020-3-5 10:21
那1.15.2 Chunk provider tick - doChunkmap很高怎么优化
栗子:https://timings.aikar.co/?id=6a4 ...
服务器自带的区块回收是Bukkit.yml的chunk-gc吧,我设置的是period-in-ticks: 300
async-chunks对区块优化有作用吗?
之前在PaperSpigot的disord里面,他们的工作人员说1.15.2插件没有办法优化区块计算。
而且我对世界有做过Pregenerate。
这个是今天下午的timings report 看起来应该还是区块计算的问题。
感谢您的解答!
顶一下,好厉害啊:9
Fur_Xia 发表于 2020-3-5 17:03
服务器自带的区块回收是Bukkit.yml的chunk-gc吧,我设置的是period-in-ticks: 300
async-chunks对区块优 ...
async-chunk是哪个配置文件中的?
异步区块加载吗
非常好nice
对于1.7.10模组服来说 如遇见某种模组物品卡顿 可以降低这个物品的工作频率,话说写删模组有点过分了--
服务器目录下的tileentities这个文件进去之后找到卡服的物品 默认是
tick-interval: 1
改成5或者更高
能有效的对症**
服务器目录下的tileentities这个文件进去之后找到卡服的物品 默认是
tick-interval: 1
改成5或者更高
能有效的对症**
java.io.IOException: Server returned HTTP response code: 500 for URL: http://paste.ubuntu.com/
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1900) ~[?:1.8.0_241]
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1498) ~[?:1.8.0_241]
at org.bukkit.command.defaults.TimingsCommand$PasteThread.run(TimingsCommand.java:240) [PaperSpigot-1.8.8.jar:git-PaperSpigot-f6fba00-9935adc]
很不错得教程 学习了
 本帖最后由 薄荷子 于 2020-3-18 05:58 编辑 
生成的txt报告很懵,不知道该从哪看起,有没有办法将它排序或者将txt导入网页之类的。
生成的txt报告很懵,不知道该从哪看起,有没有办法将它排序或者将txt导入网页之类的。
加油,等你更新。
 本帖最后由 EmptyLava 于 2020-3-18 07:51 编辑 
只能自己看前面的time值有多少了,没办法。但是也能读,你不要一个个看,找通常占用多的如包含entity/tile/chunk/handler
如果服务器能上github的话,尝试下https://www.mcbbs.net/forum.php?mobile=1&mod=viewthread&tid=823209
用spark采样
薄荷子 发表于 2020-3-18 05:57
生成的txt报告很懵,不知道该从哪看起,有没有办法将它排序或者将txt导入网页之类的。 ...
只能自己看前面的time值有多少了,没办法。但是也能读,你不要一个个看,找通常占用多的如包含entity/tile/chunk/handler
如果服务器能上github的话,尝试下https://www.mcbbs.net/forum.php?mobile=1&mod=viewthread&tid=823209
用spark采样
顶一下,好厉害啊
十分感谢,叫我在看会学习一下
实用教程
大佬辛苦了,收获满满!
EmptyLava 发表于 2020-3-18 07:29
只能自己看前面的time值有多少了,没办法。但是也能读,你不要一个个看,找通常占用多的如包含entity/til ...
大大佬,正好,我spark出现
an error occurred whilst uploading the results
上载出错了Orz
 
 
 
 
 
 
 
 
 
 
