[转载]【性能利用100%】服务器的性能的最大化调优

GreyD · 发表于 2023-8-12 09:10:29

本帖最后由 GreyD 于 2023-8-12 09:12 编辑

本帖原作者:白给一帆(已授权转载)

原帖地址:https://www.mcbbs.net/thread-1209753-1-1.html

前言（必看）

本文长期更新,有问题可以在原贴下方评论

截止目前，本文已有42215字。

这是一篇偏技术向但对新手友好的文章，对于服务器、服务端等的优化方法论述详尽，且知识覆盖面较广，知识量密集且篇幅较长，然而我的写作风格偏于学术，语言文字的使用相当严谨，我会尽可能讲解的生动有趣，不过还是可能会让你感到枯燥无味，但如果你能认真地将本文全篇看完，我想会对你有很大帮助。

本文中提到的所有优化手段，优化原理等内容，都是具有理论支撑，经过了我的实践证明其确实可能有效，才会写进文章内的。部分争议性内容我不会轻易的加入本文中来。虽然我一遍又一遍的审视文章，但难免存在漏网之鱼，包括但不限于：理论错误，失误性错误（比如我写的时候不小心把A写成了B），错别字等问题。如果你发现了这些错误，或者你有好的建议，希望你能积极的与我沟通交流（在下方评论或者私信我），但在讨论过程中你应该保持理性友善的态度。

本文以腾讯云1核2G6M,系统盘为SSD 60G的轻量应用服务器作为示范机型。之所以选择这款机型，是因为它已经是我能找到的适合于做教学和测试用的最低配服务器了，并且它的性价比十分高，对于新人入门，少人数联机等情景需求具有普适性，以及其它的一些优点（详情见下方选购服务器内容）。在此要着重强调一点，腾讯云不需要我来这里做宣传，我也无法从中获得任何利益，包括下方对各种应用、插件、软件等的推荐都是如此。（写于2021年6月份）

如果本文中提到的内容，如服务端配置的优化，优化的启动参数在MCBBS内或Minecraft的其它社区内已经有其他优秀的文章做出了详细解答，那么我会倾向于直接给出链接，而非复制粘贴,因为我认为我没必要对这些前人已经阐述清楚的问题再复述一遍。大多数时候我只会根据我的经验对给出链接中没有提到的内容进行补充。（补充的都是干货）

我的试验服开的是模组服，服务器使用的是下方的腾讯云学生机。服务器内加载了魔法金属，神秘时代4及其各个附属，拔刀剑及其各个附属，匠魂等Mod，二十余个常用插件，经过我的实际测试，承载15个（或者更多）活动的玩家TPS能稳定在19.9以上（事实上大多数时候都是20.0），没错，相当流畅，如果你也想要达到这种优化效果，请继续往下看。

选购服务器
（本文最初发布于2021年6月初，所以示例服务器也是此时购买的。）

购买服务器建议购买国内大厂的产品，质量有保障，服务也周到。
没错，就算是学生机的选购，也有性价比的高低之分,如果作为基友联机服的话，学生服务器可以达到完美的性价比，当然，如果玩模组，它无法运行太多模组，或是大型工业模组。（内存是硬伤）
我个人推荐购买腾讯云的学生优惠1H2G6Mbps轻量应用服务器（阿里云亦有对应机型），腾讯云在业界也被称为“良心云”，为什么？原因（示范机型的配置概述）有以下几点：

不需要学生证，只需要身份认证满足25岁以下即可购买
100%的CPU性能（所谓一核有难，八方围观，这一核再也不用被围观了，当然如果可以，建议买多核，原因下面会讲）
27元即可购买3个月（一个账户可购买3次），再加6元还可以再购买一年.asia域名
6M的下行带宽是三款可选服务器中最高的，流量是每月1000G，只做常规操作的话，根本用不完，我的服务器开了20多天，也只用了5.21G（实际上当用户购买的下行带宽小于10Mbps时，腾讯/阿里云会分配10Mbps上行带宽，具体说明在下方）。如果你想选择另一款2H4G的服务器，我要提醒你，1M的下行带宽太小了（绰号小漏水管），你可能要面临往服务器上传一个paper核心都要花十多分钟的窘境，也可能引发由于网络原因导致的卡顿现象的发生。
系统盘是SSD，相比于另外两款服务器的硬盘来说性能更好，而且60G只用于开服的话也完全足够了
腾讯云经常做一些很优惠的活动，后期续费或者升级服务器配置也能得到较高性价比（其实如何还要求更高性价比的话，还有一些小众服务器供应商可以选择，但是毕竟阿里腾讯两大巨头稳定而且提供的服务也很周到）

