【喵】草履虫也能直接上手的服务器优化教学
本帖最后由 喵哒子sama 于 2024-3-26 17:59 编辑static/image/hrline/2.gif
.❀喵叫❀.
应兔子的要求来发点什么~
什么时候有专门的JAVA联机教程板块啊啊啊(尖叫)(扭曲)(阴暗的爬行) (爬行)(扭动)(阴暗地蠕动)(翻滚)(激烈地爬动)(扭曲)(痉挛)(嘶吼)(蠕动)(阴森的低吼)(爬行)(分裂)(走上岸)(扭动)(痉挛)(蠕动)(扭曲的行走)(不分对象攻击)
这是一个面向萌新的MOD服的优化教程，你不需要理解复杂的专业名词，只需要跟着做即可。
此教程主要从配置文件及游戏内具体应用上来解决卡顿问题，对核心原生配置文件介绍较少，有需要可以移步其他教程！
前言说完了咱们就开始吧！
static/image/hrline/2.gif
.①.关于服务器为什么会卡这件事&何为TPS（可跳过）
我们都知道服务器中一秒分为20Tick，所以每Tick就相当于现实世界的50ms（重要，因为大多数检测插件都是以ms来计算运算速度）
如此来看，服务器每次运算只给这个服务端提供了50毫秒的运算时间，所以对于优化来说咱们要做的就是将整个服务端的所有运算内容压缩在50ms以内即可做完;这样即可保证服务器的流畅。
反映到TPS就是TPS持续保持在19.9以上！
当然，实际操作和理论有一定差距，TPS在18~19.9这个区间时在MOD服中对实际游戏体验的影响也并不会很大，但是总体上来说按照这个思路来说即可~
.②.具体哪些东西会造成严重卡顿呢（正文）
咱们针对一些常用的MOD列出以下几项，根据这个思路做参考即可，如果你比较懒那直接找到对应项目抄作业吧!
static/image/hrline/line9.png
. 植物魔法的产能花和火花（卡服程度：★★★）
火花和产能花单个的计算量其实并没有非常高，但是由于通常他们的数量十分庞大，并且属于常用mod，所以列在榜首。 在一个正常的服务器之中通常输入/gc可以看到服务器的 tiles 会达到2w以上，甚至有些能超过3w，如果没有分世界那么开久了以后5W以上都非常常见 tiles在MOD服里面的相当之广，世界上除了方块之外的可互动物品都是tiles。例如：MOD的所有机器，植魔的花，奇奇怪怪有奇怪功能的方块等。 通常情况下，不加载的Tiles的并不会消耗服务器性能，加载的Tiles也不会过多消耗性能。但是! 植魔的花在加载的情况下会不断的进行计算：产能-传输-魔力池-方块更新等 由于花的产魔方式不同，还可能设计到更加复杂的实体运动的运算（常用如叮当舞花），红石+掉落物（常用如火红莲）且玩家通常开了就不知道关，相当于进行了无上限运算！——————————————————（注：无上限运算为喵的自创词语，代指服务器中不关闭可以持续进行运算拖累服务器性能的东西。如果说普通的卡服内容扣除的是服务器的血条，那么无上限运算扣除的就是服务器的血量上限。在老式的地皮服中尤为明显，即使玩家退服几个月了，只要周围有一个人在玩，这些东西立刻会吃掉服务器的大量性能。）解决办法：限制产能花数量
static/image/hrline/line9.png
. AE的自动合成 |卡服程度：★★★★★AE储存是很方便的功能，但是AE提供了让玩家非常快乐的功能，也是AE的核心功能——自动合成 自动合成进行的时候，会不断加载刷新AE内物品，满足条件就在AE内部减去和增加相应物品，这样达成一次合成 当合成频率过高的时候-AE的更新就会相当之快，AE内部刷新也变随之变快 当合成物品过多时，AE同时进行的运算就会增加，且持续时间也会增加 这两个是后期玩家的追求，也是服务器卡服的主要元凶之一解决办法： 在config的AppliedEnergistics2中，将 I:craftingCalculationTimePerTick设置为100即可(还可以修复利用AEtick刷物品bug值得一提的是，绝大多数玩家由于材料的限制，使用AE造成的性能开销仅仅只能算是短期卡顿只要不是合成光子太阳能这种需要物品按几十上百万算的超套娃机器，性能开销甚至可以忽略不计————————————————————如果你已经通过timings或spark等手段确认AE造成的卡顿服务器已经无法承受，也提供了紧急处理办法在AE的配置文件中找到tickrates段，这里设定了AE的各个机器之间的传输速度将有MAX的项目设置到300（可自定义），min的项目设置到60（可自定义）这样你应该可以看到AE的性能开销大幅降低了，但是代价就是AE的运算速度也被大幅降低了，在你升级机器之前可以使用这个方法，毕竟也没得选择(注：既然选择了AE作为服务器的玩法，那么AE造成的正常性能开销就是可接受的，即使它占用了大量性能。所以在这里并不会作为异常的卡服项目https://klpbbs.com/static/image/hrline/line9.png
. 加速火把（卡服程度：★~★★★★★）
加速火把会比例放大其他MOD的卡服程度——最低的加速火把都能4倍加速 以下列举几个卡服的操作 1.多个加速火把叠加无上限运算的机器（例如：中子素收集器） 2.加速火把加速作物生长，然后通过观察者采集等 实例：6个中子素态收集器+6个加速火把叠加加速，服务器tps从18.5降低到14.6 加速火把其本身并没有特别卡服，但是配合某些高运算的机器，就会达到卡服的效果 解决方法：限制加速火把的放置数量,或者干脆不要加这个mod
https://klpbbs.com/static/image/hrline/line9.png
. 工业的核电以及回流导线 (卡服程度：★★★★)
多个核电叠加产生的发电量十分惊人 同时，它体内的铀棒耐久消耗也十分惊人。当区块加载时，服务器会同时计算所有铀棒和散热的耐久（一个核电是54个格子），10个核电连通就是540个物品的耐久同时计算，还要同时计算导线传输电量，传输机器等最重要的是:核电属于基本不会停机的机器，为了达到这个目标，通常会与自动传输，自动合成等一起出现，属于复合卡服项目,且能把相关的项目都转变为无上限运算———————————————————————— 2021年1.25日实测10个玩家的回流导线拆除服务器tps从8上升到了15,一个玩家的回流导线就讲tps从19.99降低到了18.87，非常建议加入相关限制插件！解决办法：引导玩家使用更高效的发电内容，或者限制数量https://klpbbs.com/static/image/hrline/line9.png
. 地皮插件 (卡服程度：★~★★★) 地皮插件的性能主要都用在——当一个玩家在线或者挂机的时候，它周围的地皮都会被加载，这样耗费性能的MOD越多，服务器就会越卡。 无论地皮主人有没有退服，都会不断加载这片地方，导致性能浪费十分的巨大。解决方法也很简单:地皮大于玩家的加载距离或使用家园插件https://klpbbs.com/static/image/hrline/line9.png
. 地图加载(跑图) (卡服程度：★★★)地图加载会同时消耗cpu和宽带，cpu是你后台内生存地图的消耗，宽带是玩家从后台下载地图的消耗 在我看来服务器的资源珍贵比是 CPU>宽带>内存>硬盘 CPU：服务器的所有活动都需要消耗 宽带：基本上只在跑图的时候才会大量消耗 内存：除去开服的必要内存意外，消耗的很少 硬盘：通常只有备份地图才会大量消耗 地图加载会同时消耗CPU和宽带！ 为了节省宝贵的CPU资源，所以推荐大家提早就使用/wb fill把地图加载好，玩家跑图的时候就只消耗宽带了 这样在玩家跑图的时候如果宽带够用，就会降低cpu的消耗，也就不会那么频繁卡顿了，适合新建资源世界的时候和暮色森林的加载建议有独立机的腐竹创建专门的资源服https://klpbbs.com/static/image/hrline/line9.png
. 漏斗 (卡服程度：★★★★★)一个简单的原版方块占用竟然能达到甚至超过工业AE的机器？！速速更改设置吧！ 1.在spigot当中，设置 hopper-transfer: 40 hopper-check: 40 hopper-amount: 3 默认是8tick处理一次上调为40tick 下面传输的数量可以根据自己喜好来增加注：如果没有加懒人AE，调整漏斗传输数量将会影响AE的自动化压印系统，不建议更改传输数量
static/image/hrline/line9.png
. 区块加载 (卡服程度：★★★★★)区块加载这个东西争议一直很大很大，加载范围大了，服务器很容易就造成卡顿，加载范围小了，很容易引起玩家不满通常的优化推荐将view-distance 范设置为4~6 也就是加载玩家为中心144*144格~208*208格的所有方块 喵：？？？———————————— 这里给一个大家一个数值 view-distance=1 加载玩家为中心48*48的方块 view-distance=2 加载玩家为中心80*80的方块 view-distance=3 加载玩家为中心112*112的方块 可以根据自己服务器的情况来决定有分服的腐竹建议缩小资源的加载范围，扩大玩家生存区域的加载范围同时禁止玩家在生存区域跑图注：服务器读取优先加载spigot里面的视距设置而不是server.properties,所以其实只更改spigot里面的即可
static/image/hrline/line9.png
. 暮色森林 (卡服程度：★★★★★)众所周知暮色森林会生成大量的野外建筑和树，并且玩家跑图会极大的消耗服务器资源，那么如何解决此类问题呢？首先在config中打开暮色森林配置文件（twilightforest.cfg）,在其中找到
[*]performance {
[*] # Amount of canopy coverage. Lower numbers improve chunk generation speed at the cost of a thinner forest.
[*] # Min: 0.0
[*] # Max: 1.7976931348623157E308
[*] D:canopyCoverage=0.1
[*]
[*] # Setting this true will make Twilight Glaciers generate with Packed Ice instead of regular translucent Ice, decreasing amount of light checking calculations.
[*] B:glacierPackedIce=false
[*]
[*] # This controls the opacity of leaves, changing the amount of light blocked. Can be used to decrease complexity in some lighting checks.
[*] # Min: 0
[*] # Max: 255
[*] I:leavesLightOpacity=1
[*]
[*] # Chance that a chunk in the Twilight Forest will contain a twilight oak tree. Higher numbers reduce the number of trees, increasing performance.
[*] # Min: 1
[*] # Max: 2147483647
[*] I:twilightOakChance=600
每个选项是什么意思可以去谷歌翻译一下:) ， 根据服务器情况适当调整生成的数值即可有效的降低性能消耗
B：skylightForest = false 这一项如果设置为TRUE，暮色森林将仅会生成必要的建筑，有想法的可以去试试
static/image/hrline/line9.png
帖子还会不断更新（大概），如果有什么建议和意见，或者服务器有卡顿也可以找咱，喵会给予优化的建议或者帮助你优化
页: [1]