“Os dados da Solana estão lentos ou incompletos?” O que verificar na infraestrutura de recepção
Você contrata um stream rápido de Shreds da Solana, mas recebe apenas alguns poucos pacotes. Os Shreds recebidos são decodificados corretamente, porém faltam fragmentos demais para extrair as transações. O gRPC funciona no mesmo servidor, e você não sabe por onde continuar a investigação.
Além de verificar o remetente, examine o servidor da sua aplicação e o data center onde ele está hospedado. Mesmo quando a ERPC encaminha os Shreds rapidamente, restrições de UDP no caminho ou gargalos de processamento no servidor receptor podem impedir que a aplicação aproveite essa velocidade.
Escolher um stream de Shreds exige considerar todo o percurso: como os pacotes chegam e como se tornam dados utilizáveis. A qualidade da rede, a distância e as políticas de operação do data center também são condições de desempenho comuns ao Geyser Yellowstone gRPC, ao tráfego comum de RPC e APIs e ao envio de transações.
Os registros de envio e os dados recebidos utilizáveis são fatos distintos
Em uma consulta recente ao suporte da ERPC, medições breves no lado do remetente registraram aproximadamente 3.400–3.900 pacotes/s. O receptor informou aproximadamente 13 pacotes/s e nenhuma reconstrução de slot concluída.
Esses números vêm de períodos de medição diferentes, e ainda não foi confirmado se os métodos de medição são comparáveis. Portanto, eles não permitem estabelecer uma taxa de entrega bem-sucedida nem uma taxa de perda. Os registros do remetente, por si só, não comprovam a chegada dos pacotes, e a causa final continua indeterminada no momento da redação.
Alguns milhares de PPS também não demonstram, por si só, uma carga excepcionalmente alta para um servidor de uso geral. É preciso verificar o que acontece no caminho real, quais limites se aplicam, como o tráfego se concentra em intervalos curtos, como a recepção é processada e o que cada contador mede.
A mesma Frankfurt. Caminhos de rede diferentes.
A origem do stream e o servidor da aplicação podem estar em Frankfurt e, ainda assim, ocupar data centers diferentes. Nessa configuração, o tráfego pode sair de uma instalação, atravessar uma rede externa e entrar na outra. A mesma identificação de região não comprova que os servidores compartilham a instalação, o operador de rede ou os equipamentos intermediários.
Ao combinar streams ou serviços RPC da ERPC com um host ERPC VPS ou Bare Metal no mesmo local, os servidores do serviço e o servidor da aplicação ficam em racks próximos, e a comunicação entre eles permanece na rede interna. Essa é a ideia da comunicação de distância zero da ERPC, ou Zero-Distance Communication: projetar em conjunto a localização física e o caminho até a aplicação receptora, indo além da escolha da mesma cidade.
Evitar um desvio externo entre os serviços ERPC e o servidor da aplicação encurta o caminho e reduz, nesse trecho, a exposição ao congestionamento e às mudanças de rota em redes externas. Um caminho curto, combinado com os recursos necessários para receber e processar os dados, cria a base para aproveitar um stream rápido. Verifique o resultado tanto na chegada dos pacotes quanto no processamento da aplicação.
As condições da rede afetam todos os tipos de comunicação
Os fragmentos ausentes tornam o problema visível nos Shreds, mas a qualidade dessa mesma infraestrutura afeta de forma mais ampla a recepção de dados, as requisições a APIs e o envio de transações. O protocolo altera os sintomas observados pela aplicação e os pontos que vale a pena medir.
| Comunicação | Onde aparecem os efeitos da rede | O que verificar na aplicação |
|---|---|---|
| Shreds / UDP | Perda e atraso de pacotes e chegada dos fragmentos necessários à reconstrução | Shreds válidos e tempo até que os dados possam ser reconstruídos |
| Geyser Yellowstone gRPC | Espera por retransmissões TCP, acúmulo no stream e atraso | Tempo até receber e processar a mesma atualização |
| RPC, APIs e tráfego entre serviços | Ida e volta das requisições e respostas e espera durante congestionamentos | Tempo de resposta e sua variação |
| Envio de transações | Caminho da requisição até o nó receptor | Tempo entre a requisição de envio e a resposta do nó |
A proximidade física e políticas de operação adequadas dão suporte a todo esse tráfego. Meça separadamente o tempo de resposta do nó receptor e o tempo até que a transação seja incluída e finalizada na blockchain.
Gbps não informa tudo sobre PPS e rajadas
A largura de banda descreve a quantidade de dados que pode ser transportada ao longo do tempo. PPS descreve o número de pacotes processados por segundo. Uma conexão pode ter largura de banda disponível e, ainda assim, atingir um limite de pacotes por segundo ou uma restrição aplicada ao UDP. A própria documentação dos provedores de nuvem trata os limites de largura de banda e PPS como restrições distintas.[1]
Os Shreds não chegam necessariamente a uma taxa uniforme. Uma rajada pode pressionar as filas de uma forma que a média oculta. Se os pacotes se acumularem mais rápido do que um equipamento de rede ou receptor consegue processá-los, aqueles que excederem a capacidade da fila poderão ser descartados.[2]
Pergunte ao seu provedor de hospedagem sobre a recepção contínua de UDP, rajadas curtas, limites de PPS e regras aplicadas pela proteção contra DDoS. O objetivo é estabelecer condições que permitam receber com segurança o tráfego necessário, em vez de desativar indiscriminadamente as proteções.
O funcionamento do gRPC não comprova o funcionamento da recepção UDP
O gRPC sobre TCP e os Shreds brutos sobre UDP usam mecanismos de transporte diferentes. O TCP oferece retransmissão e ordenação, enquanto o streaming gRPC conta com controle de fluxo que considera a capacidade do receptor. O UDP, por si só, não retransmite pacotes ausentes nem faz o remetente esperar que a aplicação receptora acompanhe o ritmo.[3]
Assim, o funcionamento do gRPC em um servidor não comprova que o caminho UDP ou o receptor esteja funcionando corretamente. Filtros específicos de cada protocolo, portas, caminhos de entrega e implementações de recepção precisam ser verificados separadamente. Atrasos no processamento gRPC também podem aparecer como tempo de espera ou desconexões.
Transactions/sec no gRPC e packets/sec no UDP medem unidades diferentes em etapas diferentes do processamento. Não é possível compará-los diretamente para calcular o volume entregue ou uma taxa de perda.
Da chegada dos pacotes aos dados utilizáveis
Em um receptor com socket UDP convencional, os pacotes que chegam passam pela NIC, pelo kernel e pelo buffer de recepção do socket antes de alcançar a aplicação. Se o processamento não acompanhar o ritmo, eles poderão ser descartados depois de chegar ao host. Os contadores de recepção das interfaces Linux incluem pacotes descartados em etapas posteriores, de modo que o aumento desse contador, por si só, não comprova a entrega à aplicação.[4]
Uma fila de recepção ou um núcleo de CPU específico pode ficar sobrecarregado mesmo quando a utilização total da CPU é baixa. Verifique as filas da NIC, a distribuição das interrupções e o desempenho por núcleo. Na aplicação, separe a recepção do trabalho posterior quando apropriado, mantendo análises custosas e registros excessivos de log fora do loop de recepção. Um buffer de recepção maior pode absorver rajadas temporárias, mas não resolve uma insuficiência contínua de capacidade de processamento.[5]
Shreds são fragmentos de dados de blocos. A correção antecipada de erros (FEC) permite recuperar dados ausentes usando data shreds e coding shreds do mesmo grupo, mas a reconstrução ainda exige fragmentos suficientes. Mais pacotes duplicados não substituem os fragmentos ausentes.[6]
Dependendo da implementação, um receptor pode reconstruir entradas a partir dos fragmentos disponíveis antes de o slot inteiro estar completo.[9] Além do total de pacotes, meça os Shreds válidos e únicos, os dados reconstruídos e o tempo até que a aplicação reconheça o evento de que precisa.
Meça cada etapa na mesma janela de tempo
Alinhe o destino, a porta e a janela de medição nos dois lados. Registrar separadamente as etapas a seguir ajuda a delimitar a próxima investigação.
| Ponto de medição | O que registrar | O que a medição permite estabelecer |
|---|---|---|
| Remetente | Registros relativos ao destino em questão e definição do contador | Qual etapa do envio foi observada |
| Entrada do host receptor | Captura do tráfego UDP em questão, estatísticas da NIC e perdas da própria captura | Quanto tráfego foi visível naquele ponto de observação |
| SO e socket | Erros UDP, descartes no buffer de recepção e mudanças nas filas | Se o processamento de recepção está se acumulando dentro do host |
| Reconstrução dos Shreds | Shreds válidos e únicos, reconstruções bem-sucedidas, dados ausentes e erros | Se os pacotes produzem os dados necessários |
| Aplicação | Trabalho acumulado e horários de detecção do mesmo evento | Se a velocidade de chegada é aproveitada pela aplicação |
Se uma captura mostrar poucos pacotes, verifique primeiro o filtro, a interface observada, as perdas da própria captura e os descartes na NIC. Alguns contadores do SO abrangem todo o host ou namespace de rede; confira seu escopo e relacione-os às medições da aplicação em questão.[4][5]
Altere as configurações depois de identificar a etapa limitada. Aumentar apenas um buffer ou anel pode deslocar o gargalo ou acrescentar tempo de espera. As configurações e verificações atuais de recepção da ERPC estão documentadas aqui:
Escolha a política de operação, além do servidor
A Solana Foundation explica a importância do controle sobre NICs, núcleos físicos, drivers e rede para validadores de alto desempenho. Esses requisitos de um validador completo não devem ser aplicados integralmente a todo receptor de Shreds. Uma aplicação receptora precisa de uma configuração adequada ao seu próprio stream e à sua carga de processamento.[7]
Reduzir custos ou o consumo de energia é um objetivo de operação razoável. Aplicações de HFT e em tempo real também precisam de resposta rápida da CPU, capacidade de processamento sustentada e pouca espera na rede. A saída de um estado de economia de energia pode envolver uma contrapartida em latência.[8]
Além dos modelos de CPU e da quantidade de núcleos, verifique como os recursos são compartilhados, como cargas sustentadas são tratadas, as condições para o tráfego UDP e o caminho real da rede.
A ERPC considera o stream e o ambiente receptor em conjunto
A ERPC trabalha na seleção de data centers próximos da infraestrutura Solana, nos caminhos de rede, no hardware e nas configurações operacionais, oferecendo VPS e Bare Metal junto com Shreds e gRPC. Você pode escolher um VPS de acordo com sua carga de processamento e comparar o Bare Metal quando quiser recursos físicos exclusivos.
Conhecer a configuração e a operação dos ambientes que fornecemos também contribui para o suporte técnico. Podemos comparar os registros do remetente com as medições do receptor e identificar verificações concretas para a rede, o SO ou a aplicação. Na consulta descrita aqui, verificamos as medições do lado do remetente e solicitamos medições adicionais ao receptor.
Avaliar em conjunto o stream, a localização do receptor e a implementação da aplicação facilita identificar o que falta entre o serviço escolhido e os dados de que você precisa.
Compare com seu ambiente atual usando cobrança por hora
Se tiver dúvidas sobre seu ambiente de recepção, experimente um VPS ou servidor Bare Metal da ERPC com cobrança por hora e compare o mesmo stream e a mesma aplicação. Consulte o painel para verificar os preços, a disponibilidade e as condições de contratação atuais na região de sua preferência.
Comece com uma configuração disponível e registre as contagens de recepção, os dados reconstruídos, o trabalho acumulado e os horários de detecção dos mesmos eventos. Ao comparar horários entre hosts, verifique também a precisão da sincronização dos relógios. Repita o teste em horários diferentes e compare em qual etapa do percurso os resultados divergem. Use essas medições para escolher um servidor e um data center adequados à sua aplicação.
- VPS: https://erpc.global/pt/vps/
- Bare Metal: https://erpc.global/pt/baremetal/
- Painel: https://dashboard.erpc.global/pt/
Artigos relacionados
- Solana Stream SDK v4.0.0: https://erpc.global/pt/news/2026/11/07/erpc-solana-stream-sdk-v4-20261107/
- [9] Shreds UDP Forwarding Premium: https://erpc.global/pt/news/2026/11/03/erpc-shreds-udp-forwarding-premium-20261103/
- Discord oficial da Validators DAO: https://discord.gg/C7ZQSrCkYR
Referências técnicas
- [1] AWS EC2, limites de largura de banda e PPS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html
- [2] IETF UDP Usage Guidelines, rajadas: https://www.rfc-editor.org/rfc/rfc8085.html#section-3.1.6
- [3] Linux UDP: https://man7.org/linux/man-pages/man7/udp.7.html
- [3] Linux TCP: https://man7.org/linux/man-pages/man7/tcp.7.html
- [3] Controle de fluxo do gRPC: https://grpc.io/docs/guides/flow-control/
- [4] Estatísticas de interfaces Linux: https://docs.kernel.org/networking/statistics.html
- [4] Comportamento de captura e perdas no libpcap: https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.linux
- [5] Distribuição do processamento na pilha de rede Linux: https://docs.kernel.org/networking/scaling.html
- [5] Buffers de recepção de sockets Linux: https://man7.org/linux/man-pages/man7/socket.7.html
- [5] Red Hat, investigação de descartes UDP: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/tuning-udp-connections
- [6] Anza Turbine Block Propagation: https://docs.anza.xyz/consensus/turbine-block-propagation/
- [7] Solana Foundation, hardware para validadores de alto desempenho: https://solana.com/news/high-performance-solana-validators-run-on-bare-metal-hardware
- [8] Gerenciamento do tempo ocioso da CPU no Linux: https://docs.kernel.org/admin-guide/pm/cpuidle.html