综上所述，腾讯云的学生轻量应用服务器可以说是我个人心目中性价比最高的学生服务器，所以我最终选购了此服务器作为本教程的教学用机器。当然，国内另一大厂商阿里云的学生服务器也不错。这段话是2年前写的了，后来腾讯云和阿里云的服务器都用过之后，其实两家的产品体验都是差不多的，学生机的性价比都是很高的。

如果你的服务器人比较多，或者你想开大型模组服，亦或者你说你就是有钱，钱什么的都是浮云。如果你符合以上几种情况，你可以去选购硬件配置更好的服务器。来，我给个导购指南。

众所周知，大多数Minecraft服务端只吃单核（这个表述是不准确的，原因见下方），虽然近年来涌现出许多号称针对多核进行优化的服务端，这些服务端或多或少取得了一些效果。但优化毕竟只是优化，仍然改变不了Minecraft服务端侧重于单核性能的本质。所以，你购买服务器的时候应当注意尽量购买CPU主频和睿频相对较高的（即单核性能较高）服务器，虽然说Minecraft服务端只吃单核，但事实上这句话并不严谨，在很多情况下，许多提供了优化配置的Minecraft服务端或者插件包括原版本身的区块、照明等因素都会使用到多线程，如果你服务器使用的CPU核心数过少（少于4核），可能会导致单核超载，进而影响服务器性能。所以严谨的说：大多数情况下，大多数Minecraft服务端侧重于单核性能。（关于这个问题的具体解释如果展开讲又是长篇大论，我也许会找个时间更新这一块的内容）。针对这个问题，我建议且推荐CPU核心数量至少为4核。
针对英特尔12/13代处理器大小核设计以及Windows系统目前调度表现不佳的问题，我建议安装Process Lasso进行手动调度，保证服务端程序运行在大核上，如果你使用的是Windows 11系统，那么务必保证服务端程序运行在前台！
事实上在内存方面的弹性就比较大了，这句话是什么意思呢？事实上，我们在内存优化方面的可操作性是比较大的，如果服务器的内存不足，我们是有很多手段对它进行优化的。并且内存占用要看你开的是模组服还是插件服，规模大还是规模小，玩家多还是少等多种情况综合判定。很多时候内存占用的跨度是比较大的。原则上满足使用需求即可（前提是内存频率要高，都已经2021年了，可别用DDR3的内存了，有些黑心的服务器提供商还在用DDR3内存），事实上分配的内存过多会导致内存回收时花费太多时间整理内存，从而导致服务器卡顿的发生。一般来说对于1.16.5的普通插件服，如果平均在线人数为10人左右，大多数情况下为服务端分配4G内存已经足够，但需注意应为操作系统预留1-1.5G的内存空间。
硬盘方面，能用SSD就用SSD（即固态硬盘），没啥好说的，速度要比机械硬盘快几十上百倍。同时，如果你追求更高的硬盘性能，你应该使用基于NVMe协议的固态硬盘而不是去使用基于传统SATA接口的固态硬盘，一般来说NVMe要比普通的SATA快了几倍。
宽带方面，视人数而定，一般来说上行宽带如果你是选购腾讯阿里的云服务器，可以选择按量计费，按量计费模式可以说是完美符合我们开服的要求，性价比极高。但要注意，上行宽带跟下行宽带是不一样的，开服主要看上行宽带，如何估计你服务器需要的上行带宽呢？我们一般可以用一个人占用1Mbps的方法粗略估计，而且这种估计方法一般情况下是存有一定预留空间的，10Mbps带10个人还留有一定的余地，在优化良好的情况下带20人也是勉强可以，这个我是做过实际测试的。所以对于中小型服务器来说，不必要花很多钱去升级服务器的上行宽带，如果你认为你的宽带有些不够用了，具体体现为偶尔会出现因网络延迟而造成的卡顿了，或者玩家会经常出现掉线或者进服务器困难的现象，你可以在server.properties中将network-compression-threshold（此参数在下文有详细阐述）适当调低，牺牲部分CPU性能来换取网络性能。（ps.宽带可比CPU金贵多了，当然，如果你的CPU是神U，当我没说）
ps.在腾讯云/阿里云购买的服务器带宽，上行下行是相等的。（摘自腾讯云关于上行带宽的说明文档）
用户购买的下行带宽大于10Mbps时，腾讯云/阿里云会分配与购买的带宽相等的上行带宽。
用户购买的下行带宽小于10Mbps时，腾讯云/阿里云会分配10Mbps上行带宽。
服务器系统选择归类为准备开服阶段，见下方。

准备开服阶段

1. 系统的选择

（操作系统的选择在大多数情况下对服务器的影响并不算太大，没必要在不熟悉的情况下非要用Linux。）
虽然Windows系统对大多数人来说更加熟悉且方便操作，但服务器系统还是推荐使用Linux系统，原因如下：

