Day: June 20, 2026

背景 一套 Minecraft 1.19.4 Forge 服务端运行在 Linux 主机上，并通过 systemd 管理。服务端使用多模组环境，世界存档体量约数 GB，包含主世界、下界、末地以及额外维度。此前服务端在运行过程中出现异常，停止服务时 systemd 报告 timeout，并最终对 Java 进程发送强制终止信号。 最初看起来像是服务器性能不足、保存世界过慢或 systemd 停止超时太短。但经过只读检查后，真正的主线问题被定位为：服务端实际 JVM heap 只有 1GB，Forge 多模组环境运行一段时间后发生 Java heap OOM，随后在保存世界时又撞上了 systemd 默认 90 秒停止超时。 初始现象 服务端停止时出现过如下现象： 这类日志容易让人第一时间怀疑是 systemd 停止流程本身有问题，或者服务器保存世界太慢。但如果只盯着停止阶段，会忽略更早发生的根因。 进一步检查崩溃报告和 latest.log 后，可以看到关键异常是： 同时崩溃报告中的 JVM Flags 显示： 这说明服务端最大堆内存只有 1GB。对于 Minecraft 1.19.4 Forge、多模组、多个维度和数 GB 世界存档来说，1GB …

背景 一套 Minecraft 1.19.4 Forge 客户端运行在 Linux 桌面环境中，桌面为 KDE，显示设备为 27 英寸高分辨率屏幕。由于客户端配置曾经经过较随意的手动调整，实际运行时存在发热、卡顿、负载偏高的可能。与此同时，服务端也出现过停止超时和内存不足问题，因此有必要先把客户端侧的明显性能压力项梳理清楚。 优化目标并不是把画质压到最低，也不是追求极限帧率，而是在保留正常视觉体验的前提下，让客户端运行更加稳定、少卡顿、低发热，并尽量减少客户端对服务端区块加载压力的间接影响。 初始检查发现的问题 客户端配置中最明显的性能压力来自几个方向：原版图形档位、渲染距离、模拟距离、帧率上限、OptiFine 视觉增强项，以及 JourneyMap 的常驻地图显示层。 首先，原版图形档位处于较高状态。配置中 graphicsMode:2 对应的通常是 Fabulous 档位。Fabulous 会使用更重的渲染路径，对高分辨率屏幕和老款 GPU 更不友好。对于普通生存和模组游玩来说，Fabulous 带来的视觉提升并不总是值得持续负载增加。 其次，客户端的 renderDistance 和 simulationDistance 均为 10。这个数值不算极端，但在 Forge、多模组、高分辨率显示环境下，会明显增加客户端渲染、CPU、内存和区块处理压力。模拟距离还会影响周边区块和实体的活跃范围，在联机环境中也可能间接增加服务端压力。 第三，帧率限制几乎处于放开状态。配置中 enableVsync:false，同时 maxFps:260。对于 60Hz 或普通显示目标来说，这种设置会让 GPU 和 CPU 尽可能多地渲染帧，即使肉眼和显示器无法完整利用，也会带来额外发热、风扇噪音和帧时间波动。 第四，OptiFine 中存在多项视觉增强功能，例如 Connected Textures、Dynamic Lights、Custom Sky、Custom Entity Models、Custom …