Solana VPS e Bare Metal: CPU, UDP e testes de rede | ERPC

Por que o servidor importa tanto quanto o stream Solana

Um stream rápido não garante dados utilizáveis em tempo real. CPU com baixa utilização e uma porta anunciada de 1 Gbps não explicam tudo. É preciso medir o percurso completo entre a fonte e a aplicação. Reunimos observações anônimas e testes independentes, sem culpar fornecedores por incidentes sem causa confirmada.

Solana combina velocidade e grande volume de dados

Shreds e Yellowstone Geyser gRPC podem transmitir continuamente e em rajadas. Banda, pacotes por segundo (PPS), RTT, jitter, perdas e tempo de processamento são métricas diferentes. A 4 MB/s por 30 dias, o volume hipotético é 10,4 TB, mas a média é só 32 Mbps. Isso não prova que uma porta de 1 Gbps seja insuficiente. Verifique limites UDP, rajadas, uplinks compartilhados e o receptor.

O stream funciona, mas faltam dados

Em uma investigação anônima, o emissor observou cerca de 3.400–3.900 pacotes UDP/s e, em outro momento, o receptor relatou aproximadamente 13 pacotes/s. Os Shreds recebidos eram válidos, porém insuficientes para reconstrução. gRPC funcionava no mesmo host. As observações são de tempos e locais distintos: não demonstram percentual de perda nem uma causa específica. Alguns milhares de PPS não são intrinsecamente excessivos.

Localize onde os pacotes desaparecem

Políticas de rede, proteção DDoS ou o hipervisor podem limitar UDP antes da máquina virtual. Após a NIC, kernel, buffers de socket e aplicação também podem perder pacotes. Capture primeiro com tcpdump, depois inspecione contadores da NIC, erros UDP e filas. XDP pode descartar antes de tcpdump. Compare emissor e receptor nas mesmas janelas e evite atribuições precipitadas.

A mesma cidade não significa o menor caminho

Dois servidores em Frankfurt podem usar instalações e redes distintas, com trânsito externo. De um mesmo host foram medidos cerca de 11 ms e 23 ms de RTT para endpoints próximos em Amsterdam, separados entre si por aproximadamente 0,1 ms. Em outra janela, o upstream teve 5–8% de perdas e cerca de 5 ms extras. Os resultados são específicos daquele caminho, não de todos os provedores.

Execute perto da fonte de dados

Normalmente, o provedor RPC e a hospedagem vendem partes separadas. A ERPC projeta Shreds, Geyser gRPC, RPC, VPS e Bare Metal em conjunto. Em locais suportados, a fonte e a aplicação podem usar caminhos locais entre racks próximos, evitando desvios externos desnecessários. Zero-Distance Communication não promete distância ou latência literalmente nula. Meça a rota real.

Compare o que chegou à aplicação

Uma assinatura Geyser gRPC comparável para o mesmo endpoint de Amsterdam mostrou 3,7–4,2 MiB/s em hospedagem externa com lag crescente. Um teste independente em VPS ERPC Frankfurt, limitado a um core, registrou 9,396 MiB/s e cerca de 1.910 transações/s por 60 s sem acumular lag. Houve retransmissões TCP no caminho problemático. Hosts e clientes eram diferentes, portanto não é A/B controlado. Outro teste HTTP/2 mediu 2,7 MB/s com janela de 16 KiB e até 7,1 MB/s com janela maior.

O modelo da CPU esconde limitações

VMs com a mesma geração de CPU e vCPUs podem ter políticas diferentes de boost, energia, temperatura e agendamento. AMD Core Performance Boost e Intel Turbo Boost podem ser desativados no host ou BIOS. Mesmo ativados, não garantem frequência máxima contínua. A máquina virtual pode não expor essa política. Meça desempenho sustentado sob a carga real.

Quatro vCPUs e diferença medida de 1,93×

No benchmark publicado pela ERPC com AMD Turin, quatro vCPUs e Ubuntu 24.04 em Amsterdam, sysbench CPU registrou 7.850 contra 4.062 eventos/s: cerca de 1,93× naquele teste. Também foram relatadas diferenças de aproximadamente 3,2× em banda de memória e 16,6× em IOPS de leitura aleatória 4K. Não é garantia universal nem prova de que apenas o boost causou a diferença.

A economia do data center afeta desempenho

Energia, refrigeração, racks, switches, links e operação têm custo. Compartilhar recursos é racional para aplicações usuais. Streams Solana e cargas de baixa latência podem exigir CPU, PPS e rede sustentados. Banda compartilhada, limites por fluxo, proteção DDoS e economia de energia podem ser adequados a outros usos. O essencial é verificar se as políticas servem à aplicação.

Inclua o custo da transferência em nuvem

Streams contínuos acumulam terabytes. A entrada de Internet costuma ser gratuita em algumas nuvens, mas saída, zonas e transferências entre serviços podem ser cobradas. Produtos ERPC elegíveis distinguem tráfego interno da plataforma de cotas externas, conforme o plano atual. Avalie o custo do caminho inteiro, não só a mensalidade da VM.

Escolha a infraestrutura pelo trabalho

Um EPYC VPS pode servir RPC leve; análise gRPC contínua exige CPU e memória suficientes. Shreds UDP e aplicações de baixa latência precisam de política UDP adequada, PPS, tolerância a rajadas e detecção rápida. Bare Metal oferece recursos físicos exclusivos, mas não é automaticamente mais veloz em tudo. Dividir cargas entre VPS também pode ser bom. Compare software, filtros e janelas iguais, Shreds válidos, reconstrução, lag, retransmissões e latência p95/p99.

Meça antes de contratar

No Linux, tcpdump, nstat, ip -s link, ethtool -S, ss -tin e lscpu permitem verificações iniciais sem mudar configurações. Substitua IP e interface e compare contadores ao longo do tempo. lscpu não comprova a política de boost do hipervisor. A ERPC oferece cobrança por hora para configurações VPS e Bare Metal elegíveis, conforme disponibilidade. O servidor certo entrega dados utilizáveis dentro do prazo exigido.

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