Linux更加稳定
Linux更加安全
Linux资源消耗低，系统性能更好
Linux的计划任务是真的好用，配合脚本可以实现很大程度上的自动化运维（所以事实上你并不需要使用阿里腾讯提供的自动化运维工具，事实上他们的工具只是把Linux自带的计划任务功能搬到了网页上并提供了GUI而已）
大多数Linux系统开源，如果日后你成长为一位大牛，你可以根据自己的需要定制系统
Linux作为服务器操作系统的优点还有许多，在此不可能一一列举，如果你希望深入了解Linux作为服务器操作系统的优点，你可以自行百度

操作系统推荐选择

CentOS 7.6 64bit或者Debian

。为什么不选择更新的CentOS 8.0以上的版本?因为虽然CentOS8.X相比于CnetOS7.X做出了很多改进，但经过实际测试CentOS 8.0以上的版本内存消耗会更大一点，让本就不多的内存更加雪上加霜。并且Centos 8已经被提前结束维护了，是一个不折不扣的夭折版本，甚至可以说CentOS系列现在已经有些过时。
如果你还是不习惯全文字的操作系统，也可以选择桌面Linux系统，比如Ubuntu。特别的，如果你使用的是国内两大云服务器厂商的产品，操作系统选择两家专门为自家云产品定制的系统即可，原因如下：

国内两大云服务器厂商阿里云和腾讯云均针对云的场景研发了专用的 Linux 操作系统，引自腾讯产品文档说明：为自家产品提供了特定的功能及性能优化，为云服务器实例中的应用程序提供高性能及更加安全可靠的运行环境。
TencentOS Server/Alibaba Could Linux 3的开发团队正在对这款操作系统进行积极的更新维护，没错，懒人必备的Yum库也正被积极的维护，你可以从TencentOS Server/Alibaba Could Linux 3的Yum库中一键下载安装到很多最新的软件包。
有什么系统上的问题直接提交工单问工程师就行，加急工单一般会在一小时内被处理。
TencentOS Server/Alibaba Could Linux 3已经在我的服务器上运行了几个多月了，我只想说——真香！空载状态下的系统内存占用相比于CentOS 7.6 64bit要低约5%。而操作方面与CentOS相差无几，有使用过CentOS经验的人可以轻松上手。
关于TencentOS Server/Alibaba Could Linux 3的具体说明文档在这：TencentOS Server常见问题、Alibaba Cloud Linux 3的概述

2.一些对服务器的优化

事实上像腾讯云、阿里云这样的大厂商，本身在服务器的性能优化上就已经做的很好了，但是他们的服务器镜像往往会捆绑安装许多不必要的组件，这些组件会占用你许多内存。你可以在购买云服务器时取消勾选这些组件，它们就不会被安装，如果你忘记勾选了，它们已经被安装在你的服务器里了，可以手动卸载，教程
如下：
卸载云服务器监控组件（阿里同理，是因为我手头上只有腾讯云的服务器，所以用腾讯云服务器演示）
这个组件就是使你可以在腾讯云的控制台查看到服务器资源占用情况的组件，2个组件加起来大概占用50M的内存，平常根本不会去腾讯云的控制台查看资源消耗，所以推荐卸载以节约内存。（总之就是能省就省）

步骤一：卸载 BaradAgent（腾讯云监控）

注意：卸载此项将导致你无法在官方网页控制台上查看到服务器使用资源的情况。

1.登录云服务器后，执行以下命令，进入 BaradAgent 安装目录。

cd /usr/local/qcloud/monitor/barad/admin

2.执行以下命令，卸载 BaradAgent。该命令不显示结果，如果不存在/usr/local/qcloud/monitor/barad文件夹，则说明卸载成功。

./uninstall.sh

步骤二：卸载 Sgagent（云服务器监控组件）

注意：卸载此项将导致你无法在官方网页控制台上查看到服务器使用资源的情况。

1.执行以下命令，进入 Sgagent 安装目录。

cd /usr/local/qcloud/stargate/admin

2.执行以下命令，卸载 Sgagent。该命令不显示结果，您可以执行crontab -l |grep stargate 命令查看是否有计划任务，若无计划任务，则说明卸载成功。

./uninstall.sh

步骤三：卸载Yunjing（云镜）

（总的来说就是个监控组件兼杀毒软件。）

1.执行以下命令，卸载Yunjing。

/usr/local/qcloud/YunJing/uninst.sh

另外我在使用过程中还发现有个进程rshim的内存占用达到10-20M。rshim驱动程序提供了一种从外部主机访问 BlueField 目标上的 rshim 资源的方法。对于我们来说，用不上这个，删掉。

在/usr/sbin文件夹下查找该进程
找到该进程文件后，禁用其写权限chmod 600 rshim
```
chmod 600 rshim
```
kill掉rshim进程
查询进程是否存在
```
ps -ef | grep rshim | grep  -v grep
```
如果不存在，那么该进程已经被成功删除。

