在MCSM中有一个不起眼的功能——容器化，但实际上这个功能非常好用，可以很方便的隔离环境，限制性能，指定核心，但很多人都不会用
1.镜像选择
由于Openjdk的Docker镜像已经不再维护，现在流行的都是由各大知名大厂、社区基于 OpenJDK 编译并长期维护的Tck 兼容认证生产级 JDK 镜像，我比较推荐使用 eclipse-temurin，这是由Eclipse 基金会 (红帽、IBM等)维护的镜像
使用时根据我的世界版本选取合适的镜像版本即可，比如在Tags中搜索11-jdk,21-jdk等版本
2. 启用容器化
在实例控制界面点击应用实例设置-容器化，选择“启用Docker容器”
然后在右侧选择(如果你已经将镜像拉取到本地)或填写你上一步选择的镜像
其他默认的设置不需要修改，在网络模式方面，我比较推荐使用bridge网桥，这样可以比较方便的管理端口映射，而不是使用host模式每次修改端口都要去修改配置文件。
然后在开放端口处点击编辑，新增一条配置(内部端口一般是25565,如果你在配置文件中修改过就使用你改过的端口)
下面的容器名这里可以留空让MCSM自动生成一坨，当然也可以自己写一个你看着顺眼的
3.容器限制
使用容器化后可以很方便的限制容器性能，在应用实例设置-容器限制可以进行这项配置
比较基础的是限制最大内存，防止服务端在某些情况下把物理机干死
需要注意的是这里的CPU 总和使用率，指的是CPU每个核心使用率的和，比如200%
就是占用了两个核心
指定 CPU 计算核心
对于一些采用大小核架构的消费级 CPU,我们还可以使用指定 CPU 计算核心，在 linux 服务器上运行lscpu -e可以获取每个 CPU 核心的详细信息，比如我的i9-14900kf的输出是这样的:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| ➜ ~ lscpu -e
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ
0 0 0 0 0:0:0:0 是 5700.0000 800.0000 5700.0000
1 0 0 0 0:0:0:0 是 5700.0000 800.0000 800.0000
2 0 0 1 4:4:1:0 是 5700.0000 800.0000 5700.0000
3 0 0 1 4:4:1:0 是 5700.0000 800.0000 800.0000
4 0 0 2 8:8:2:0 是 5700.0000 800.0000 5700.0000
5 0 0 2 8:8:2:0 是 5700.0000 800.0000 5657.8062
6 0 0 3 12:12:3:0 是 5700.0000 800.0000 5700.0000
7 0 0 3 12:12:3:0 是 5700.0000 800.0000 800.0000
8 0 0 4 16:16:4:0 是 6000.0000 800.0000 5700.0000
9 0 0 4 16:16:4:0 是 6000.0000 800.0000 5382.4360
10 0 0 5 20:20:5:0 是 6000.0000 800.0000 5700.0000
11 0 0 5 20:20:5:0 是 6000.0000 800.0000 800.0000
12 0 0 6 24:24:6:0 是 5700.0000 800.0000 5700.0000
13 0 0 6 24:24:6:0 是 5700.0000 800.0000 800.0000
14 0 0 7 28:28:7:0 是 5700.0000 800.0000 5700.0000
15 0 0 7 28:28:7:0 是 5700.0000 800.0000 800.0000
16 0 0 8 32:32:8:0 是 4400.0000 800.0000 800.0000
17 0 0 9 33:33:8:0 是 4400.0000 800.0000 4368.9390
18 0 0 10 34:34:8:0 是 4400.0000 800.0000 4400.0859
19 0 0 11 35:35:8:0 是 4400.0000 800.0000 4337.2222
20 0 0 12 36:36:9:0 是 4400.0000 800.0000 800.0000
21 0 0 13 37:37:9:0 是 4400.0000 800.0000 800.0000
22 0 0 14 38:38:9:0 是 4400.0000 800.0000 4400.6821
23 0 0 15 39:39:9:0 是 4400.0000 800.0000 800.0000
24 0 0 16 40:40:10:0 是 4400.0000 800.0000 800.0000
25 0 0 17 41:41:10:0 是 4400.0000 800.0000 4400.0400
26 0 0 18 42:42:10:0 是 4400.0000 800.0000 4359.9048
27 0 0 19 43:43:10:0 是 4400.0000 800.0000 800.0000
28 0 0 20 44:44:11:0 是 4400.0000 800.0000 800.0000
29 0 0 21 45:45:11:0 是 4400.0000 800.0000 4400.9121
30 0 0 22 46:46:11:0 是 4400.0000 800.0000 4399.6802
31 0 0 23 47:47:11:0 是 4400.0000 800.0000 800.0000
|
其中第一列的 CPU 就是你要填入MCSM的核心编号，第四列是物理核心编号，所以需要注意不要把一个物理核心的两个逻辑核心分配给不同的服务端，这会导致资源竞争
同时也需要避免将 CORE0 对应的CPU 0,1 分配给服务端，这两个逻辑核心通常运行着宿主机系统（Ubuntu/Debian）、Docker 守护进程以及网络中断
在开启我的世界服务器时，最好将 MAXMHZ 最高频率高的核心分配给服务端，比如这里我应填写8,9,10,11来将能跑到 6Ghz 的的核心分配给服务端，对我的世界来服务端来说，一般分配2-3个物理核心就足够了，分配多了他也无法利用
当然如果你想坑人卖别人垃圾服务器也可以把小核分给他(bushi
之后重启一下服务器就可以开始wan了:)
4. 服务端性能调优
Java启动参数
对于高版本forge服务端，可以添加一些参数来优化性能，比如添加这些参数
1
2
3
4
| -Xmx12G
-XX:ParallelGCThreads=6
-XX:ConcGCThreads=2
-XX:G1ConcRefinementThreads=6
|
其中 -Xmx12G 对应你分配给服务端的内存，-XX:ParallelGCThreads和-XX:G1ConcRefinementThreads应该对应你分配给服务端的逻辑核心数目
优化Mod
- ModernFix：优化 高版本 的内存分配，减少模组服的内存碎片。
- FerriteCore：大幅降低由 Mod 引起的数据结构内存占用。