Solana VPS 与裸金属选型：CPU、UDP、网络测试 | ERPC

Solana 数据流很快，运行服务器也同样重要

Solana 流服务高速，并不代表数据能及时在应用中使用。即使 CPU 占用率很低、端口标称 1Gbps，也可能出现 Shreds 缺失或 gRPC 延迟持续增加。需要测量从数据源到应用的完整路径。本文依据匿名调查、独立测试和公开基准，讨论如何选择 VPS 与裸金属，而不是在原因未明时指责某家服务商。

高吞吐也意味着持续数据与短时突发

Shreds 与 Yellowstone Geyser gRPC 会持续推送数据，也可能出现短时间突发。带宽、每秒数据包数（PPS）、RTT、抖动、丢包和应用处理时间是不同指标。假设 4MB/s 持续 30 天，总量约为 10.4TB，但平均只有 32Mbps。这不能证明 1Gbps 一定不足，还要验证 UDP 限制、共享上联、突发处理和接收队列。

数据流在运行，片段却无法重建

一项匿名调查中，发送端短时观测约 3,400–3,900 个 UDP 包/秒，而接收端在另一个时间报告约 13 包/秒。收到的 Shreds 有效，但数量不足以重建数据；同一服务器的 gRPC 可用。两组数据的时间和位置不同，不能直接得出丢包率或认定原因。每秒数千包本身也不代表普通服务器无法处理。

更换机器前先确认数据在哪一层消失

UDP 可以在进入虚拟机之前受到网络策略、DDoS 防护或宿主机限制。到达 NIC 后，内核、套接字缓冲区和应用也可能丢包。先用 tcpdump 观察接收接口，再检查 NIC 计数、UDP 错误和应用队列。XDP 可能在 tcpdump 之前丢弃数据。比较双方时要对齐目标、端口和时间窗口。

同一城市不等于更短的网络路径

两台位于 Frankfurt 的服务器也可能分处不同设施和自治网络，需要经过外部 transit。实际调查中，从同一外部主机访问两个相距约 0.1ms 的 Amsterdam 节点，RTT 分别约为 11ms 和 23ms。另一个时间段，上游链路出现 5–8% 丢包和约 5ms 额外延迟。这是特定路径的观测，不是对所有服务商的概括。

让执行环境靠近数据源

通常 RPC 服务商提供数据，主机服务商提供算力，二者不保证位于相邻机架。ERPC 将 Shreds、Geyser gRPC、RPC 与 VPS、裸金属共同设计。在支持的站点，可以通过同一设施内的本地网络连接，减少不必要的外部绕路。Zero-Distance Communication 并非字面上的零距离或零延迟，仍需测试真实路径。

比较应用实际收到的数据

对同一 Amsterdam 端点的相近 Geyser gRPC 订阅，外部主机记录 3.7–4.2MiB/s 且 lag 持续增加。ERPC Frankfurt VPS 的独立单核限制测试在 60 秒内平均收到 9.396MiB/s、约 1,910 笔交易/秒，lag 未持续累积。异常路径上还观测到 TCP 重传。但接收主机与客户端实现不同，因此不是严格的 A/B 测试，不能把差距全部归于 ERPC VPS。另一个 HTTP/2 测试中，16KiB 接收窗口对应约 2.7MB/s，更大窗口达到最多约 7.1MB/s。

CPU 型号隐藏了真正的限制

相同 CPU 代际与 vCPU 数量不意味着相同的 Boost、电力、散热和调度策略。AMD Core Performance Boost 与 Intel Turbo Boost 可以被 BIOS 或宿主机关闭。即使开启，也不保证长期维持最高频率。虚拟机可能看不到宿主机的设置。应当测量实际工作负载的持续性能。

4 vCPU 的公开测试出现 1.93 倍差距

ERPC 在 Amsterdam 公布的 AMD Turin 4-vCPU、Ubuntu 24.04 对比中，sysbench CPU 分别为 ERPC 7,850 events/s、对比云 VM 4,062 events/s，特定测试约为 1.93 倍。公开资料还报告内存带宽约 3.2 倍、4K 随机读取 IOPS 约 16.6 倍。这不代表所有应用都会获得相同收益，也不能证明差距只来自 CPU Boost。

数据中心的成本结构会影响技术策略

电力、制冷、机架、交换机、线路和运维都要付费。共享资源与节能策略对普通应用合理，但高负载 Solana 流可能长期占用 CPU、PPS 和上联带宽。共享网络、单流限制、DDoS 防护和省电配置在不同场景下有不同适用性。关键是与自身工作负载匹配，而不是贬低服务商。

不要忽略云网络费用

持续数据流会在数周内累计为数 TB。一些云平台的互联网入站免费，但出站、跨可用区和服务间传输可能收费。符合条件的 ERPC 产品将平台内部流量与外部流量额度区别计算，具体以当前套餐为准。请比较整个数据路径的成本，而不仅是 VM 月租。

根据实际负载选择 VPS 或裸金属

轻量 RPC 可能适合 EPYC VPS；持续 gRPC 分析需要 CPU、内存余量。低延迟 Shreds UDP 和交易应用应测试 UDP 许可策略、PPS、突发、近距离部署和检测时延。需要独占物理 CPU 或 NIC 时可考虑裸金属，但它并非对所有应用始终更快。将负载拆分到多台 VPS 也可能有效。比较相同软件、过滤器、时间窗口下的有效 Shreds、重建、lag、重传与 p95/p99。

签长期合同之前先实测

在 Linux 中可用 tcpdump、nstat、ip -s link、ethtool -S、ss -tin 和 lscpu 进行以读取为主的初步诊断。替换示例 IP 与接口，比较计数器增量。lscpu 无法单独确认虚拟化宿主机的 Boost 策略。ERPC 对符合条件的 VPS 和裸金属按库存提供按小时使用方式。应选择能按时交付可用数据的环境。

bash

IFACE=ens3
SRC_IP=203.0.113.10  # documentation address; replace with real sender IP
PORT=2000
sudo timeout -s INT 10 tcpdump -nni "$IFACE" -l -q \
  "udp and src host $SRC_IP and dst port $PORT" 2>/dev/null | wc -l
nstat -az UdpInErrors UdpRcvbufErrors
ip -s link show dev "$IFACE"
sudo ethtool -S "$IFACE" | grep -Ei 'drop|miss|err|fifo'
ss -tin
lscpu

IFACE=ens3
SRC_IP=203.0.113.10  # documentation address; replace with real sender IP
PORT=2000
sudo timeout -s INT 10 tcpdump -nni "$IFACE" -l -q \
  "udp and src host $SRC_IP and dst port $PORT" 2>/dev/null | wc -l
nstat -az UdpInErrors UdpRcvbufErrors
ip -s link show dev "$IFACE"
sudo ethtool -S "$IFACE" | grep -Ei 'drop|miss|err|fifo'
ss -tin
lscpu