总结就是，把服务器上自带的捆绑软件全部删干净，来腾出更多的服务器资源运行服务端。将这些监控组件和rshim卸载后，你的服务器将变得更加清爽，并且没有多余的内存占用了。
至于Linux的开服教程，论坛内有许多教程，在此就不赘述了。
不过SSH工具我推荐使用Finalshell，这款软件是国产的，并且我认为比Xshell更好用，Xshell有的它都有，Xshell没有的它也有，并且基础版已经足够我们使用了，高级版和专业版只是加了些不怎么实用的辅助功能，完全不必要购买（当然，如果你的经济情况不错，你可以购买高级版或专业版作为对作者的打赏）。

关于Windows系统的优化：

服务器上不要安装乱七八糟的软件，服务端运行时最好确保只有必须进程在运行。如果在服务端运行时，同时运行了多个进程，服务端就无法获得最大的性能释放，就好像145W的显卡，你只给到了85W，那么性能是打了相当大的折扣的。

如果你一定要在运行服务端时同时运行多个进程，那么可以使用Process Lasso将服务端进程的优先级设置调高，这将对服务端性能有一定优化作用，但是运行的其他进程会相应的获得更少的资源调配。

如果你的服务器使用的是intel的12代或者13代CPU，建议对电源计划进行优化，保证最充足的性能释放，同时搭配Process Lasso进行手动调度。

服务端核心的选择

事实上如果你的服务器配置不是很好，我更推荐开插件服。如果你想让你的服务器承载更多的玩家而不卡顿，并且获得相对来说更加流畅稳定的游戏体验，开个插件服绝对是最好的选择。

我的世界服务端的核心可谓是琳琅满目，各式各样的服务端绝对能让你眼花缭乱，所以接下来请移步服务端核心合集。
这篇文章罗列了目前常见的各种核心并进行了简单的介绍，你可以根据你的实际需求选择服务端核心，原则上优先选择优化更好，性能更好，兼容性更佳的服务端。
我个人推荐插件服使用Paper核心，因为这个核心在性能优化、稳定性、兼容性上都很不错，也是我自己用着最舒服的核心。不过除了Paper之外，Purpur（Paper和Tuinity的分支）、Tuinity（Paper的一个更加注重于对多玩家优化的分支）等服务端都是基于Paper，而更加侧重于优化的服务端，如果你希望获得更好的服务器性能，可以尝试这些进一步优化的服务端。

模组服我推荐用Catserver,Catserver是国内老牌的模组服务端核心，维护至今，在单核优化上做的很不错（曾经有多核优化版，不过因为存在Bug，所以开发者放弃多核优化版核心的维护更新了），我用Catserver开服的实际体验也还不错。高版本的话我推荐使用Arclight和Mohist，Arclight和Mohist同样是国产的模组服务端核心，就目前来看，它们的稳定性良好，操作人性化，优化也做的还不错。
尽管基于Bukkit的模组服务端可以使用大部分基于BukkitAPI的插件，但如果你的服务器加载了很多模组。我更加推荐你使用Sponge（即海绵端），Sponge直接基于Forge（严格上不能这么说，但你可以这么认为），对于模组的兼容性远高于其他Bukkit与Forge混合的服务端，如果你的服务器出现了模组与服务端的兼容性问题，请改用Sponge。
注意：你应该时刻关注服务端开发团队的最新动态，以保证你使用的是最新的服务端核心。

开服后的优化

服务器配置文件的优化（半壁江山）

当你第一次开服成功后，服务端根目录下会生成相关配置文件。关于配置文件的优化，论坛内已经有几篇不错的文章，在此就不过多赘述了，请移步服务器配置文件优化 — 用测试数据说话，服务器优化指南，相对来说我认为第一篇以实践为基础，内容比较可靠且专业，但是新人服主可能看不太懂,并且也不够全面。第二篇则翻译自SpigotMC论坛中的一篇优秀文章，内容更加清晰明了、简洁易懂，新手照着改即可。不过这篇文章已经很久没有更新了，至今停留在1.13版本的优化指南，而原作已经更新至1.16.5，虽然它仍然具有参考意义，但我建议你去看原贴（配置优化指南），事实上并不需要你拥有很高的英语水平，拥有一定的词汇量结合机翻就能够理解。

我个人的经验：配置文件的修改对于服务器流畅性的提升相当的大，前不久有个朋友找到我，说他的工业魔法服务器特别卡，他的服务器是2H4G的面板服，并且这个服务端有一百多个MOD，N个大型模组。我说：这还优化个鸟啊，能跑得动就算不错了。
不过我还是写了一份几乎是极限优化的配置文件扔给他，然后删掉了几个易于造成卡服的模组，平均TPS一下子就提升到了19点多。
但是，配置文件的优化往往伴随着游戏性的丧失，比如说我给他的配置文件view-distance只有3，这是相当低的数值了，可能会让习惯了远视距的玩家感到不适，所以在他提出这个问题之后，我告诉他把视距调到4，但是平均TPS立马下降到18，可见view-distance会在很大程度上影响TPS。
注意：1.14或更早版本的spigot.yml的view-distance优先度大于server.properties。

