本帖最后由 EmptyLava 于 2022-8-19 00:06 编辑
|
| |
- 这篇教程的意义？ - ①目前站内的100%关于配置文件的优化教程，大多都是凭借前人经验与个人感觉，而实际的优化效果可能欠佳，不但优化效果差，还会严重影响玩家体验。而本篇教程就是为了在配置文件中找出最有效的配置项，以及最佳优化效果时的数值，并结合形成整个配置文件优化。 ②高版本(1.13+)教程稀缺，大多数还是1.7-1.9/1.12的教程，导致玩家无法得知新增配置项的意义而使用旧教程中的配置项修改推荐，损失了大量服务器性能。 - 你的测试数据怎么让我们信服？ - 我们每次测试都会记录下测试数据，然后公布在腾讯文档上(以后可能会发布在pastebin上)，每一次测试都可以寻找到spark链接和当时的TPS/Chunks/Entities/Tiles，同时我们会尽量减小测试的误差。 - 测试平台是? - Windows Server 2016 / Intel Xeon E5 2689 2 Cores / 6GB 服务器进程的内存分配为4000M 启动参数为 java -jar -Xmx4000M -Xms4000M server.jar 服务器版本在测试时会有说明，大部分为1.12/1.15，也有1.13/1.14/1.16内容 服务器种子为114514(防止地图建筑等对测试的影响) 数据收集默认使用Spark - 我的服务器是1.11或更低版本的，看你的这篇教程有用吗？ - 对于这些服务器版本，教程所说的部分配置项可能不存在，但您仍然可以参考本篇教程 - 测试原则 - 测试用服务端不会在每次测试后进行更换，但可能会重新生成地图。 - 若测试的配置项为A，但配置项B会大幅影响A的作用，则禁用配置B。 - 默认区块加载数为10或16，不同于这两个值的情况会额外说明。 - 其他 - 结论的表格中的“综合提升”有一定参考价值，在实际环境中的提升效果会有一定折扣(除非服务器没有插件占用)，‘针对提升’是针对某些单一方面的(看针对提升的效果时，请注意这个配置项测的是什么)，一般反映的是这项配置的最大优化能力，请勿把针对提升当做此配置的真实优化水平! - 这种字体一般是对前文的解释或者提醒，它一般在表格外 [1]这种跳转链接也是对前文的解释，但它一般是在表格中。因为过长的注释会影响表格的美观 [1.13+]指1.13及更高版本；[1.13-]指1.13及更低版本 - 更新计划 - 当前进程: 重写教程(使用原测试数据) 进度■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ 3/18 点击最上方目录选择内容 |
2021.12 数据，可能有更多内容
|
| |
- 这篇教程的意义？- ①目前站内的100%关于配置文件的优化教程，大多都是凭借前人经验与个人感觉，而实际的优化效果可能欠佳，不但优化效果差，还会严重影响玩家体验。而本篇教程就是为了在配置文件中找出最有效的配置项，以及最佳优化效果时的数值，并结合形成整个配置文件优化。②高版本(1.13+)教程稀缺，大多数还是1.7-1.9/1.12的教程，导致玩家无法得知新增配置项的意义而使用旧教程中的配置项修改推荐，损失了大量服务器性能。 - 你的测试数据怎么让我们信服？- 我们每次测试都会记录下测试数据，然后公布在腾讯文档上(以后可能会发布在pastebin上)，每一次测试都可以寻找到spark链接和当时的TPS/Chunks/Entities/Tiles，同时我们会尽量减小测试的误差。 - 测试平台是?- Windows Server 2016 / Intel Xeon E5 2689 2 Cores / 6GB服务器进程的内存分配为4000M启动参数为 java -jar -Xmx4000M -Xms4000M server.jar服务器版本在测试时会有说明，大部分为1.12/1.15，也有1.13/1.14/1.16内容 服务器种子为114514(防止地图建筑等对测试的影响)数据收集默认使用Spark - 我的服务器是1.11或更低版本的，看你的这篇教程有用吗？ - 对于这些服务器版本，教程所说的部分配置项可能不存在，但您仍然可以参考本篇教程 - 测试原则- 测试用服务端不会在每次测试后进行更换，但可能会重新生成地图。- 若测试的配置项为A，但配置项B会大幅影响A的作用，则禁用配置B。- 默认区块加载数为10或16，不同于这两个值的情况会额外说明。 - 其他- 结论的表格中的“综合提升”有一定参考价值，在实际环境中的提升效果会有一定折扣(除非服务器没有插件占用)，‘针对提升’是针对某些单一方面的(看针对提升的效果时，请注意这个配置项测的是什么)，一般反映的是这项配置的最大优化能力，请勿把针对提升当做此配置的真实优化水平!- 这种字体一般是对前文的解释或者提醒，它一般在表格外 [1]这种跳转链接也是对前文的解释，但它一般是在表格中。因为过长的注释会影响表格的美观 [1.13+]指1.13及更高版本；[1.13-]指1.13及更低版本 - 更新计划- 当前进程: 重写教程(使用原测试数据) 进度■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ 3/18 点击最上方目录选择内容 |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Part 1 —— Server.properties适用服务端:All1. View-distance(Test ID:2-7)描述:服务器玩家能看见的最大世界距离，单位:区块数默认值: 代码:
①:
在1.13-的服务器内区块加载规则是加载玩家周围的[(2n+1)^2]个区块(n=view-distance数值)，这个和view-distance的解释是吻合的。但是在1.14的区块加载数变成了[(2n+3)^2]，1.15变成了[(2n+5)]^2，与解释不符，后续未进行研究。建议:生存服(1.12-):设置为6-8，若实体压力大可以降低为4-5生存服(1.13+):设置为3-6，若实体压力大可直接设置为3Mod服:根据TPS状况而论，一般设置为4-5 Part 2 ---- Bukkit.yml适用服务端：Bukkit，CraftBukkit，Spigot，Mohist，Paper，Catserver等基于bukkit的服务端1.ticks-per(Test ID:15-19|126-130)描述:每多少ticks执行一次以下任务，包括世界保存和生物生成默认值: 代码:
2.spawn-limits(Test ID:20-24|144-148)描述:玩家所在世界的最大生物存在量默认值: 代码:
 服务器内的实体满足这个公式(这个似乎是官方给的，高版本中，256[16*16]可能需改为289[17*17]，具体版本不明，下文都以289为准)  此外spawn-limits还会受其他参数影响[仅1.13或更低版本]:默认配置文件下，只要所在区块被kill @e或killall了，短期内(数分钟至数小时)实体不可能恢复原样。经过排除后是spigot.yml的mob-spawn-range影响的，默认值为4导致刷怪量大大减少(如上方踩坑时的实体图，理论实体数为1952，实际仅四分之一)所以，你的服务器刷怪少大概率是mob-spawn-range导致。测试内容:①:参数不同时玩家在出生点的时候服务器状况[1.12]②:参数不同时玩家在出生点的时候服务器状况[1.15]①在spigot.yml设置了mob-spawn-range为等同于视野距离的数值，防止怪物刷怪数量减少的问题(仅1.13或更低版本会出现此现象)，①②的spawn-limits默认值均以正常的10倍计，模拟10人时的情况( 1 0 倍 杠 杆 )，接下来还会有多个测试项通过高倍率数值来放大现象。结果: ①:
建议 生存服(1.13-):推荐将各数值设置为原来的30%至75%。 生存服(1.14+):推荐将各数值设置为原来的20%至75%。Mod服:推荐将各数值设置为原来的20%至60% 3.chunk-gc(Test ID:33-36)chunk-gc.period-in-ticks (多少tick回收一次区块，默认值=600，即30秒)chunk-gc.load-threshold[1.13-] (两次区块回收之间，需要加载多少区块才能进行下一次区块回收，默认=0)这两项数值不会影响很多性能这是测试chunk-gc.period-in-ticks在不同情况下的性能占用: (耗时1h)①：在出生点时，不加载额外区块，区块回收占用[1.12]②：匀速移动200格后，区块回收占用[1.12]
默认值时，区块回收占用几乎为0(实际情况是根本找不到区块回收这一项，应该是小于0.01%)，设置为1时，玩家静止不动时区块回收占用略高(0.80%，移动时虽然区块回收占用有1.05%，但是加快了服务器内区块回收，及时减少了区块回收的数量，能挽回区块回收带来的占用亏损，甚至还赚了一些。但我不建议您设置为1，如此频繁的区块回收在服务器玩家过多，区块数量很多时(如大于5000)，区块回收占用就很可怕了，因此建议您设置的数值不要低于100。 Part 3 Spigot.yml适用服务端:Spigot Paper Mohist Catserver等1.Mob-spawn-range(Test ID:25-32)(以玩家为中心的半径多少区块内可以刷怪，1.12-默认值=4,1.13+默认值=8) 注意： 数值设置大于9，也不会在9区块外刷怪，因为原版刷怪机制为：生物离玩家最多128格。 数值低于8时，服务器内刷怪量低于正常刷怪量[仅1.14以下版本]。(使用/killall命令前)   在1.14以下版本的服务器上，较低的数值会导致刷怪量急剧减少，这是因为bukkit.yml内的spawn-limits限制了平均一个区块内能生成多少生物，而mob-spawn-range会阻止较远的区块生成怪物，两项配置的共同作用使得刷怪数量远低于正常水平 测试内容: ①修改mob-spawn-range，bukkit内spawn-limits为原来的3倍时候，服务器内生物刷新的状况[1.12] 附加参数: ①view-distance=16结果/建议/提醒 ①
在1.14或高版本的服务器上，mob-spawn-range的作用类似bukkit.yml中的生物生成配置，测试时设置为3的刷怪速度只有设置为8刷怪速度的10%左右,但这项数值不会影响刷怪量不过为了配合ticks-per，推荐将这项数值修改为3~4在1.14以下版本的服务器上mob-spawn-range会使刷怪量大幅减少将mob-spawn-range设置为9以上，相当于默认刷怪机制将mob-spawn-range设置为1，还是能见到刷怪，但已经很少了如果您的服务器内玩家很多，此项配置可改为3(但是较低的mob-spawn-range数值会导致刷怪塔的性能不能被完全榨干)如果您想让您的服务器回归bukkit/原版刷怪机制，修改到8或10也是一个不错选择，而且带来的服务器负担也不是很多(0.8%，换算为事件耗时约为8%) 2.entity-activation-range(Test ID:37-42)(以玩家为中心，生物距离玩家多少格内才被激活/每秒被激活的数量限制，默认值在下方，已折叠)entity-activation-range: #1.15新增，设置对村民的飞行怪物的激活范围 villagers: 32 flying-monsters: 32 #1.15新增，设置工作的村民的激活范围 villagers-work-immunity-after: 100 villagers-work-immunity-for: 20 villagers-active-for-panic: true #1.14新增，设置对袭击怪物的激活范围 raiders: 32 #设置为动物/怪物/掉落物/水流的激活范围 animals: 32 monsters: 32 misc: 16 water：16 #1.14新增，是否对无活动村民进行计算 tick-inactive-villagers: true #1.14新增，设置对生物被激活的速度限制 wake-up-inactive: animals-max-per-tick: 4 animals-every: 1200 animals-for: 100 monsters-max-per-tick: 8 monsters-every: 400 monsters-for: 100 villagers-max-per-tick: 4 villagers-every: 600 villagers-for: 100 flying-monsters-max-per-tick: 8 flying-monsters-every: 200 flying-monsters-for: 100 测试内容: ①不同entity-activation-range.monsters数值时，玩家周围均匀分布500只实体的服务器占用[1.12] 附加参数: ①:禁用区块回收 ②:将paper.yml内的despawn-ranges.soft设置为128(否则服务器内的怪物会被缓慢删除，影响测试效果) ③:view-distance=16结果/建议/提醒: ①
当entity-activation-range.monsters为默认值一半的时候，怪物的耗时降低了一半多，但是16这个数值对于玩家是几乎无法游玩的(看到的怪物大多都没有激活，玩家没有游戏体验)，设置到24的时候，怪物的占用有30%的降低。而animals/villagers等其他配置的优化效果和monsters是一样的，可以根据表格内的优化效果修改，且动物对于玩家的影响不大，改为12也没什么关系。村民被激活时的寻路AI占用了大量的tick。flying-monsters貌似仅仅是指幻翼。misc是指掉落物，如果你的服务器内有很多生成掉落物的机器(如:用岩浆块杀死怪物的刷怪塔，地毯机，0t机器)，可以适当降低此项，但不能设置为1或更低，否则会出现实体无法捡起等一系列奇妙的bug。water指水流，在高空流水多的时候降低此数值可能对TPS有小幅帮助(流水卡服主要是更新周围方块)。wake-up-inactive在村民多的时候对TPS有一定帮助，村民占用高时可改为false，若出现村民不转换职业等问题请设置为true。 因此，如果您的服务器是养老生存服，且大型机械非常多，玩家又喜欢养动物，可以设置为viilagers:16 flying-monsters:18~24 monsters: 18~24animals: 8~12 misc:2~4 water:16wake-up-inactive设置为原来的50%或更低。如果您的服务器是RPG服，这几项建议略微修改注意:过低的monsters数值会导致刷怪塔效率降低，甚至不工作!(monsters数值是指怪物与玩家的水平距离，与竖直距离无关) 3.max-tick-time(Test ID:48-52)(在服务器的两个tick之间，实体/方块实体最多允许被计算多长时间，单位毫秒，默认tile:50，entity:50)默认数值已经足够了，如果你的服务器实体/方块实体占用极高，降低这两项数值可能会有显著的提升。如果实体/方块实体占用不高如果设置太低，实体/方块实体会跳过计算，可能会导致玩家体验下降/漏斗分类机堵塞之类的bug。测试内容:①使用Spigot核心(因为paper禁用此项)，在不同max-tick-time.entity数值的情况下，1400只实体的占用，以及玩家怪物计算被跳过的情况[1.12] (由于tile很难达到50ms/tick，因此不测试max-tick-time.tile，且max-tick-time.entity的规律适用于tile) 附加参数: ①View-distance=16 ②/gamerule doMobSpawning false(禁止生物自然生成) ③使用timings v1进行数据收集，而不是spark(spark对于低tps时的采样效果不好)结果/建议/提醒: ①
max-tick-time.tile同理针对提升中的“最高”指的是当服务器内实体/方块实体达到100% tick占用时(即50ms 达到了默认值的阈值)，但是大多数服务器都无法达到这个数值，所以您需要使用Timings进行采样(输入/timings on 三分钟后输入/timings paste)，然后在输出结果的网页内内找到"tickentity"一项的Pct Tick[11] (如下图)  如果max-tick-time没有修改过，您又需要优化，您可以将max-tick-time.entity修改为[tickentity最高时占用(%)*50-5]，大约会带来10%的实体占用下降如果您修改过max-tick-time,且tickentity占用(%)*50≈max-tick-time.entity，就不建议再改了。max-tick-time.tile与max-tick-time.entity同理，只是tile的占用=每一种tile占用的总和，需要自己计算所有tile总和。注意事项:①此配置项在paper上不生效(已经在paper.yml找过了，没有启用这个配置项的选项，在paper上的数据请看腾讯文档内Test ID:43-47)，是自己禁用的 PaperSpigot does not offers "max-tick-time" PaperSpigot 不支持max-tick-time ②降低此项可能会给服务器带来不稳定，特别是RPG服务器，如数据不同步等，但是它带来的优化效果真的很可观 There’s a reason PaperSpigot doesn’t offer it: You shouldn’t use it! That system is fundamentally broken in implementation and can cause inconsistencies with your server. 这就是PaperSpigot不支持它的原因，你就不应该用它!它从源头上破坏了服务器的正常运转，导致了服务器的不同步 翻译自https://aikar.co/2015/10/08/spig ... -use-max-tick-time/ 注:aikar是paperspigot的维护者之一 4.ticks-per(Test ID:53-58)(漏斗多少tick传输一次，多少tick检查一次，默认hopper-transfer: 8 hopper-check:1) hopper-amount(漏斗一次传输几个，默认值为1，此项不影响性能，但是会影响效率)测试内容: ①100个漏斗传输物品时，不同数值下(这三个数值的1倍，2倍，3倍，4倍，5倍)，漏斗的占用[1.12]其他参数: ①/gamerule doMobSpawning false(禁止生物生成，因为测试的时候动用了summon命令生成怪物来生成掉落物) ②使用spigot核心结果/建议/提醒:①:(8,1,1代表hopper-transfer: 8 hopper-check: 1 hopper-amount:1)
不修改数值时，大约每个漏斗会占用0.01%(0.005ms)的服务器tick，多个漏斗叠加的占用还是挺多的(一般用到漏斗的大型机器有1000+个，差不多就要占用10%tick了)。按照站内一些教程给的推荐数值(3x;24,3,3), 大概只能降低20%的漏斗tick，意义不大，即使这个数值设置到全站给过的最高数值(5x;40,5,5),也只能降低40%占用。这是因为Tile与Entity不同，Entity由于受到entity-activation-range的限制，不工作的实体占用几乎为0。而Tile只要区块执行区块刻，就一定有计算，在不工作的情况(见表格第六行)也有一定的占用。同时，修改了hopper-amount后，物品每次传输间隔时间和数量都有变化，许多和漏斗有关的机器都可能会出现Bug，如抽.奖机，分拣机。为了减少或防止这种不同步，hopper-transfer数值最好要是hopper-check的倍数。因此，对于生存服，如果服务器内的漏斗很多，那还是建议设置为(16,4,2 hopper-check也占用了一定性能，所以多提升了一些)，如果漏斗占用不高，只建议更改hopper-check。对于RPG服，且又需要漏斗的，可以改为(1,4,32)，这样漏斗传输速度很快，传输时间变短，占用会下降很多。对于Mod服，修改为5x~10x即可。 5.max-tnt-per-tick(Test ID:122-125)(每个tick最多计算多少个tnt，默认=100)测试内容: ①不同数值时5000余个TNT爆炸时，服务器的状况以及TNT的占用[1.12] ②不同数值时2000余个TNT爆炸时，服务器的状况以及TNT的占用[1.15] 附加参数: ①view-distance: 16结果/建议/提醒:
在max-tnt-per-tick为默认值时，爆破5000余个TNT时，TPS降低较多，仅能保持9~10，但是TNT的处理速度很快，15秒不到的样子。在max-tnt-per-tick设置到20后，能明显看见了TNT计算滞后，处理很慢。同时实体积压，60秒后还有4000多个实体(已被点燃的TNT)待处理。设置为5和1时，TNT的爆炸处理明显缓慢，周围TNT甚至出现了没有被激活的情况，到最后还有一部分TNT没有被引爆，这样会导致许多需要TNT的大型机器威力下降甚至炸膛(少量TNT复制机器不受影响)，这也明显减弱了熊孩子放置大量TNT的威力。对于任何服务器，设置为20即可(也可设置为10)，高于这个数值的优化效果较差，低于这个数值会导致TNT计算滞后。对于一些正在用TNT清理区块的服务器，可以临时恢复为100。 Part 4 Paper.yml适用服务端:Paper1.world-settings.max-chunk-gens-per-tick[1.13-](每个世界中每tick最多生成多少区块，默认=10) world-settings.max-auto-save-chunks-per-tick(每个世界中保存地图时，每tick最多保存多少区块，默认=24) world-settings.max-chunk-sends-per-tick[1.13-](每个世界中每tick最多发送多少区块，默认=81)注:生成≠发送，生成这里指的是从未被加载过的区块，发送指的是已经加载过的区块这三个配置项放在一起的原因: ①它们的功能都相似 ②它们对于服务器的优化效果不是很明显(除非服务器玩家跑的比香港记者还快/网速感人)，但是这三项数值对于提升服务器的稳定性(可以让tps更平滑，减少跑图/世界保存带来的突发tps降低)测试内容: ①不同数值时，5倍移动速度平稳加载新区块时，服务器tps和CPU占用[1.12]附加参数: ①view-distance=16结果/建议/提醒: ①:由于world-settings.max-auto-save-chunks-per-tick优化效果很小，且这个数值不会影响性能，所以没放入测试（主要是测不出，强行测的话误差大）
虽然看着提升很大，但实际肯定不能这样用①测试的时候是飞行5倍速，速度为54m/s，那么每秒可以移动3.375个区块，同时视野距离为16，那么玩家每移动一个区块就会加载36区块(不考虑斜向)。这样的话每秒就会加载121.5个区块，不考虑网络的情况下(实际上网络没满)，max-chunk-sends/gens-per-tick都设置为1时，有80%+的区块被跳过加载了。正常的玩家疾跑速度是5.612m/s，换算下来在16视野距离时，每秒需要加载12.6个区块，如果减少80%的区块加载(区块只能加载到最大值的20%)那么玩家肯定无法接受，因此推荐平均每个玩家只能加载到最大值的70%，也就是8.5区块每秒，对应的max-chunk-sends/gens-per-tick就是0.425(当然，max-chunk-gens-per-tick可以更低，如0.35)。②这是一个世界性选项，作用在整个世界上，而一个世界又有很多玩家，我测试的时候是独自一人的，所以最终数值要乘以服务器玩家。③玩家加入的时候，会满速加载区块，大概3~5秒就要加载400~1000区块。为了防止这样的情况，还要增加max-chunk-sends/gens-per-tick数值 如果你需要对此项进行设置，可以参照该公式： max-chunk-sends/gens-per-tick的设置公式={[V*2+4]*S/320*P}*0.7+5 V=view-distance数值 S=玩家疾跑时的速度，默认=5.612。如果你的服务器玩家普遍加速，这个数值还要上升 P=服务器内玩家最多的那个世界的平均活跃人数(需要减去挂机人数，这一部分人不加载区块，只要不是核心跑图玩家就都建议去掉)最终数值取整(取上取下自由选择)，如果玩家会用鞘翅之类或者可以飞行，就把数值提高一些 如:某世界平均活跃玩家为30的服务器，view-distance=12，每个玩家拿着+100%移速的武器数值就应该设置为26*11.224/320*30*0.7+5=24.11，取整后为24这样每秒最多加载480格区块，平均每个玩家分到16区块；1名玩家正在进入服务器时，每名玩家也能分到12区块。既能保证玩家不流失体验，又可以略降服务器占用(如果服务器玩家频繁进出，效果会更好) 最后给三张不同数值下，区块加载的直观状况分别为表格中三个数值依次顺序时    2.Timings.enabled(Test ID:64-71)(是否开启timings，默认=true)Timings是一个服务器分析工具，虽然很轻量，但仍然会有一定占用，服务器不会每时每刻都用Timings。测试内容: ①在服务器的不同占用情况下(即每秒tick数不同时)，co.aikar.timings.FullserverTickHandler.stopTiming与co.aikar.timings.FullserverTickHandler.startTiming的总占用[1.12]附加参数: ①在第7/8个测试中，Entity-activation-range和Entity-tracking-range都为128结果/建议/提醒: ①:(耗时4h)
即使打开Timings，大约也只会占用0.15%~0.25%的服务器tick，不会随tps变化而变化。但是，如果你的服务器内安装了一些可以代替timings的插件，例如spark。那么你完全可以选择关闭这一项选择如果你偶尔需要使用Timings，又没有替代插件，我还是推荐保留了。如果你没用过....哦，那没事了，直接关掉吧，不用想。 3.world-settings.anti-xray.enabled(Test ID:72-81)(是否启用反透视，默认=false。这里不讨论其他配置，因为不会影响性能)注意:反透视的原理是服务器修改数据包，让服务器发给玩家的关于区块数据的数据包中都充满假矿，玩家收到数据包后，自己看不见的区域都会变成假矿。如果玩家正在用一些作弊mod透视矿物，他看到的将都是假矿测试内容: ①开启和关闭反透视的两种情况下，服务器的sleep占比和ServerConnection(数据包传输)的占用，并多次测试求平均值[1.12]附加参数: ①world-settings.anti-xray.engine-mode=2结果/建议/提醒①:(耗时3h,这里只给了求平均值后的结果，没给原值)
如果关闭此项，服务器占用变化不明显，但在未来的1.17版本可能会出现明显的优化效果。如果服务器是生存服，有需要反矿透，我建议直接打开，因为没有哪个反矿透插件占用比官方反矿透还低了。如果是其他类型服务器，开启它有什么意义呢(笑)，还不如关掉给玩家更好的体验。 4.world-settings.despawn-ranges(Test ID:82-85)(生物离玩家多远将会被删除,soft是缓慢地依次删除[随溢出实体数量增加而变快],hard是直接删除。默认值soft=32，hard=128)这里的soft不能比hard高，否则高出部分没有意义。而且不建议比spigot.yml内entity-activation-range.monsters低，否则可能怪物对你有仇恨却突然没了这项数值会尽量保证服务器内的实体回到bukkit.yml内spawn-limits限制的范围以下，除非实体不能再被删除了测试内容: ①新生成的僵尸=服务器内限制生物数量，且生物已经饱和的情况下，不同soft数值下服务器的状况(没有动hard，因为会改变实体机制)[1.12]附加参数:无结果/建议/提醒:①:(耗时3h)
在world-settings.despawn-ranges.soft降低到24后，实体减少了20%左右，最多可以降低27.9%的实体。设置到128后，实体相比32时多了至少50%。但是真有这么大的效果?实际会比这个小，因为在服务器中，玩家如果不加载区块，通常实体是不会多于限制的。只会有一些刷怪笼或者非自然生成的生物超过这个限制。而despawn-ranges的目的就是删除这些非自然生成的生物。当玩家跑图时，由于加载了新的区块，实体会明显超过限制，设置world-settings.despawn-ranges.soft的意义不是很大了。此时设置world-settings.despawn-ranges.hard会更有效(但hard对于服务器内一些实体的机制有影响，同时会减少刷怪[服务器内刷怪距离为24~128，比如设置world-settings.despawn-ranges.hard到64时，随机tick刷新的怪物离玩家距离可能为80，将被直接删除]，因此不建议设置到64以下)如果你的服务器玩家经常跑图，但是总体实体不是很多，可以适当下降world-settings.despawn-ranges.hard(比如降低到96)。如果你的服务器内实体特别多，而且你降低过spigot.yml的entity-tracking-range。可以将world-settings.despawn-ranges.soft设置和前面那个数值接近的水平。world-settings.despawn-ranges.soft也可以下降到80~96。如果你的服务器玩家都很肝，且他们抱怨某些实体总是会消失，那么world-settings.despawn-ranges.soft完全可以设置为64。 5.world-settings.optimize-explosions(Test ID:86-93)(是否开启paper对于爆炸的优化，死亡的实体会被立即清除等，从而减少爆炸占用。默认=false)开启后爆炸时的实体将被缓存而不是重复计算，1.15或更高的版本开启此项可能效果不明显测试内容: ①不同数量TNT爆炸时，TNT的占用和睡眠的tick占比[1.12] ②不同数量TNT爆炸时，TNT的占用和睡眠的tick占比[1.15]附加参数:无结果/建议/提醒①:
开启此项后，TNT的占用同比下降了10%~30%。同时TPS有一定幅度的提升，如果使正在使用盾构机等大型机器，会有显著的优化效果(平常的时候没有)。对于Essentials的禁止TNT爆炸，此项无效果。对于允许TNT爆炸但不破坏方块(仅造成伤害),此项仍有效果并且建议所有服务器都打开此项，因为没有副作用。 6.world-settings.hopper.disable-move-event(Test ID:93-97)(是否禁用漏斗的move事件，禁用后可以降低漏斗占用，但coreprotect，领地插件等可能无法记录或保护漏斗物品)注意:这个选项上方还有一个push-based[高版本已被移除]，可能可以对漏斗进行优化，但有重大BUG[详情见github issue #763 #354]，因此在后期版本删除了此项，本贴也不对push-based进行测试测试内容: ①当漏斗传输和不传输时，分别启用和禁用move事件时，漏斗的占用[1.12]附加参数:无结果/建议/提醒①:
将此项配置设置为true后(即禁用move事件)，漏斗的占用下降了25%~40%。但是此项配置不能在以插件玩法为中心的生存/RPG服中开启(通常安装了领地插件/CoreProtect等，会导致漏斗不被保护)，只能在以原版内容为中心的生存服中开启。因此启用此项前请三思，考虑是否要对漏斗move事件进行监听。 7.use-faster-eigencraft-redstone(是否启用theosib的红石优化算法，启用后对于红石的优化巨大。仅1.13~1.15可用，默认=false)注:由于Mojang在1.16大改红石机制，原算法的作者还没有更新适配1.16的新算法，因此这一项在1.16被移除了测试内容: ①:启用这项后对于红石计算的优化效果[1.13]附加参数: ①:view-distance=8(以后高版本除特殊情况外，默认=8，因为性能差异问题会影响结果)结果/建议/提醒:
启用后，对于红石的优化可以达到90%(活塞一类的优化很小)，总体能达到70%的优化效果。强烈建议服务器都开启这一项，除非启用后红石机器出现问题。 8.keep-spawn-loaded-range(Test ID:117-121)(出生点加载区块的范围，加载区块数=[(数值*2+1)^2]，默认值=4) keep-spawn-loaded(是否加载出生点区块，默认值=true)keep-spawn-loaded-range:0 和keep-spawn-loaded: false的区别：前者会加载出生点的1区块，后者不会加载出生点区块。除非玩家加入服务器并加载了区块。并且keep-spawn-loaded的部分是无法被卸载的另外，在2019年2月22日之前构建的paper.jar，在玩家加载出生点前，出生点区块不会被加载。测试内容: ①无玩家进入时，不同数值的keep-spawn-loaded-range能减少多少的tick占用[1.12] ②无玩家进入时，不同数值的keep-spawn-loaded-range能减少多少的tick占用[1.15] 附加参数:无结果/建议/提醒①:(耗时3h)
关闭keep-spawn-loaded或设置keep-spawn-loaded-range为0后，服务器内的Tick至少下降了2%(要看主城周围的实体/方块实体多不多，多的话这个优化效果会更好；如果服务器玩家经常蜗居在出生点，可能效果会变差一些)。如果关闭这一项，对服务器的优化可能是显著的(出生点实体多的情况下)。但是这可能会导致生存服中出生点的机器无法循环工作(如刷沙机，这样就要多点人了)，或者multiverse插件小概率出现无法用/mv tp命令传送到别的世界失败的问题。所以，不建议把keep-spawn-loaded设置为false，但是可以把keep-spawn-loaded-range设置为0(至少加载1区块，防止mv的bug)，如果需要常加载的生存服可以选择把这一项设置为2或4。 9.chunk-tasks-per-tick(1.15+可用，每个tick最多能执行多少次区块的任务，默认=1000) 官方称降低此项数值可能对区块渲染和区块生成有帮助，但在实际测试中(1.15/1.16)，无论设置为多少数值，都无法看见因这项配置带来的区块渲染/生成速度变化，也没有减少实际占用。我目前也不推荐降低此项数值以进行优化。 Part 5 Global.conf 适用服务端:Sponge注:文件在服务端目录\config\sponge\global.conf中，这是sponge最主要的配置文档测试时服务端核心是API7.2.0/SpongeForge，由于本配置文件的配置项较多，还会写出配置项所在第XX行另外global.conf中有大量内容与server.properties/bukkit.yml/spigot.yml/paper.yml重合，这一部分将不会进行测试 1.deny-chunk-requests(Test ID:98-101/第630行)(设置为true后，所有未加载区块内的请求都会被拒绝。它可以提升一定性能，但它是实验性设置。默认值=false)启用它可能会导致一些问题，如果这些问题出现了并确定是该项配置导致的，可以根据严重程度考虑关闭它测试内容: ①玩家不移动和玩家跑图时，开启/关闭此项时的服务器状况[1.12] 附加参数: ①view-distance=16结果/建议/提醒①:
启用此项后，有显著的性能提升，并且在TPS能提升接近1。但是测试时(8次启动)中有一次崩溃了，看上去是区块生成的时候导致卡线程，可能和这个配置项有关但我还是建议你启用此项，配置文件中建议也比较中肯，只是说出现问题后才建议关闭。 2.panda-redstone(Test ID:102-105/第479行)(使用panda4944的红石算法以提升性能，默认值=false)这项配置在spongeForge服中可能效果不好(MOD服谁用红石啊)，但是如果你是用SpongeVanilla(并且是生存服)，那么这一项的优化效果绝对是显著的。测试内容: ①:不同红石数量不断更新(并更新周围方块)时，开启/关闭此项配置时红石更新的占用和服务器状况[1.12] 附加参数: ①这次使用了SpongeVanilla。稳定性更好同时数据更精确结果/建议/提醒①:
开启此项后，仅关于红石周围的方块更新优化就达到了95%左右，整体的红石占用也能降低65%左右，而且开启此项后红石更新更加流畅了，并不会损失特性。对于这种副作用小的选项，强烈建议启用。如果出现了大型机器失效后，可以尝试关闭此项(sponge也修复了一些原版的bug，机器失效时也要注意这些) 3.eigen-redstone(Test Id:106-112/第432行)(是否启用theosib的红石优化算法，同样可以提升性能，默认值: enabled=false vanilla-decrement=false vanilla-search=false)enabled决定这个算法是否启用vanilla-decrement决定了是否使用原版的红石能量等级计算，默认值即为使用优化算法 vanilla-search决定是否使用原版的方块更新机制，默认值即为使用优化算法 测试内容: ①启用这项后对于红石计算的优化效果[1.12] ②子配置项内两个选项对于红石计算的优化效果[1.12] 附加参数: ①还是用SpongeVanilla结果/建议/提醒①
启用此项后，优化效果与之前的panda-redstone差不多，可能还会略差一些，红石周围的方块更新优化也能达到90%左右，整体的红石占用也能降低60%左右。但是这一项配置可以单独设置启用给的部分，比如使用优化算法会导致某机器无法使用，这样的话你可以设置为使用原版红石能量更新/使用原版方块更新，能保留另一个，同时又有一定的优化效果。 |
| |
| 以下根据结果总结了server.properties/bukkit.yml/spigot.yml/paper.yml/global.conf中的所有配置项 如果你需要自己对配置进行修改，可以查看下面的内容 如果你只需要一个能优化的文件，直接拉到最下面白嫖配置文件即可 优化效果:极好＞好＞较好＞一般＞较差＞差＞极差＞特别差
副作用:无＞极小＞小＞中等＞较大＞大＞极大
分界线上方是已经测试过的内容，同时有中等或更好的优化效果 分界线下方是未测试过的内容，这些配置项绝大多数优化效果都特别小 注:由于帖内宽度的问题，有一部分配置项没有写完全 对于实体，有18项配置项可以进行优化，其中10项优化效果较好 配置文件 配置项 优化效果 副作用 server.properties+spigot.yml ➟ view-distance 较好 中等 bukkit.yml ➟ spawn-limits 好 小 bukkit.yml ➟ ticks-per.monster-spawns 好 极小~较大 bukkit.yml ➟ ticks-per.animal-spawns 一般 极小 spigot.yml ➟ entity-activation-range 较好 中等 spigot.yml+global.conf ➟ mob-spawn-range 较好 较大 spigot.yml ➟ max-tick-time.entity 较好(paper除外) 较大 paper.yml ➟ despawn-ranges 较好 小 paper.yml ➟ optimize-explosions 较好 极小 global.conf ➟ living-hard-despawn-range 一般 中等 global.conf ➟ living-soft-despawn-range 一般 中等 spigot.yml+paper.yml+global.conf➟ max-entity-collisions 极差 无 spigot.yml ➟ squid-spawn-range 差 无 spigot.yml ➟ arrow-despawn-rate 特别差 无 spigot.yml ➟ merge-radis 差 极小 paper.yml ➟ experitence-merge-radis 极差 极小 global.conf ➟ item-merge-radis 差 极小 global.conf ➟ item-despawn-rate 较差 中等 global.conf ➟ living-soft-despawn-minimum-life 较差 较小 对于方块实体，有1项配置项可以优化，此项优化效果较好 配置文件 配置项 优化效果 副作用 spigot.yml ➟ max-tick-time.tile 好(paper除外) 中等 对于红石，有3项配置项可以优化，这3项优化效果较好 配置文件 配置项 优化效果 副作用 paper.yml ➟ use-faster-eigencraft-redstone 极好 小 global.conf ➟ eigen-redstone 极好 小 global.conf ➟ panda-redstone 极好 小 注:paper.yml内use-faster-eigencraft-redstone和global.conf内eigen-redstone为同一个算法 对于区块，有12项配置可以优化，其中8项优化效果较好 配置文件 配置项 优化效果 副作用 server.properties+spigot.yml ➟ view-distance 极好 中等 bukkit.yml ➟ chunk-gc 一般 无 paper.yml ➟ max-chunk-sends-per-tick 较好 较大 paper.yml ➟ max-chunk-gens-per-tick 较好 较大 paper.yml ➟ delay-chunk-unloads-by 一般 极小 global.conf ➟ chunk-gc-load-threshold 一般 极小 global.conf ➟ chunk-unload-delay 一般 极小 global.conf ➟ deny-chunk-requests 较好 一般 bukkit.yml ➟ ticks.per-autosave 较差 极小 paper.yml ➟ max-auto-save-chunks-per-tick 差 中等 global.conf ➟ auto-save-interval 较差 极小 global.conf ➟ max-chunk-unloads-per-tick 一般 较小 对于漏斗，有5项配置可以优化，这5项优化效果较好 配置文件 配置项 优化效果 副作用 spigot.yml ➟ ticks-per.hopper-transfer 一般 较小 spigot.yml ➟ ticks-per.hopper-check 较好 极小 spigot.yml ➟ hoppper-amount 一般 较小 paper.yml ➟ hopper.disable-move-event 较好 较大 关于其他类型的优化，有1项配置可以优化 配置文件 配置项 优化效果 副作用 paper.yml ➟ Timings.enabled 较差 极小 可供下载的已优化过的配置文件 插件服: 支持1.12-1.17 CraftBukkit/Spigot/Paper/Tuinity/Purpur/Airplane等任何基于bukkit的核心 有轻度优化/中度优化/重度优化/极限优化四个版本，可根据服务器实际情况选择配置文件 轻度优化:TPS 17.5+，且原来配置文件基本未修改过 中度优化:TPS 14+，且原来配置文件基本未修改过 重度优化:TPS 8+ 极限优化:TPS＜8 或选择回复获取配置文件 xmdhs如果您要查看本帖隐藏内容请回复 MOD服: 1.12: 支持Catserver/Mohist/Sponge(API 7.2.3) 1.14/1.15: 支持Arclight 有轻度优化/中度优化/重度优化/极限优化四个版本，可根据服务器实际情况选择配置文件 轻度优化:TPS 17.5+。且原来配置文件基本未修改过 中度优化:TPS 14+。且原来配置文件基本未修改过 重度优化:TPS 10+ 极限优化:TPS＜10 或选择回复获取配置文件 xmdhs如果您要查看本帖隐藏内容请回复 更改配置文件虽然能大幅提升性能，但它不是万能的，如果你需要对服务器进行更好的优化，请打开折叠部分 有些东西无法通过修改核心的配置文件进行优化 如服务器与玩家间的数据包传输，插件的占用，Mod的占用，内存回收等 关于数据包传输，可以考虑开bungeecord服，设置几个子服对玩家进行分流，并同步数据，同时也可以降低实体/方块实体/区块等的占用 关于Mod的占用，不仅有难优化的方块实体，还有方块更新等，这些都很难优化 关于插件的占用，可以通过更换轻量插件/减少不必要的粒子或GUI 从而大幅减少它们的占用 比如crazycrates插件，抽奖时的跑马灯式GUI，你完全可以不用它而用其他抽奖插件 再比如mythicmobs插件，当怪物的粒子效果较多时服务器会严重卡顿，你当然可以减少粒子效果从而降低mm插件的占用 关于内存回收，你可以使用这里的参数https://mcflags.emc.gs/ |
插个嘴，可以把标题改的明白一点比如MC服务端配置文件优化，一开始以为是插件开发读写配置文件的优化懵了半天(((另外腾讯文档好像不登陆看不了
本帖最后由 EmptyLava 于 2021-2-15 10:36 编辑
ok已修改
后续可能会用pastebin或者其他平台来代替腾讯文档
蕾米洛伊 发表于 2020-7-20 16:22
插个嘴，可以把标题改的明白一点比如MC服务端配置文件优化，一开始以为是插件开发读写配置文件的优化懵了半 ...
ok已修改
后续可能会用pastebin或者其他平台来代替腾讯文档
114514还行 草
114514
这是大佬要开新坑了吗
Windows Server 2016 / Intel Xeon E5 2689 2 Cores / 6GB
这个配置看起来很眼熟呢
这个配置看起来很眼熟呢
本帖最后由 极光creeper 于 2020-7-20 17:43 编辑
原来如此，挺好的
最近在练习打字，可以不管我的，只是一点小小的建议，希望能采纳/探讨一下
比如你们一上来就选择了最难的一个View-distance
我们粗略地把生产环节里的地图分为Generation和Loading以及Lighting三个部分
"Generation"，它在1.13前和1.13后的逻辑是不一样的，虽然Generation还要再作区分，但是我就这么一概而论吧
此外，在世界生成过程中，1.15后一般使用2个线程，而之前的表现更差
"Loading"，对于内存而言，1.14及以后不再只加载视野中的"view distance"区块(请允许我使用这样野鸡的说法)，
它还会加载内存中的区块，以及区块的加载策略也有了非常大的改动，它不是单纯的一股脑，数据全塞到内存里
"Lighting"，同样的，由于光照引擎的修改，Lighting也要区分1.14前和1.14后，mj其实是在优化多线程的(笑
网络因素(波动)，延迟峰值 也是有必要考虑到的
所以说起来如果要测试，你必须在至少4个情景下测试
· 1.13以前
· 1.13
· 1.14
· 1.15及以后
· 指不准哪天还要测试更多，单单测试一个，实在是太不具有普适性了
我相信这就是大家很少写这种基于测试的教程的原因，它就是超绝麻烦
这些是必须要注意的，所以我推荐超大号红字写清楚这个问题，否则还是挺麻烦的
以及在不同的核心线程数量下，地图生成，光线引擎等等 它们的情况也是不一样的
同样，GC也是一个非常大的问题，众所周知，大家可以轻松地使用16GB在1.8带300个玩家
但对于1.15，在逻辑上就拒绝了那么多玩家 (它强推了分布式架构)，对于GC Root大小的要求也是更进一步的
这样独立出来的测试并不是一个非常好的做法
对于你的较少内存(你测试中只给了1536M)，它可以大量利用cpu进行一个回收
而测试中禁用回收则完全不是在模仿生产环节，它的目标是生产环节
最初，你可以在禁用区块回收的情况下进行测试，但是这个数据最好放在最后公示，因为它可能不太适合作为最终结论
我想，这就是其他教程给人模棱两可的感觉的原因了，毕竟在生产环节上服务器还会崩溃呢(笑
原来如此，挺好的
最近在练习打字，可以不管我的，只是一点小小的建议，希望能采纳/探讨一下
比如你们一上来就选择了最难的一个View-distance
我们粗略地把生产环节里的地图分为Generation和Loading以及Lighting三个部分
"Generation"，它在1.13前和1.13后的逻辑是不一样的，虽然Generation还要再作区分，但是我就这么一概而论吧
此外，在世界生成过程中，1.15后一般使用2个线程，而之前的表现更差
"Loading"，对于内存而言，1.14及以后不再只加载视野中的"view distance"区块(请允许我使用这样野鸡的说法)，
它还会加载内存中的区块，以及区块的加载策略也有了非常大的改动，它不是单纯的一股脑，数据全塞到内存里
"Lighting"，同样的，由于光照引擎的修改，Lighting也要区分1.14前和1.14后，mj其实是在优化多线程的(笑
网络因素(波动)，延迟峰值 也是有必要考虑到的
所以说起来如果要测试，你必须在至少4个情景下测试
· 1.13以前
· 1.13
· 1.14
· 1.15及以后
· 指不准哪天还要测试更多，单单测试一个，实在是太不具有普适性了
我相信这就是大家很少写这种基于测试的教程的原因，它就是超绝麻烦
这些是必须要注意的，所以我推荐超大号红字写清楚这个问题，否则还是挺麻烦的
以及在不同的核心线程数量下，地图生成，光线引擎等等 它们的情况也是不一样的
同样，GC也是一个非常大的问题，众所周知，大家可以轻松地使用16GB在1.8带300个玩家
但对于1.15，在逻辑上就拒绝了那么多玩家 (它强推了分布式架构)，对于GC Root大小的要求也是更进一步的
这样独立出来的测试并不是一个非常好的做法
对于你的较少内存(你测试中只给了1536M)，它可以大量利用cpu进行一个回收
而测试中禁用回收则完全不是在模仿生产环节，它的目标是生产环节
最初，你可以在禁用区块回收的情况下进行测试，但是这个数据最好放在最后公示，因为它可能不太适合作为最终结论
我想，这就是其他教程给人模棱两可的感觉的原因了，毕竟在生产环节上服务器还会崩溃呢(笑
本帖最后由 EmptyLava 于 2020-7-20 18:06 编辑
你的想法很有建设性，在接下来我也会参考的(
在实际设置参数的时候也考虑到了很多
我也想到了1.12 1.13 1.13+的区块机制变化，但是由于个人屑电脑的缘故可能不会测试到1.14，1.13的区块改了很多，对于1.13或更高版本也有一定的说服力
网络问题也想到了，如果网速过低会导致区块还没被加载/生成就要被卸载了
内存的话后面分了5G，对于1个人，chunks不超过2k的情况下富足了
其实我是想尽量还原生产环境的，在设置参数的时候我可能更多考虑到了多玩家的时候(10个分开的玩家不就相当于一个玩家跑图10*[view-distance*16]的距离，而且没有进行区块回收吗( )
极光creeper 发表于 2020-7-20 17:41
原来如此，挺好的
最近在练习打字，可以不管我的，只是一点小小的建议，希望能采纳/探讨一下
在实际设置参数的时候也考虑到了很多
我也想到了1.12 1.13 1.13+的区块机制变化，但是由于个人屑电脑的缘故可能不会测试到1.14，1.13的区块改了很多，对于1.13或更高版本也有一定的说服力
网络问题也想到了，如果网速过低会导致区块还没被加载/生成就要被卸载了
内存的话后面分了5G，对于1个人，chunks不超过2k的情况下富足了
而测试中禁用回收则完全不是在模仿生产环节，它的目标是生产环节
其实我是想尽量还原生产环境的，在设置参数的时候我可能更多考虑到了多玩家的时候(10个分开的玩家不就相当于一个玩家跑图10*[view-distance*16]的距离，而且没有进行区块回收吗( )
本帖最后由 EmptyLava 于 2020-7-20 18:24 编辑
还想和您探讨一下 计算配置文件提升效果的时候 基准应该选哪个
只有一个spark的采样数据
我就只想到两种
1.(Thread.sleep优化前占比%-Thread.sleep优化后占比%)/(1-Thread.sleep优化前占比)=优化效果
2.(Thread.sleep优化前占比%-Thread.sleep优化后占比%/(1-Thread.sleep[0tile,0entity,出生点加载区块数]的占比%=优化效果
但是好像都不是很好，看一下您能不能出点招
不能接受加权等算法，这样的优化效果就没什么意义了
极光creeper 发表于 2020-7-20 17:41
原来如此，挺好的
最近在练习打字，可以不管我的，只是一点小小的建议，希望能采纳/探讨一下
还想和您探讨一下 计算配置文件提升效果的时候 基准应该选哪个
只有一个spark的采样数据
我就只想到两种
1.(Thread.sleep优化前占比%-Thread.sleep优化后占比%)/(1-Thread.sleep优化前占比)=优化效果
2.(Thread.sleep优化前占比%-Thread.sleep优化后占比%/(1-Thread.sleep[0tile,0entity,出生点加载区块数]的占比%=优化效果
但是好像都不是很好，看一下您能不能出点招
不能接受加权等算法，这样的优化效果就没什么意义了
EmptyLava 发表于 2020-7-20 18:22
还想和您探讨一下 计算配置文件提升效果的时候 基准应该选哪个
只有一个spark的采样数据
后排小声吐槽
为什么要看sleep来作为优化效果对比(?)也许可以更加全面一点(?)
也许可以具体到某个方法调用次数/[平均/峰值]耗时
还可以看看多核利用率是多少？
像这样看看每个线程IO cpu情况
如果可以 使用jdk或者其他工具记录内存/CPU/GC/IO情况
毕竟核心数量不同 ↑可能会有所不同X
本帖最后由 EmptyLava 于 2020-7-20 18:41 编辑
就论view-distance吧
还会影响entity tile等，算方法调用时间的话好像挺麻烦的
方法调用耗时这个想法挺好的呀，spark上也有
cpu利用率的话纯粹一乐..误差太大
阴阳师元素祭祀 发表于 2020-7-20 18:34
后排小声吐槽
为什么要看sleep来作为优化效果对比(?)也许可以更加全面一点(?)
而且sleep我觉得不稳定 ...
就论view-distance吧
还会影响entity tile等，算方法调用时间的话好像挺麻烦的
方法调用耗时这个想法挺好的呀，spark上也有
cpu利用率的话纯粹一乐..误差太大
- 以上都没有[s]，只是被之前的代码套了
本帖最后由 阴阳师元素祭祀 于 2020-7-20 18:44 编辑
方法耗时不需要具体到每个细节 大块大概就好了（？）
可以看出来 view-distance影响的大块是哪个地方
然后..
cpu利用率可以看每个线程
主要是看多线程优化怎么样（bushi
↓我记得我看timings的时候 还有chunk相关的
EmptyLava 发表于 2020-7-20 18:40
就论view-distance吧
还会影响entity tile等，算方法调用时间的话好像挺麻烦的
方法耗时不需要具体到每个细节 大块大概就好了（？）
可以看出来 view-distance影响的大块是哪个地方
然后..
cpu利用率可以看每个线程
主要是看多线程优化怎么样（bushi
↓我记得我看timings的时候 还有chunk相关的
等个能拯救大型次元的配置
指暮色跑图、交错次元跑图，实测即使预载了，跑得快还是...
指暮色跑图、交错次元跑图，实测即使预载了，跑得快还是...
本帖最后由 EmptyLava 于 2021-8-15 22:05 编辑
更新日志: 2020.7.20~2020.8.23:发布帖子，共进行163次测试(146次有效，17次无效)。 ↑主体更新 ↓非主体更新 2020.8.12~2020.8.24 ①总结中的配置文件添加了对Arclight(1.14/1.15)的支持 ②现在的Catserver/Mohist/Paper/Bukkit/Arclight配置文件中都基于自身和自身版本的文件了，而不是再使用Paper 1.12.2提供的(Catserver，Mohist都针对MOD服删减了配置文件内的一些配置项，直接使用Paper的文件不会造成什么后果，但是会让服主以为这个配置项可用。实际上它不会生效。)，修改了一些差异性内容 2020.8.16优化排版 2020.8.18:添加了总结部分对于玩家事件/数据包传输这两个占用较大的项目的提醒。 2020.11.26:优化排版，删除部分冗杂内容，更改了一部分配置项修改建议2021.2.18: 更新paper.yml chunk-tasks-per-tick的描述 2021.2.24: 更正/更改大量描述，优化排版 2021.3.13: 更正大量描述 |
挺好 支持一下
666+牛逼了，这个帖子，一个没看懂
max-tick-time-entity均改为25后tps还是不到12
能否继续下调
现在出现问题就是玩家看实体可能瞬移
能否继续下调
现在出现问题就是玩家看实体可能瞬移
本帖最后由 EmptyLava 于 2020-8-9 22:38 编辑
先不要下降了
贴内说过了要用timings看一下tickentity有多少，再来修改数值
你可以把timings报告发给我，我看看是哪部分的问题
bukkit.yml和spigot.yml对于catserver和mohist的优化实在捉急
entity-activation-range可用，不受影响
max-tick-time可用，但是对游戏体验影响比较大
spawn-limits半残，mod的刷怪机制很多都不是自然生成
monster-spawns可用
chunk-gc半残，想卸载区块，mod不让
Stant_hed 发表于 2020-8-9 21:36
max-tick-time-entity均改为25后tps还是不到12
能否继续下调
现在出现问题就是玩家看实体可能瞬移
先不要下降了
贴内说过了要用timings看一下tickentity有多少，再来修改数值
你可以把timings报告发给我，我看看是哪部分的问题
bukkit.yml和spigot.yml对于catserver和mohist的优化实在捉急
entity-activation-range可用，不受影响
max-tick-time可用，但是对游戏体验影响比较大
spawn-limits半残，mod的刷怪机制很多都不是自然生成
monster-spawns可用
chunk-gc半残，想卸载区块，mod不让
EmptyLava 发表于 2020-8-9 22:11
先不要下降了
贴内说过了要用timings看一下tickentity有多少，再来修改数值
https://www.spigotmc.org/go/timings?url=icohicozaq
现在和之前tps差不多了= =
之前两个设置的1000
Stant_hed 发表于 2020-8-10 09:37
https://www.spigotmc.org/go/timings?url=icohicozaq
现在和之前tps差不多了= =
之前两个设置的1000 ...
服务器内加速火把加速其他方块实体导致的tps降低
max-tick-time的entity可以不用动，占用不高。主要是tile高，大概每tick占了45ms，降tile即可
还有50%的tick不知道跑哪去了，可能是forge本身的事，这一部分要深入的话得用spark采样
挺好 支持一下
感谢楼主分享
感谢腐竹大人
神乎奇迹，不服不行！
這邊連評論都各個大老啊.....
我也需要他这个 我服务器需要优化
获取获取
十分感谢！！！！
感谢这个篇文章，让我受益匪浅
感谢楼主如此好的分享以及不断辛勤测试！
https://timings.aikar.co/?id=d37ab0785db94b85997d284ec9c27e65
你好作者
我看不懂timinigs
用了你的配置优化 还是有掉tps
请问是什么原因给我解决方案谢谢
你好作者
我看不懂timinigs
用了你的配置优化 还是有掉tps
请问是什么原因给我解决方案谢谢
本帖最后由 EmptyLava 于 2020-8-17 22:29 编辑
哪里说了用了就能把tps提升到20的(
插件的锅我不背，反作弊和simplecore的占用高
实体，区块占用什么的都还不错(至少这一部分是配置文件的效果)。还有就是数据包传输有点高(通常也是插件的锅，当然也可能是玩家多)，这个是几乎无法优化的
另外，看timings的时候只有后面一段才掉了tps，也许正好是那时候你的玩家做了些什么事
哪里说了用了就能把tps提升到20的(
Minecraft::Pluginscount(699624) total(34.98% 28.977s, 113.19% of tick)avg(0.04ms per - 56.60ms/1,366.45 per tick)
SimpleScore::Combined Totalcount(511) total(15.43% 12.779s, 49.92% of tick)avg(25.01ms per - 24.96ms/1.00 per tick)
Matrix::Combined Totalcount(25801) total(8.59% 7.114s, 27.79% of tick)avg(0.28ms per - 13.89ms/50.39 per tick)
TrMenu::Combined Totalcount(8491) total(5.21% 4.315s, 16.86% of tick)avg(0.51ms per - 8.43ms/16.58 per tick)
mcMMO::Combined Totalcount(14647) total(1.41% 1.166s, 4.55% of tick)avg(0.08ms per - 2.28ms/28.61 per tick)
Residence
插件的锅我不背，反作弊和simplecore的占用高
实体，区块占用什么的都还不错(至少这一部分是配置文件的效果)。还有就是数据包传输有点高(通常也是插件的锅，当然也可能是玩家多)，这个是几乎无法优化的
另外，看timings的时候只有后面一段才掉了tps，也许正好是那时候你的玩家做了些什么事
本帖最后由 Zengdadawang 于 2020-8-19 19:36 编辑
然而并没有看懂，最后直接下载配置文件
然而并没有看懂，最后直接下载配置文件
牛的厉害啊
感谢楼主分享！
这种文档的帮助实在是太大了
AkkLive 发表于 2020-8-25 21:35
用了你的配置优化
我来反馈了
net.minecraft.server.v1_16_R1.ChunkProviderServer.tick()29.38%10668ms
net.minecraft.server.v1_16_R1.WorldServer.entityJoinedWorld()40.97%
1.16带35人?不考虑bc吗
实体和区块占用挺高的，考虑一下限制动物繁殖数量?villager占用的话看一下villager optimizer插件更新了1.16没
怪物一类的占用还好
本帖最后由 AkkLive 于 2020-8-25 22:07 编辑
VillagerOptimiser 已经最新了 WorldBorder 生成区块fill的 就怎么样?
开bc 做什么用给我说以下 我就去做
EmptyLava 发表于 2020-8-25 21:43
1.16带35人?不考虑bc吗
实体和区块占用挺高的，考虑一下限制动物繁殖数量?villager占用的话看一下villa ...
VillagerOptimiser 已经最新了 WorldBorder 生成区块fill的 就怎么样?
开bc 做什么用给我说以下 我就去做
AkkLive 发表于 2020-8-25 22:03
VillagerOptimiser 已经最新了 WorldBorder 生成区块fill的 就怎么样?
开bc 做什么用给我说以下 我就去 ...
把玩家分流开来，原来一个服要承受的压力现在多个服务器来承受，从而大幅减少服务器mspt
1.16的优化仍然不行，单服承载35人已经很不错了
但是bc的话要弄两个子服的数据库同步 会有一定难度
wangxiaotong 发表于 2020-8-26 04:48
https://spark.lucko.me/#1kEOE31OtO、 在不哥帮我看一下我被卡的心态崩了
编辑了，，，，，，，，，，，，，，，，，，
感谢大佬的优化成果
太棒了 正是我需要的
下载来研究研究
感谢分享，支持一下!
MCBBS有你更精彩~
很不d教程支持
金粒和回复间做选择当然是这样啦