高主频独立服务器，保持稳定 tick 率

大多数游戏服务器都在单个主线程上运行模拟。Minecraft（Java 版）的每个世界 tick 都在主线程中处理，许多其他游戏也是如此：多出来的核心可以分担网络、区块生成和插件，但 tick 循环始终绑定在一个核心上。以每秒 20 tick 计算，每个 tick 只有 50 ms 的时间预算，一旦超时，玩家就会遇到位置回弹。

这正是 Core 系列适合游戏服务器的原因。Core 16X 加速频率可达 5.7 GHz，并借助 3D V-Cache 拥有 128 MB L3 缓存，大型世界的更多状态数据可以留在片上，不必等待内存。Core 16 最高 5.4 GHz，配备 64 MB L3 缓存，$299/月。

在硬件之上，还有这些实用调优：

• 用 taskset 或 systemd 的 CPUAffinity 将每个实例绑定到各自的核心，避免繁忙的服务器争抢同一个核心。
• 将 CPU 调频策略（governor）设为 performance。
• 为 Java 服务端设置固定堆大小（-Xms 与 -Xmx 相同），按单个实例的需要设定，而不是按整机内存。

先按繁忙的主线程数量规划，再看内存。粗略估算如下：

估算前提：每个主线程接近满载的实例占用一个物理核心；保留两个核心给操作系统、备份和语音服务；约 10% 的内存留给操作系统。负载较轻的服务器（例如小型私人世界）可以共享核心，因此实际数量往往更高；重度模组服可能每个需要两个核心。Pro 32 能容纳更多实例，但加速频率为 4.4 GHz 而不是 5.7 GHz，因此最适合轻量游戏和配套服务。

先实测，再定方案：在玩家人数峰值时运行最繁忙的地图，观察 tick 耗时（例如在 Minecraft 上使用 spark 性能分析器，或查看游戏自带的服务器统计），并确保峰值时主线程至少还有 20% 的余量。

玩家最先感受到的就是延迟，所以要把服务器部署在离玩家近的地方。Core 系列服务器覆盖全部 10 个机房：纽约、阿什本、达拉斯和洛杉矶；阿姆斯特丹、法兰克福和伦敦；新加坡、东京和悉尼。粗略估算，光纤路径每增加 1,000 km，往返时延约增加 10 ms，因此选对地区比任何调优都重要。可以用我们的 Looking Glass 网络测试工具从玩家所在的网络实测。

游戏流量以小型 UDP 数据包为主，而游戏服务器又是 DDoS 攻击的常见目标。FlexDedi 在网络边缘为每个 IP 过滤攻击流量，始终开启、已含在价格中，无需任何配置。你自己的防火墙也要收紧：只开放实际使用的游戏端口和查询端口，RCON 和管理面板只允许你自己的地址访问。

10 Gbps 端口不限流量，向成千上万名玩家分发地图、模组和更新，都不会产生额外费用。需要多个游戏服都使用默认端口？可按需申请额外的 IPv4 地址。