这里给出几个我认为很重要，可以说是必须在默认设置的基础上修改的参数（以下配置针对高版本Spigot系服务器，低版本一样可以参考）。

view-distance的降低可以极大程度的改善服务器的卡顿，如果你的服务器性能不佳，玩家人数偏高，或者你的TPS比较低，都应该将你的view-distance调低，一般4-5就是比较低，但带来的效果很好的值了（当这个值在3以下时，都会默认调整为3，即3是服务端view-distance的最低值）
server.properties中的network-compression-threshold意为网络压缩阈值，功能即字面意思。默认值为256，将此值提高可以以牺牲宽带资源来节省CPU资源（如果设置的太高则会造成客户端的网络延迟），将此值降低可以牺牲CPU资源来节省宽带资源。如果你的服务器是群组服，且子服之间的延迟小于1ms（运行在同一台设备上），推荐将此值设置为-1，即禁用此选项，因为内网的速度通常可以处理额外的未压缩流量。但切记如果你服务器的宽带速率不高，一定要把此项打开并且调试到一个合适的值，否则会出现玩家网络连接不稳定，频繁掉线，进入服务器困难等现象的发生，这种情况尤其常见于模组服当中。
bukkit.yml中的spawn-limits，即生物生成限制，生成公式为在线玩家数*限制配置，例如，当前服务器内有5名玩家在线，本项配置monsters设置为20，那么在已加载区块上，至多生成5*20=100个怪物类型的生物。推荐服务器性能不好的生存服设置monsters为25~40，animals设置为6-8，water-animals设置为2-5，water-ambient设置为2-5，water-underground-creature: 3，ambient设置为1
bukkit.yml中的chunk-gc，建议设置为300-400。设置此项的意义在于它可以更快的卸载空载的区块（即没有因为玩家而加载的区块），这可以在一定程度上改善内存的使用情况，但不应该把此项设置的过低，如果设置的过低，可能导致CPU的占用明显提升。
bukkit.yml中的ticks-per,monster-spawns可设置为8+，animal-spawns设置为400+，water-spawns设置为40+，water-ambient-spawns设置为25+，ambient-spawns设置为80+，事实上我这里给的推荐值偏保守了，如果你的服务器实体占用真的很多，还可以在推荐值的基础上往上调，但不建议将每项设置的过大，否则你会面临在你的服务器上找不到生物实体的窘况
spigot.yml中的max-tick-time设置tile和entity的总和小于等于30可以明显降低tile和entity对TPS的影响，但一般不建议将这两个值设置的过低，甚至推荐你将这两个值都设置为1000以禁用它，因为max-tick-time的设计本身就存在问题，如果你将它的值设置的很低，可能会发生实体（包括玩家）被跳过计算的情况发生，甚至它的值不需要很低（只要小于50）也有可能发生，具体表现为你攻击一个生物，却毫无反应，你的工作台或熔炉等方块无法工作（不止于这些情况）
spigot.yml中的mob-spawn-range推荐设置为你服务器视距的值减1，比如，你服务器的view-distance设置为了5，那么就把mob-spawn-range设置为4，这样设置与spawn-limits和ticks-per配合时能制造出你服务器的生物实体数量不少的假象
spigot.yml中的entity-activation-range一般建议将monsters设置为18-24，animals设置为12-16，raiders设置为48，misc设置为5-8,不建议将此值设置的过低，否则会导致玩家与生物十分接近时生物才会被激活
spigot.yml中的merge-radius是控制掉落物合并半径的设置，将此值调大可以允许更多范围更广的掉落物汇聚在一起，来减少掉落物对tick的占用。一般建议item设置为4-6，exp设置为6-8
spigot.yml中的item-despawn-rate实际上就是掉落物的消失时间，当此项数值降低时，可以明显改善掉落物带来的卡顿，默认值是6000，即5分钟清理一次掉落物，你可以将它设置为2400（2分钟）或更低。因为此项配置的存在，你根本不需要在你的服务端中安装扫地插件，如果你需要在扫地前提醒玩家，你只需要编写一个简单的shell脚本，并且设置好linux的计划任务即可

配置文件的优化真的很重要，针对你服务器的情况，不断的调试配置，设置合理的数值，可以为服务器的TPS带来很大提升，我这里只是简单的列举了几个参数的修改，如果你想对配置文件进行更深一步的优化，请参阅上文提到的两篇文章。

服务端和客户端的优化

