Solana VPS và Bare Metal: đo CPU, UDP, mạng | ERPC

Máy chủ quan trọng không kém luồng dữ liệu Solana

Luồng Solana nhanh không đảm bảo ứng dụng nhận được dữ liệu đúng lúc. CPU ít sử dụng và cổng mạng được quảng cáo 1 Gbps chưa nói lên mọi chuyện. Cần đo toàn bộ đường đi từ nguồn đến dữ liệu có thể dùng. Bài viết tổng hợp điều tra đã ẩn danh, thử nghiệm độc lập và benchmark công khai, không quy trách nhiệm cho nhà cung cấp khi chưa rõ nguyên nhân.

Solana nhanh đồng thời tạo ra nhiều gói tin

Shreds và Yellowstone Geyser gRPC truyền dữ liệu liên tục, đôi khi theo đợt ngắn. Băng thông, gói tin mỗi giây (PPS), RTT, jitter, mất gói và thời gian xử lý là các đại lượng khác nhau. Ví dụ 4 MB/s trong 30 ngày tương đương khoảng 10,4 TB nhưng trung bình chỉ 32 Mbps. Điều đó không chứng minh cổng 1 Gbps thiếu. Cần kiểm tra giới hạn UDP, lưu lượng bùng nổ, uplink dùng chung và bộ nhận.

Luồng hoạt động nhưng dữ liệu vẫn không đủ

Một vụ kiểm tra ẩn danh ghi nhận phía gửi khoảng 3.400–3.900 gói UDP/giây và phía nhận báo khoảng 13 gói/giây ở thời điểm khác. Những Shreds nhận được hợp lệ nhưng không đủ để tái dựng dữ liệu. gRPC vẫn hoạt động trên cùng máy. Hai lần đo khác thời gian và vị trí, không thể tính tỷ lệ mất chính xác hay xác định nguyên nhân. Vài nghìn PPS tự nó không phải tải bất thường cho mọi máy chủ.

Xác định điểm đo trước khi thay máy

Chính sách mạng, chống DDoS hoặc máy chủ ảo hóa có thể giới hạn UDP trước khi vào VM. Sau NIC, kernel, bộ đệm socket và ứng dụng cũng có thể bỏ gói. Hãy bắt gói bằng tcpdump tại giao diện nhận, rồi xem bộ đếm NIC, lỗi UDP và hàng đợi. XDP có thể bỏ gói trước khi tcpdump thấy. So sánh cùng cổng, đích và khoảng thời gian.

Cùng thành phố vẫn có thể đi đường vòng

Hai máy tại Frankfurt có thể thuộc các trung tâm và mạng khác nhau, qua transit bên ngoài. Từ một máy ngoài, RTT đến hai endpoint Amsterdam cách nhau khoảng 0,1 ms lại lần lượt là 11 ms và 23 ms. Ở khoảng thời gian khác, tuyến upstream có mất gói 5–8% và tăng khoảng 5 ms trễ. Những số này thuộc tuyến cụ thể, không đại diện mọi nhà cung cấp.

Đưa ứng dụng lại gần nguồn dữ liệu

Thông thường nhà cung cấp RPC bán dữ liệu và công ty hosting bán máy chủ. ERPC thiết kế Shreds, Geyser gRPC, RPC, VPS và Bare Metal cùng nhau. Ở địa điểm được hỗ trợ, nguồn và ứng dụng có thể kết nối qua mạng nội bộ giữa các rack gần nhau để giảm đi vòng ngoài không cần thiết. Zero-Distance Communication không có nghĩa khoảng cách hay trễ bằng không theo nghĩa đen. Phải đo đường đi thật.

Đo dữ liệu thực sự tới ứng dụng

Với đăng ký Geyser gRPC tương đương đến cùng endpoint Amsterdam, một môi trường hosting ngoài nhận 3,7–4,2 MiB/s và lag tiếp tục tăng. Thử nghiệm độc lập trên ERPC VPS Frankfurt giới hạn một lõi đạt trung bình 9,396 MiB/s và khoảng 1.910 giao dịch/giây trong 60 giây, không tích lũy lag. Có TCP retransmission trên đường gặp vấn đề. Host và client khác nhau nên không phải A/B kiểm soát nghiêm ngặt. Thử nghiệm HTTP/2 khác ghi nhận 2,7 MB/s với cửa sổ 16 KiB và tối đa 7,1 MB/s khi tăng cửa sổ.

Tên CPU không cho biết giới hạn thực tế

VM có cùng thế hệ CPU và số vCPU có thể dùng chính sách boost, điện, tản nhiệt và scheduling khác nhau. AMD Core Performance Boost và Intel Turbo Boost có thể tắt trong BIOS hoặc host. Kể cả bật, không đảm bảo luôn đạt xung tối đa. VM khách có thể không nhìn thấy cấu hình host. Hãy đo hiệu năng bền vững trong tải thực tế.

Bốn vCPU, chênh lệch 1,93 lần trong benchmark

Benchmark ERPC công khai tại Amsterdam với AMD Turin bốn vCPU, Ubuntu 24.04 ghi 7.850 so với 4.062 events/s trong sysbench CPU, tương đương khoảng 1,93× trong phép thử này. Công bố cũng nêu khoảng 3,2× băng thông bộ nhớ và 16,6× IOPS đọc ngẫu nhiên 4K. Không thể suy ra mọi ứng dụng nhanh hơn như vậy hay chỉ do CPU Boost.

Kinh tế trung tâm dữ liệu ảnh hưởng chính sách

Điện, làm mát, rack, switch, kết nối và vận hành đều tốn phí. Chia sẻ tài nguyên hợp lý cho ứng dụng thông thường. Luồng Solana lớn có thể liên tục cần CPU, PPS và uplink. Băng thông dùng chung, giới hạn theo luồng, DDoS protection và tiết kiệm điện có thể phù hợp trường hợp khác. Vấn đề là mức độ phù hợp với tải, không phải chỉ trích nhà cung cấp.

Cần tính thêm phí truyền dữ liệu cloud

Luồng liên tục tích lũy hàng TB theo thời gian. Một số cloud miễn phí lưu lượng Internet vào nhưng tính phí lưu lượng ra, giữa các zone và dịch vụ. Sản phẩm ERPC đủ điều kiện tách lưu lượng nội bộ với hạn mức bên ngoài theo điều khoản hiện hành. Hãy so sánh chi phí cả tuyến dữ liệu chứ không chỉ giá VM.

Chọn VPS hoặc Bare Metal theo nhu cầu

RPC nhẹ có thể dùng EPYC VPS; phân tích gRPC liên tục cần đủ CPU và RAM. Shreds UDP và trading nhạy độ trễ cần chính sách UDP, PPS, xử lý burst, vị trí gần và thời gian phát hiện tốt. Bare Metal có tài nguyên vật lý độc quyền nhưng không tự động nhanh hơn mọi VPS. Chia tải qua nhiều VPS đôi khi hợp lý. Đo cùng phần mềm, bộ lọc, thời gian, Shreds hợp lệ, dữ liệu tái dựng, lag, TCP retransmission và p95/p99.

Đo trước khi ký dài hạn

Trên Linux, tcpdump, nstat, ip -s link, ethtool -S, ss -tin và lscpu giúp kiểm tra ban đầu mà không sửa cấu hình. Thay IP và giao diện ví dụ, so sánh mức tăng bộ đếm. Chỉ lscpu không chứng minh chính sách boost của hypervisor. ERPC cung cấp trả theo giờ cho VPS/Bare Metal đủ điều kiện theo tồn kho. Chọn máy đưa dữ liệu dùng được đến đúng hạn.

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