服务端优化
前言
对一个 50 人同时在线的 Paper 服来说，TPS 每跌 1，玩家24 小时留存率就掉 12 %——这是 Hypixel 公开运营数据里的铁律。于是你连夜换上 9950X3D、把内存加到 32 GB，结果 /tps 还是稳不到 18。
但，真正的瓶颈往往不在机箱里，而在 Spigot.yml 里那个默认 true 的 use-async-chunks，以及你刚装的那堆"万能"插件：它们把区块生成、实体 AI 甚至背包排序统统塞进主线程，CPU 再强也只能排队——选错一个插件，比少加内存，更能让社区瞬间鬼服。
序章
本篇文章将从三个核心维度来教各位如何优化Minecraft服务端：
- 启动参数优化 - 包括JVM启动参数配置、内存分配策略等底层优化
- 插件优化（主要针对非Paper用户）- 涵盖Spark火花插件的火焰图分析、Lag-Fixer服务端卡顿修复、Chunky区块预加载等插件的配置与使用
- 服务器配置文件优化 - 对spigot.yml和paper.yml等核心配置文件的参数进行调优
启动参数，插件配置我会给出个人总结后的通用模板供想偷懒的人直接使用。
重要提醒：我提供的配置仅为个人调试总结，由于CPU体质、系统版本、内存频率、服务器硬件配置等影响因素，实际效果可能存在差异，请各位根据自己情况调整。[测试环境m1 Mac os15.5 zulu-jdk 24 下面有截图]
再次提醒：优化前请备份好服务器文件，方便自己反悔（是的，万一翻车了还有后悔药）
希望各位服主（无论是准备开服还是已经在运营）在看完这篇文章后能有效优化自己的服务端
正文
1. JVM启动参数优化
JVM启动参数直接影响服务端性能和稳定性。根据YouHaveTrouble/minecraft-optimization和brucethemoose/Minecraft-Performance-Flags-Benchmarks两个权威项目的基准测试验证，合理的参数设置能显著提升TPS并减少卡顿。
Java版本选择
根据官方测试数据，不同Minecraft版本对应的推荐Java版本：（开服首选zulu/龙井[雨云严选]）
- 1.20.5+: 必须使用Java 21+
- 1.17-1.20.4: Java 17+
- 1.16.5: Java 17兼容性最好
- 1.15及以下: Java 8
启动脚本的JVM参数
基于实际性能测试的优化参数配置：
核心G1GC参数（经过Benchmark.py验证）:
-Xms8G -Xmx8G # 内存设置，建议相同值避免动态扩容
-XX:+UseG1GC
-XX:MaxGCPauseMillis=37 # 经过测试，37ms比Aikar的200ms更优
-XX:G1HeapRegionSize=16M
-XX:G1NewSizePercent=23 # 降低新生代占比，减少长暂停
-XX:G1ReservePercent=20
-XX:SurvivorRatio=32
-XX:G1MixedGCCountTarget=3
-XX:G1HeapWastePercent=20
-XX:InitiatingHeapOccupancyPercent=10
-XX:MaxTenuringThreshold=1
高级优化参数（Benchmark验证有效）:
-XX:+UnlockExperimentalVMOptions
-XX:+UnlockDiagnosticVMOptions
-XX:+AlwaysActAsServerClassMachine
-XX:+AlwaysPreTouch
-XX:+DisableExplicitGC
-XX:+UseNUMA
-XX:NmethodSweepActivity=1
-XX:ReservedCodeCacheSize=400M
-XX:NonNMethodCodeHeapSize=12M
-XX:ProfiledCodeHeapSize=194M
-XX:NonProfiledCodeHeapSize=194M
-XX:-DontCompileHugeMethods
-XX:MaxNodeLimit=240000
-XX:+PerfDisableSharedMem
-XX:+UseFastUnorderedTimeStamps
-XX:+UseCriticalJavaThreadPriority
实际性能对比
| 参数组 | 平均GC暂停时间 | TPS稳定性 | 内存占用 | 适用场景 |
|---|---|---|---|---|
| 默认参数 | 150-300ms | 波动较大 | 较低 | 测试服 |
| Aikar标志 | 50-100ms | 中等 | 中等 | 通用服 |
| 基准优化 | 15-40ms | 最稳定 | 中等偏高 | 生产服 |
关于内存的建议
计算公式：[基于github项目归纳总结得出]
基础内存 = 服务器类型系数 × 玩家数量 + 插件开销 + 预留缓冲
服务器类型系数：
- 生电服：0.3-0.4GB/人
- 小游戏服：0.2-0.3GB/人
- RPG服：0.25-0.35GB/人
- 生存服：0.2-0.25GB/人
- 空岛服：0.15-0.2GB/人
插件开销：
- 基础插件：1-2GB
- 大型RPG插件：2-4GB
- 小游戏插件：1-3GB
预留缓冲：2GB（系统+其他进程）
快速查表（基于基准测试数据）：
| 服务器类型 | 微型(<10人) | 小型(10-30人) | 中型(30-60人) | 大型(60+人) |
|---|---|---|---|---|
| 生电服 | 6-8GB | 8-12GB | 12-18GB | 18-24GB |
| 小游戏服 | 4-6GB | 6-10GB | 10-14GB | 14-18GB |
| RPG服 | 5-7GB | 7-11GB | 11-16GB | 16-20GB |
| 生存服 | 4-6GB | 6-9GB | 9-13GB | 13-16GB |
| 空岛服 | 3-5GB | 5-8GB | 8-11GB | 11-14GB |
验证方法：
# 实际测试命令
java -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -jar server.jar
# 观察Full GC频率，超过1次/小时就加内存
内存分配不要超过物理内存的80%，留20%给系统和其他进程
先按最低标准配置，通过Spark监控实际使用情况后逐步增加
通过合理配置JVM参数，基于实际基准测试数据，你的Minecraft服务器性能会有显著提升。建议先在测试环境验证后再应用到生产环境。
2.插件优化
在完成了JVM启动参数的基础优化后，我们进入服务端优化的第二个环节——插件优化。
优化插件是提升Minecraft服务端性能的关键步骤。合理选择优化插件、调整插件配置，移除不必要的，功能重复的插件[此主题会在以后讲，还没想好怎么概述插件列表的优化]
[最偷懒的方法：在服务端shell里输入plugin即可获得你服务器的插件列表，然后丢给ai问问有没有功能重复的插件然后做出适当移除。请自己判断一下ai的回答，在移除前自己去查查插件功能，ai的幻觉率还是很高的]
可以显著减少服务器的资源开销，提高运行效率。同时使用强大的优化插件，适当调整配置文件，能够在保持核心功能的同时降低性能开销。
本章节将重点介绍三个核心优化插件：[这些插件均可在spigotmc下载到]
- Spark（火花）：通过火焰图精准定位卡顿源头，让性能问题无所遁形
- Lag-fixer（服务端卡顿修复）：修复常见的服务端卡顿问题
- Chunky（区块预加载）：合理预加载区块，避免玩家探索时的卡顿
2.1 Spark
插件链接：Spark [点击即可跳转spigot官方网站]
插件简介：Spark是一个性能分析插件，管理员可以通过火焰图精准定位服务器卡顿源头，在Paper服务端中已内置。
关键配置
| 配置项目 | 命令/设置 | 推荐值 | 说明 |
|---|---|---|---|
| 卡顿警报灵敏度 | /spark monitoring --threshold 200 |
200 |
默认过低，调到200%才能抓到真正卡的时候 |
| 性能检测精度 | /spark profiler --interval 4 |
4 |
改成4毫秒能发现更多问题 |
| 权限设置 | spark.* |
管理员专用 | - |
常用命令
/spark profiler start- 开始60秒性能分析/spark monitoring- 开启实时监控/spark profiler --timeout 120- 自定义分析时长
火焰图示例
性能热点分析:
████ 高CPU占用 (>40%) ███ 中等占用 (10-40%) ██ 一般占用 (5-10%) █ 轻微占用 (<5%)
火焰图解读：横轴表示CPU时间占比，纵轴表示调用栈深度。越宽的条块表示该组件占用CPU时间越多，这是优化的重点！Spark的web里你还能挖掘出更关于服务器占用的信息，此处不过多赘述
注意事项
重要警告：/spark heap 命令会严重卡服务器，人多的时候禁止使用！
2.2 Lag-Fixer
插件链接：Lag-Fixer [点击即可跳转spigot官方网站]
插件简介：Lag-Fixer是一个综合性的服务器优化插件，能够自动清理垃圾实体、优化生物AI、限制红石频率，有效减少各类卡顿问题。
关键配置[config.yml]
| 配置项目 | 配置路径 | 推荐值 | 说明 |
|---|---|---|---|
| 监控刷新间隔 | main.monitor_interval |
10 |
默认5太频繁会增加CPU负担，改成10就够用了 |
| MSPT触发值 | LagMonitor.values.needed_mspt |
60 |
默认75有点高了，Paper默认是50，个人认为设60比较合适 |
| 实体密度上限 | EntityLimiter.perchunk.creatures |
12 |
默认15在养殖场容易超，调到12能降低实体密度减少TPS波动 |
| 世界清理间隔 | WorldCleaner.values.interval |
600 |
默认的240秒太短，会频繁清理世界垃圾。这个数值建议自己多调调 |
常用命令
/lagfixer status- 查看插件运行状态/lagfixer clear- 手动清理垃圾实体/lagfixer reload- 热重载配置文件[非常不推荐使用]
注意事项
配置警告：先在测试服调试配置，避免在正式服务器频繁修改配置文件然后reload，非常容易崩服！
2.3 Chunky
插件链接：Chunky [点击即可跳转spigotmc官方网站]
插件简介：Chunky是一个专门用于预生成世界区块的插件，能够在玩家到达之前提前生成地图区块，避免玩家探索时因区块生成导致的卡顿和延迟。
适用场景：新开服务器、跑图较多的服务器、大型活动前的地图准备，以减少玩家探索卡顿
关键配置
| 配置项目 | 命令/设置 | 推荐值 | 说明 |
|---|---|---|---|
| 预生成半径 | chunky radius 2500 |
2500 |
每1k×1k约60MB区块数据，10G内存建议≤2500半径 |
| 并发线程 | chunky threads 4 |
4 |
与JVM的ParallelGCThreads对齐，IO慢就降到2 |
| 世界选择 | chunky world world |
world |
指定要预生成的世界名称 |
| 生成模式 | chunky shape circle |
circle |
圆形生成比方形更自然，减少边界突兀感 |
常用命令
chunky world world- 选择要预生成的世界chunky radius 2500- 设置预生成半径chunky start- 开始预生成任务chunky pause- 暂停预生成任务chunky cancel- 取消预生成任务
使用流程
- 准备阶段：选择完全无玩家/少量玩家的时间段
- 临时调整：关闭Lag-Fixer实体限制，降低视距到6[服务器配置较高，带宽较大可以无视这一条]
- 开始预生成：使用合适的线程数和半径
- 完成后恢复：重新开启Lag-Fixer，恢复正常视距
注意事项
重要提醒：预生成时最好临时关闭Lag-Fixer的实体限制（/lf toggle EntityLimiter off），否则会误杀预生成的实体，导致生物数量偏少。
3. 配置文件优化
插件再好用，也改不了那些默认配置的毛病。下面这些参数改完就能起飞，照着抄就行：
必改四件套（基于YouHaveTrouble）
| 文件 | 关键配置 | 推荐值 | 一句话说明 |
|---|---|---|---|
| spigot.yml | entity-activation-range | animals:16,monsters:24,misc:2 | 远处生物直接休眠，节省CPU资源 |
| paper-world-defaults.yml | hopper.disable-move-event | true | 漏斗不监听事件，卡顿减少 |
| paper-world-defaults.yml | use-faster-eigencraft-redstone | true | 红石算法调优 |
| server.properties | network-compression-threshold | 256 | 网络压缩阈值，平衡CPU与带宽 |
| server.properties | simulation-distance | 4-6 | 模拟距离，影响实体更新范围 |
优化过的配置模板：
# spigot.yml 直接替换
world-settings:
default:
entity-activation-range:
animals: 16
monsters: 24
misc: 2
raiders: 48
water: 12
villagers: 16
flying-monsters: 48
simulation-distance: 4
view-distance: 8
mob-spawn-range: 3
merge-radius:
item: 4.0
exp: 6.0
ticks-per:
hopper-transfer: 24
hopper-check: 24
hopper-amount: 3
# paper-world-defaults.yml 直接替换
hopper:
disable-move-event: true
cooldown-when-full: true
ignore-occluding-blocks: true
max-entity-collisions: 2
use-faster-eigencraft-redstone: true
optimize-explosions: true
per-player-mob-spawns: true
armor-stands-tick: false
# server.properties 关键网络配置
network-compression-threshold=256
simulation-distance=4
view-distance=8
spawn-protection=0
max-tick-time=-1
改之前记得备份，每台服务器体质不同，数值得自己微调
不同类型服务器注意事项
| 服务器类型 | 推荐配置 | 绝对不能动的配置 | 说明 |
|---|---|---|---|
| 生电服 | 实体距离可适当调高到32 | hopper-amount保持1 |
红石机器需要精确的物品传输，调高会打乱时钟 |
| 小游戏服 | 所有配置优化拉满 | 无 | 小游戏不需要红石机器，怎么省CPU怎么来 |
| RPG服 | 实体碰撞可以调到4 | entity-activation-range别太低 |
NPC和怪物需要正常AI交互 |
| 生存服 | 照着模板抄即可 | 无 | 无 |
| 空岛服 | 刷怪范围可以调到6 | per-player-mob-spawns必须开 |
空岛刷怪塔依赖玩家独立刷怪 |
生电服警告
以下配置改了会炸机器，千万别动：
ticks-per.hopper-transfer: 8（必须保持8tick传输）ticks-per.hopper-amount: 1（必须一次传1个物品）use-faster-eigencraft-redstone: false（生电服要关闭红石优化）
生电服可以动的配置：
entity-activation-range可以调到32（不影响红石机器）max-entity-collisions可以调到8（养殖场需要更多碰撞）
结语
写到这里，回想起刚开始折腾服务端优化的时候，面对动不动就卡成PPT的服务器真的是头疼不已。从最初的盲目调参到现在基于数据的科学优化，算是踩了不少坑也积累了一些经验。
不过，服务端优化有点太老套了。对于新兴的Pumpkin——Rust重写的服务端，多线程处理、更激进的优化算法，这些新特性都为服务端优化带来了新的可能性。虽然目前还有很多bug，区块生成错误，物品无法拾取……不过开源社区有很多大佬在不断pr，解决issue，期待12月的正式上线。(我已经在测试服务端性能以及评估插件迁移难度)
想着光看文字可能还是不够直观，最近也在准备B站的视频教程，给各位更直观的优化教程。
参考资料
本优化指南基于以下权威开源项目的实际测试数据和最佳实践，以及自己测试得出：
主要参考项目
1. YouHaveTrouble/minecraft-optimization
项目地址：GitHub - YouHaveTrouble/minecraft-optimization: Minecraft server optimization guide
项目描述：Minecraft服务器优化指南，包含详细的配置文件优化建议和实际测试数据
主要贡献：
- 实体激活距离配置标准
- 漏斗和红石优化参数
- 网络配置最佳实践
- 不同服务器类型的配置建议
2. brucethemoose/Minecraft-Performance-Flags-Benchmarks
项目地址：GitHub - brucethemoose/Minecraft-Performance-Flags-Benchmarks: Sane, Benchmarked Java Flags and Tweaks for Minecraft
项目描述：Minecraft服务器性能标志基准测试，包含JVM参数的实际性能对比
主要贡献：
- 经过验证的JVM参数组合
- Java版本兼容性的测试
- GC暂停时间基准测试
以上项目均为开源项目，感谢社区开发者的贡献。
优惠码？我还不是代理()不过 欢迎注册 UID：29541
, 追求稳定/性能上 Purpur，追求原版特性上 Leaves，性能上 Leaf.