关于JVM的选择，一个好并且适合的JVM可以为你的服务器带来很高的优化效果。推荐参考这一篇对几个知名JVM的对比选对 JVM，更有效地节省内存和CPU。
JVM我个人推荐使用阿里巴巴推出的Alibaba Dragonwell（即龙井），因为我已经在我自己的1.12.2的模组服上试运行了一个月，空载状态下内存占用下降了高达32%，TPS方面与使用hotspot时基本持平。并且龙井支撑了阿里经济体内所有的JAVA应用，稳定性方面毋庸置疑。

启动参数一样有前人的经验值得我们借鉴：Aikar的启动参数教程，站内的搬运汉化贴。强烈建议你在使用任何启动参数时，至少要对该参数有大概的了解，所以建议你去看看关于这个参数配置的详解。

适用于为服务端分配内存在12G以下的服务器使用

java -Xms最小内存 -Xmx最大内存 -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true -jar 服务端核心名.jar nogui

如果你为服务端分配的内存大于12G，请使用这个参数

java -Xms最小内存 -Xmx最大内存 -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=40 -XX:G1MaxNewSizePercent=50 -XX:G1HeapRegionSize=16M -XX:G1ReservePercent=15 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=20 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true -jar 服务端核心名.jar nogui

尽管G1GC更加适用于大内存服务器，但上述参数一样是我在基于实践后，证明的确对服务器的内存有优化作用的参数。这里我做了一个测试。我们将“java-Xmx最大内存 -Xms最小内存 -jar 服务端核心.jar nogui”定义为原版参数，适用于分配内存12G以下的Aikar参数定义为测试参数。

经过我的实际数据测试，保持一切无关变量不变，令4名玩家从出生点分别向东南西北四个方向快速跑图，在分别测试使用两种参数的情况在10分钟内分别记录20次TPS数据取平均值，统计结果显示原版参数TPS平均值为19.92，而优化参数TPS平均值为19.94，通过Timings可以看到，使用本参数后在内存回收时带来的延迟峰值与使用原版参数相比要低了一截，且更加平滑，这意味着当服务器进行内存回收时带来的负载有所降低。

综上，Aikar的优化参数经历了多年的测试，在几千甚至更多的Minecraft服务器上长期使用，你可以很放心的使用它，因为它也许是目前在普适优化性上最高的启动参数。注意：

如果你使用的操作系统是Linux，并且你服务器的内存充足，Xms和Xmx的值要比你服务器的最大内存至少小1500M（即给操作系统预留大于1500M的内存），以避免服务端运行内存不足，或被Linux的OOMkiller强制结束进程。
如果你的服务器是模组服，或者CPU占用持续过高，我推荐你将xms和xmx设置为相同数值，这是为了能够在GC后不需要重新分隔计算堆区的大小而浪费CPU资源。
使用优化参数启动时可能会报警，可能是因为该优化参数中部分参数可能将在更高版本的JDK中被删除，无视即可，不影响正常开服。

如果你的服务器是模组服，或者是需要专属客户端的插件服，在你已经将服务器优化的很不错了，服务器也相当流畅的情况下，还有玩家反馈卡顿的问题，那么问题所在很可能是客户端的优化原因，或是玩家硬件配置本身的问题。玩家的硬件配置，我们很难去优化，但是客户端的问题，我们可以通过以下几个措施来优化。

使用优化的启动参数，摘自ksqeib445的文章
-Xss512K -XX:+AggressiveOpts -XX:+UseCompressedOops -XX:+UseCMSCompactAtFullCollection -XX:+UseFastAccessorMethods -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=2 -XX:CMSInitiatingOccupancyFraction=70 -XX:-DisableExplicitGC -XX:TargetSurvivorRatio=90
- 避免客户端的臃肿，精简客户端安装的MOD，并且安装优化MOD比如，Forge端可以安装：Optifine、铁氧体磁芯、FoamFix、BetterFPS、Phosphor（相比于Starlight，磷只是基于原版光照系统进行修改优化，它的兼容性更好）、Starlight（对原版光照机制的彻底重写，性能突出）等等。（应当注意尽量避免安装的两个优化mod在功能上的重叠）
- Fabric端可以安装的优化类模组更多，且这些mod的优化效果较之forge端的优化mod要更强：Sodium，Lithium，Iris Shaders（Fabic端开光影要用），Hydrogen（较锂而言，他在优化方面做出的修改更加激进，所以兼容性更差些）、FerriteCore（与Foamfix同样专注于内存方面的优化，效果很不错），Starlight（对原版光照机制的彻底重写，性能突出）、C^2M 引擎（旨在提高Minecraft区块的性能，原身是Barium（钡））等等。安装这些mod之前你必须在官方模组发布页或者mcmod站上了解这些mod的注意事项，否则可能导致各类问题的发生。

优化MOD和插件的安装

