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 後，核心、socket 緩衝區與應用程式也可能丟包。先以 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 筆交易/秒，未累積延遲。問題路徑上也有 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 倍。這不是對所有程式的保證，也不能證明差距單由 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 無法確認 hypervisor 的 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