«Данные Solana поступают медленно или не полностью?» Что проверить в инфраструктуре приёма
Вы подписались на быстрый поток Solana Shreds, но пакеты поступают лишь понемногу. Полученные Shreds корректно разбираются, но из-за нехватки слишком большого числа фрагментов извлечь транзакции не удаётся. На том же сервере gRPC работает, и непонятно, где искать дальше.
Проверяя отправителя, обратите внимание и на сервер вашего приложения, а также на дата-центр, в котором он размещён. Даже если ERPC быстро пересылает Shreds, ограничения UDP на маршруте или узкие места обработки на принимающем сервере могут не позволить приложению воспользоваться этой скоростью.
Выбирая поток Shreds, нужно учитывать весь путь: как пакеты поступают и как они превращаются в пригодные для использования данные. От качества сети, расстояния и эксплуатационных политик дата-центров также зависит производительность Geyser Yellowstone gRPC, обычного обмена по RPC и API и отправки транзакций.
Записи на стороне отправителя и пригодные для использования полученные данные свидетельствуют о разном
В одном из недавних обращений в поддержку ERPC кратковременные измерения на стороне отправителя показали примерно 3 400–3 900 пакетов/с. Получатель сообщил примерно о 13 пакетах/с и об отсутствии полностью восстановленных слотов.
Эти показатели относятся к разным периодам измерения, и сопоставимость методов измерения не подтверждена. Поэтому по ним нельзя определить долю успешных доставок или долю потерь. Одни лишь записи на стороне отправителя не доказывают, что пакеты дошли, а точная причина на момент написания статьи остаётся неустановленной.
Несколько тысяч PPS сами по себе также не означают необычно высокой нагрузки для сервера общего назначения. Нужно выяснить, что происходит на фактическом маршруте, какие ограничения действуют, как трафик концентрируется в коротких интервалах, как организован приём и что измеряет каждый счётчик.
Один и тот же Франкфурт, разные сетевые маршруты
Источник потока и сервер вашего приложения могут находиться во Франкфурте, но при этом размещаться в разных дата-центрах. При такой конфигурации трафик может покинуть одну площадку, пройти через внешнюю сеть и попасть на другую. Одинаковое обозначение региона не означает, что речь идёт об одной площадке, одном сетевом операторе или одном и том же наборе промежуточных устройств.
Когда потоки или RPC-сервисы ERPC и сервер VPS или Bare Metal от ERPC размещены на одной площадке, серверы сервисов и сервер приложения находятся в соседних стойках, а обмен между ними остаётся во внутренней сети. В этом заключается идея Zero-Distance Communication ERPC: совместно проектировать физическое размещение и маршрут до принимающего приложения, выходя за рамки выбора одного города.
Отказ от обходного пути через внешнюю сеть между сервисами ERPC и сервером приложения сокращает маршрут и уменьшает на этом участке подверженность перегрузкам и изменениям маршрутов во внешних сетях. Короткий путь в сочетании с ресурсами, необходимыми для приёма и обработки, создаёт основу для использования преимуществ быстрого потока. Проверяйте результат и на этапе поступления пакетов, и при обработке приложением.
Состояние сети влияет на все виды обмена данными
В случае Shreds недостающие фрагменты делают проблему заметной, но качество той же инфраструктуры влияет на приём данных, запросы API и отправку транзакций в целом. От протокола зависят симптомы, которые видит приложение, и точки, в которых стоит проводить измерения.
| Тип обмена | Где проявляется влияние сети | Что проверять в приложении |
|---|---|---|
| Shreds / UDP | Потери и задержки пакетов, а также поступление фрагментов, необходимых для восстановления | Валидные Shreds и время до возможности восстановить данные |
| Geyser Yellowstone gRPC | Ожидание повторных передач TCP, накопление данных в потоке и задержки | Время до получения и обработки одного и того же обновления |
| RPC, API и обмен между сервисами | Время прохождения запросов и ответов туда и обратно, а также ожидание при перегрузке | Время ответа и его колебания |
| Отправка транзакций | Маршрут запроса до принимающего узла | Время от запроса на отправку до ответа узла |
Близкое размещение и подходящие эксплуатационные политики помогают обслуживать весь этот трафик. Измеряйте время ответа принимающего узла отдельно от времени до включения и финализации транзакции в блокчейне.
Одних Gbps недостаточно для оценки PPS и всплесков трафика
Пропускная способность описывает объём данных, который можно передать за определённое время. PPS показывает число пакетов, обрабатываемых за секунду. У соединения может оставаться запас пропускной способности, но при этом оно может упираться в ограничение числа пакетов в секунду или в ограничение, применяемое к UDP. В документации самих облачных провайдеров лимиты пропускной способности и PPS рассматриваются как отдельные ограничения.[1]
Shreds не обязательно поступают с равномерной частотой. Кратковременный всплеск может создать нагрузку на очереди, которую не видно по средним значениям. Если пакеты накапливаются быстрее, чем сетевое устройство или получатель успевает их обрабатывать, пакеты сверх ёмкости очереди могут быть отброшены.[2]
Уточните у своего хостинг-провайдера условия длительного приёма UDP и кратковременных всплесков трафика, лимиты PPS и правила, применяемые защитой от DDoS. Цель состоит в том, чтобы создать условия для безопасного пропуска необходимого трафика, а не отключать защиту без разбора.
Работающий gRPC не доказывает, что приём UDP работает корректно
gRPC на базе TCP и необработанные Shreds по UDP используют разные механизмы транспорта. TCP обеспечивает повторную передачу и соблюдение порядка доставки, а потоковый gRPC имеет механизм управления потоком с учётом возможностей получателя. Сам UDP не пересылает повторно пропущенные пакеты и не заставляет отправителя ждать, пока принимающее приложение обработает накопившиеся данные.[3]
Поэтому работа gRPC на сервере не доказывает, что маршрут UDP или получатель работают правильно. Фильтры для конкретного протокола, порты, маршруты доставки и реализации приёмника нужно проверять отдельно. Задержки обработки gRPC также могут проявляться в виде ожидания или разрывов соединения.
Транзакции/с в gRPC и пакеты/с в UDP отражают разные единицы измерения на разных этапах обработки. Их нельзя напрямую сравнивать для расчёта объёма доставленных данных или доли потерь.
От поступивших пакетов к пригодным для использования данным
При использовании стандартного приёмника на UDP-сокете входящие пакеты проходят через сетевую карту (NIC), ядро и приёмный буфер сокета, прежде чем попасть в приложение. Если обработка отстаёт, пакеты могут быть отброшены уже после того, как достигли хоста. Счётчики приёма интерфейсов Linux учитывают и пакеты, отброшенные на последующих этапах, поэтому само по себе увеличение счётчика приёма не доказывает доставку в приложение.[4]
Отдельная очередь приёма или ядро CPU могут быть загружены, даже если общая загрузка CPU низкая. Проверьте очереди NIC, распределение прерываний и производительность одного ядра. В приложении по мере необходимости отделите приём от последующей работы, вынеся ресурсоёмкий разбор данных и чрезмерное логирование из цикла приёма. Увеличенный приёмный буфер может поглощать временные всплески, но не устраняет постоянный недостаток производительности обработки.[5]
Shreds представляют собой фрагменты данных блока. Прямая коррекция ошибок (FEC) позволяет восстанавливать недостающие данные с помощью Shreds данных и Shreds кодирования из одной группы, но для восстановления всё равно нужно достаточное количество фрагментов. Дополнительные дубликаты пакетов не заменяют недостающие фрагменты.[6]
В зависимости от реализации приёмник может восстанавливать записи из доступных фрагментов ещё до того, как слот будет собран целиком.[9] Наряду с общим числом пакетов отслеживайте уникальные валидные Shreds, восстановленные данные и время до того, как приложение распознает нужное ему событие.
Измеряйте каждый этап в одном и том же временном интервале
Согласуйте адрес назначения, порт и окно измерения на обеих сторонах. Раздельная фиксация следующих этапов помогает сузить дальнейший поиск.
| Точка измерения | Что фиксировать | Что это позволяет установить |
|---|---|---|
| Отправитель | Записи для целевого адреса назначения и описание того, что измеряет счётчик | Какой этап отправки наблюдался |
| Точка входа принимающего хоста | Захват целевого UDP-трафика, статистика NIC и потери при захвате | Какой объём трафика был виден в этой точке наблюдения |
| ОС и сокет | Ошибки UDP, потери в приёмном буфере и изменения очередей | Скапливаются ли данные в очередях приёма внутри хоста |
| Восстановление Shreds | Уникальные валидные Shreds, успешное восстановление, недостающие данные и ошибки | Позволяют ли пакеты получить необходимые данные |
| Приложение | Накопившаяся очередь обработки и временные метки обнаружения одного и того же события | Передаётся ли преимущество скорости поступления приложению |
Если захват показывает мало пакетов, сначала проверьте его фильтр, наблюдаемый интерфейс, потери при захвате и отбрасывание пакетов на NIC. Некоторые счётчики ОС охватывают весь хост или сетевое пространство имён; проверьте их область действия и сопоставьте с измерениями целевого приложения.[4][5]
Меняйте настройки после того, как определите этап, на котором возникает ограничение. Одно лишь увеличение буфера или кольца может переместить узкое место либо добавить время ожидания. Актуальная конфигурация приёмника ERPC и необходимые проверки описаны здесь:
Выбирайте и сервер, и эксплуатационную политику
Solana Foundation объясняет важность контроля над NIC, физическими ядрами, драйверами и сетью для высокопроизводительных валидаторов. Эти требования к полноценному валидатору не следует целиком переносить на каждый приёмник Shreds. Принимающему приложению нужна конфигурация, соответствующая его собственному потоку и нагрузке обработки.[7]
Снижение затрат или энергопотребления является разумной целью эксплуатации. Приложениям HFT и реального времени также нужны быстрый отклик CPU, устойчивая производительность обработки и короткое ожидание в сети. Выход из энергосберегающего состояния может потребовать компромисса в отношении задержки.[8]
Наряду с моделями CPU и количеством ядер проверяйте, как организовано совместное использование ресурсов, как обслуживается длительная нагрузка, какие условия действуют для UDP-трафика и каков фактический сетевой маршрут.
ERPC рассматривает поток и среду приёма вместе
ERPC занимается выбором дата-центров рядом с инфраструктурой Solana, сетевыми маршрутами, аппаратным обеспечением и эксплуатационными настройками, предоставляя VPS и Bare Metal наряду с Shreds и gRPC. Вы можете подобрать VPS под свою нагрузку обработки и сравнить его с Bare Metal, если нужны выделенные физические ресурсы.
Понимание конфигурации и эксплуатации предоставляемых нами сред также помогает в технической диагностике. Мы можем сопоставить записи отправителя с измерениями получателя и определить конкретные проверки для сети, ОС или приложения. В описанном обращении мы проверили измерения на стороне отправителя и запросили дополнительные измерения у получателя.
Совместная оценка потока, размещения приёмника и реализации приложения упрощает поиск того, чего не хватает между выбранным сервисом и нужными вам данными.
Используйте почасовую оплату для сравнения с текущей средой
Если вы не уверены в своей среде приёма, попробуйте VPS или сервер Bare Metal ERPC с почасовой оплатой и сравните результаты на одном и том же потоке и приложении. В панели управления проверьте актуальные цены, наличие и условия заказа в нужном вам регионе.
Начните с доступной конфигурации и фиксируйте число принятых пакетов, восстановленные данные, накопившуюся очередь обработки и временные метки обнаружения одних и тех же событий. Сравнивая временные метки между хостами, также проверяйте точность синхронизации часов. Повторяйте тест в разное время и сравнивайте, в каких точках пути результаты различаются. Используйте эти измерения, чтобы выбрать сервер и дата-центр, подходящие вашему приложению.
- VPS: https://erpc.global/ru/vps/
- Bare Metal: https://erpc.global/ru/baremetal/
- Панель управления: https://dashboard.erpc.global/ru/
Связанные статьи
- Solana Stream SDK v4.0.0: https://erpc.global/ru/news/2026/11/07/erpc-solana-stream-sdk-v4-20261107/
- [9] Shreds UDP Forwarding Premium: https://erpc.global/ru/news/2026/11/03/erpc-shreds-udp-forwarding-premium-20261103/
- Официальный Discord Validators DAO: https://discord.gg/C7ZQSrCkYR
Технические источники
- [1] Лимиты пропускной способности и PPS в AWS EC2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html
- [2] Рекомендации IETF по использованию UDP, кратковременные всплески: https://www.rfc-editor.org/rfc/rfc8085.html#section-3.1.6
- [3] UDP в Linux: https://man7.org/linux/man-pages/man7/udp.7.html
- [3] TCP в Linux: https://man7.org/linux/man-pages/man7/tcp.7.html
- [3] Управление потоком в gRPC: https://grpc.io/docs/guides/flow-control/
- [4] Статистика сетевых интерфейсов Linux: https://docs.kernel.org/networking/statistics.html
- [4] Особенности захвата и потери в libpcap: https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.linux
- [5] Масштабирование сетевого стека Linux: https://docs.kernel.org/networking/scaling.html
- [5] Приёмные буферы сокетов Linux: https://man7.org/linux/man-pages/man7/socket.7.html
- [5] Red Hat, диагностика потерь UDP: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/tuning-udp-connections
- [6] Anza, распространение блоков через Turbine: https://docs.anza.xyz/consensus/turbine-block-propagation/
- [7] Solana Foundation, оборудование для высокопроизводительных валидаторов: https://solana.com/news/high-performance-solana-validators-run-on-bare-metal-hardware
- [8] Управление временем простоя CPU в Linux: https://docs.kernel.org/admin-guide/pm/cpuidle.html