由于服务器本身的硬件配置就不是很好，所以就别作死将模组插件一股脑的塞进服务端来。
如果你开的是模组服，请确定你的服务器主要游玩哪些模组，除这些模组之外的MOD就别加进来了，避免服务端的臃肿。
同时你需要对你添加的模组有一定了解，在决定添加某个模组之前，请先前往mcmod站或模组的CurseForge主页了解此模组相关事项。
比如说你事先了解到植物魔法的产能花和火花、AE的自动合成、拔刀剑的幻影剑容易造成卡服，你就可以有针对性的去查找解决方案，或者在MCBBS你问我答版块内提问以获得解决方案。
插件的选择请尽量选择性能高，轻量化的插件，以能满足需求即可，不必要太过追求功能强大。一个插件或原版机制就能解决的事不要让2个甚至多个插件来解决！

另外如果不是真的需要反作弊插件，我建议不使用反作弊插件，因为它们大多数都占用了很多服务器资源，我曾见过很多服务器因为反作弊插件从而导致服务器的卡顿，尤其是Spartan带给我的印象尤其深刻，每一次有安装了Spartan插件的服务器的服主发Timming给我时，Spartan总是最亮眼的undefined......不过在目前主流的反作弊插件中，优化部分配置项可以在较小的性能损失下达到理想的效果，这需要使用者认真查看相关的插件使用说明。

安装这些mod之前你必须在官方模组发布页或者mcmod站上了解这些mod的注意事项，否则可能导致各类问题的发生。（应当注意尽量避免安装的两个优化mod在功能上的重叠）

推荐安装的MOD（这些mod通常在客户端也能正常运行）：铁氧体磁芯、FoamFix、Phosphor、Starlight、另一个通用Bug修复（这个MOD推荐模组服安装，修复了很多常见模组的BUG，注意要安装修复包！否则等于没装。）
推荐安装的插件：Insights(可以限制在一个区块中最多可以放置多少个指定方块)、WorldBorder、Chunky(高版本使用)、AntiRedstoneclock（当服务器TPS下降时自动降低红石频率）
注意：我不推荐在服务端中安装过多的优化类插件或者Mod，在不使用的时候你甚至可以禁用它。并且我需要提醒你，经过几年的发展，诸如Paper、Purpur、Tuinity、Airplane等服务端在优化方面都做的很好，他们提供了许多与优化相关的配置项，很多时候你不需要额外安装Lag优化插件,甚至有时会产生负面影响。
如果你的服务器安装了FoamFix，需要修改以下几项配置：

在 forge.cfg 中启用alwaysSetupTerrainOffThread，开启多核加载（如果你的服务器是多核的话）。
在server.properties中设置max-tick-time=0 可以解决与“java.lang.Error: Watching server”相关的崩溃。
根据FoamFix官方声明，FoamFix不支持Sponge，不过理论上FoamFix做出的优化Sponge一样有效，如果你使用的是Sponge端，你需要禁用config中foamfix.cfg 中的 coremod.optimizedBlockPos 来修复与MixinMutableBlockPos相关的常见崩溃。

预加载区块

正式迎接那些活蹦乱跳的玩家之前，还有一件很重要的事情需要做——预加载区块。
加载区块是很消耗服务器性能的一件事，服务器需要花费大量时间来生成区块，然后生成光，再然后还要加载区块，所以如果你不希望区块成为拖垮你服务器的罪魁祸首，请一定要预加载区块。
想象一下，你的服务器中有多个活跃，并且热衷于跑图的玩家，他们在你的服务器地图内四处奔跑，探索一个又一个未被加载的区块。他们在你的服务器内尽情的奔跑，而服务器的CPU也在后台“满头大汗”的“尽情”奔跑，甚至不止是CPU，内存和宽带都会受到相当大的损耗。这个时候，服务器的TPS就会骤降，同时服务器内的玩家也能明显感到服务器变的卡顿起来。所以，预加载区块的重要性不言而喻。
目前WorldBorder原作者已弃坑，WorldBorder的高版本目前虽然有其他人接手维护，但我还是建议高版本使用Chunky,因为Chunky目前已经比较成熟了。
具体做法：

请确保你的服务器安装了WorldBorder，因为我们预加载插件要使用到它。
进入游戏，站在你要设定边界的中心位置，输入指令/wb set <你要设置的边界半径>。
控制台输入wb <你要填充的世界名> fill confirm。
然后服务器就开始进行区块填充了，如果要暂停填充，请输入wb fill pause，如果要取消填充，请输入wb fill cancel。

这一过程可能会造成服务器卡顿，所以推荐夜深人静，没有玩家在服务器时进行,你也可以使用WorldBordAutoFill插件进行自动填充。
当你的区块都预加载好之后，就再也不用担心因为玩家跑图引发的卡顿啦！
Chunky的使用：

在服务端上安装Chunky。
使用chunky world 世界名选中你想设置的世界。（或进入游戏，进入你想设置的世界，输入以下指令）
chunky radius <你想设置的半径>。
chunky worldborder <你想设置的边界>。（与Worldborder不同的是，chunky可以不必设置边界，但推荐你设置为与你预加载半径相同的数值，以防玩家离开边界跑图）
开始预加载，chunky start

定时重启

随着服务器运行时长的增长，内存使用量的不断增加，服务端的不稳定性也会不断增加，这很容易导致服务器的突发性崩溃。
所以，请定时重启你的服务器，建议24小时内至少重启一次，以避免上述问题的发生，如果你的服务器内存比较吃紧，因为内存不足而导致的崩溃频繁发生，还可以继续缩短重启间隔时间。（比如本文的主角-我的1H2G测试用学生服务器，在加载了一些模组和插件，承载了10余人的情况下需要约2小时重启一次，否则会发生内存溢出。）
Driver_C已经写了一个定时重启脚本，代码简洁明了，注释详细到位，我自己再写一个脚本也只是班门弄斧。大家直接移步Linux开服的全面教程拉到页面最下面，打开可靠的自动重启脚本配置折叠栏就可以看到了。
同时我自己写了一份检测到内存不足自动重启的脚本,它很适合内存不足的服务器使用（记得下载后把.txt改为.sh后缀哦！）

游客，如果您要查看本帖隐藏内容请回复

防止服务端被Linux的OOM killer机制杀死

一般来说这种情况往往在模组服中出现，这是物理内存不足或内存溢出的硬伤。
关于OOM：OOM_killer是Linux自我保护的方式，当内存不足时不至于出现太严重问题（比如死机或者强制性关机），有点壮士断腕的意味。
在kernel 2.6，内存不足将唤醒oom_killer，挑出/proc/oom_score最大者并将之kill掉。与OOM相关的几个文件是 /proc/oom_adj 、 /proc/oom_score。前者是一个权值-17至15。设置为0表示永远不被kill，其余情况值越大越容易被kill。后者就是它计算出来的一个值，就是根据这个值来选择哪些进程被kill掉的。为了保护重要进程不被oom-killer掉，我们可以：echo -17 > /proc/oom_adj,-17表示禁用OOM
我们也可以对把整个系统的OOM给禁用掉：
sysctl -w vm.panic_on_oom=1 （默认为0，表示开启）
当overcommit_memory=0 允许进程轻微过量使用内存，但对于大量过载请求则不允许(默认）
当overcommit_memory=1 永远允许进程overcommit
当overcommit_memory=2 永远禁止overcommit
注意：这是个治标不治本的方法，只能算是“缓兵之计”，倘若物理内存确实严重不足，这种方法可能会导致死机或长时间不响应的问题出现，想要从根本上解决JAVA进程被OOM杀死的问题，提高物理内存是最根本也是最有效的方法，其次是检查出导致内存快速大量增加的原因是什么，然后解决它。（一般是某些模组占用内存过多,多数情况下为工业类模组，因为工业类模组往往注册了大量物品和方块,这种问题往往通过模组铁氧体磁芯或是氢能够得到有效解决；或者是在没有预加载地图的情况下，有玩家在服务器内跑图，因为玩家跑图加载的区块在一定时间内都是临时储存在内存中的;当然，也有可能是发生了内存溢出）

雷区

拿到一个服务端却在配置方面什么也不调就是最大的雷区，大部分服务端默认的服务端配置都会给服务器带来不小的压力，尤其是当人数上升之后，不要仗着是神机就横着走，否则会摔个狗啃泥。
不要在你的服务器上使用大量的结构生成类型的数据包！实际上数据包效率低下，会给性能带来影响，尤其是大型数据包，因为数据包就可以看作是命令组，工作依赖于重复的发出某些命令。如果按照性能来排序的话：插件>数据包>命令方块，所以可以用插件实现的功能，就不要用数据包。
游戏版本1.18以上，由于区块大改，不管是对服务端还是客户端，都增加了一定的计算和内存压力，所以如果要开1.18版本以上的服务器，应当适当考虑提升服务器配置以及合理安装部分优化类模组。
部分模组，例如科技工业魔法类，或是包括大量结构体生成的模组比较容易造成卡顿。在对服务器进行优化时，应该对这些模组加以关注，寻找造成卡顿的原因也可以从这些模组入手，特别是应该去社区，比如mcbbs或是mcmod上搜索这些模组可能造成的问题，并加以解决。比如说现在有一个含有大量结构体，并且生成频繁的模组，通常这类模组都会有关于结构生成概率和数量的配置项，此时调低结构的生成概率和数量即可有效解决问题。

服务器性能的分析与调优（有时间就把这个大坑填完，支持我能让我更的更快undefined）......

来自群组: 服主交流组