Операційні вимоги для «Як аналізувати skip rate валідатора» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Skip rate — це пряма міра того, наскільки надійно ваш валідатор виконує лідерські слоти. Кожен пропущений слот означає втрачені комісії, зниження кредитного рейтингу (vote credits) і ризик переходу в статус delinquent. Цей матеріал дає покрокову методологію аналізу skip rate: від розуміння механіки до конкретних команд діагностики та оптимізації.
Середовище перевірки: клієнт Agave (гілка validator), кластер mainnet-beta, ОС Ubuntu 24.04 LTS. Команди та шляхи до журналів можуть відрізнятися на інших дистрибутивах — перевірте відповідність вашому розгортанню.
Що таке skip rate та як він розраховується
Skip rate — це відсоток лідерських слотів, у яких валідатор не зміг згенерувати та транслювати блок. У Solana час лідера триває приблизно 400 мс на слот. Якщо за цей час блок не сформовано, слот вважається пропущеним.
Формула розрахунку:
skip_rate = (skipped_slots / total_leader_slots) × 100%
Де:
- total_leader_slots — загальна кількість слотів, призначених вашому валідатору в розглянутому вікні (зазвичай за останні епохи).
- skipped_slots — кількість цих слотів, де блок не було створено.
Важливо розрізняти skip rate за одну епоху та усереднений за кілька епох. Одиничний сплеск може бути викликаний тимповою проблемою (наприклад, перезавантаженням), тоді як стабільно високий skip rate вказує на системну інфраструктурну проблему.
Допустимі та критичні значення skip rate
У спільноті операторів сформувалися такі орієнтовні межі (не є офіційним протокольним стандартом — перевірте актуальні рекомендації для вашого кластера):
| Діапазон skip rate | Інтерпретація | Дія |
|---|---|---|
| 0–3% | Нормальний робочий рівень. Ізольовані пропуски неминучі через мережеві коливання. | Стандартний моніторинг. |
| 3–10% | Увага. Є періодичні збої під час лідерства. | Запустіть діагностику, корелюйте з метриками. |
| 10–25% | Критично. Значна частина комісій втрачається, кредитний рейтинг падає. | Негайна діагностика та виправлення. |
| >25% | Аварійний стан. Висока ймовірність переходу в delinquent. | Негайне втручання, див. розділ про аварійне відновлення. |
Ці значення варто адаптувати до вашого апаратного профілю. Валідатор на мінімальних специфікаціях може мати стабільно вищий skip rate, ніж потужна машина, навіть за ідеальної мережі.
Інструменти для перевірки skip rate
1. CLI-команда block-production
Основний інструмент для швидкої перевірки:
solana block-production --url https://api.mainnet-beta.solana.com
Очікуваний результат — таблиця з вашою ідентичністю, кількістю слотів, пропущених слотів та відсотком skip rate. Якщо ви запускаєте без вказання identity, команда покаже дані для всіх валідаторів — фільтруйте за своїм pubkey.
Для конкретного валідатора:
solana block-production --url https://api.mainnet-beta.solana.com --identity YOUR_VALIDATOR_PUBKEY
2. Команда validators
solana validators --url https://api.mainnet-beta.solana.com
Показує список валідаторів із їхнім skip rate, кредитним рейтингом та іншими параметрами. Корисно для порівняння вашого показника з медіаною по кластеру.
3. Журнали валідатора
Системний журнал (journalctl для systemd) містить записи про кожен пропущений слот із причиною:
journalctl -u solana --since "1 hour ago" --no-pager | grep -i "skip"
4. Лог-файл валідатора
Якщо ви логуєте у файл (наприклад, через agave-validator ... --log /mnt/ledger/validator.log), аналізуйте його аналогічно:
grep -i "skip" /mnt/ledger/validator.log | tail -50
Причини високого skip rate
Кожна причина має характерний слід у метриках та журналах. Нижче — чотири основні категорії.
CPU-бутleneck
Під час лідерства валідатор має обробити пул транзакцій, виконати їх у runtime, згенерувати блок і підписати його. Це CPU-інтенсивна робота. Якщо процесор не встигає, блок не формується в межах тайм-слоту.
Ознаки: завантаження CPU наближається до 100% під час лідерських слотів; у журналах з'являються повідомлення про затримки обробки транзакцій або пропуски слотів без мережевих помилок.
Дисковий I/O
Ledger (база даних рахунків) зберігається на диску. Читання стану рахунків та запис нових записів під час лідерства вимагають швидкого I/O. NVMe-накопичувачі здатні забезпечити необхідну пропускну здатність, тоді як SATA SSD або HDD створюють вузьке місце.
Ознаки: високі значення await (очікування I/O) у iostat; у журналах — повільні операції з accounts-db або slots-db.
Мережева latency
Навіть якщо блок сформовано вчасно, його треба транслювати достатній кількості пірів (peer-to-peer вузлів) до закінчення слоту. Висока latency до ключових пірів або обмежена пропускна здатність призводять до того, що блок не потрапляє до консенсусу.
Ознаки: у журналах — повідомлення про timeout при трансляції блоків, низька кількість пірів (solana gossip показує мало активних з'єднань).
Синхронізація ledger
Якщо валідатор відстає від верхівки кластера (не повністю синхронізований), він не має актуального стану для формування блоку у своєму слоті. Це окремий випадок, який часто передує переходу в delinquent.
Ознаки: solana slot показує відставання від solana block-height; у журналах — повідомлення про catchup або fork.
Покрокова діагностика високого skip rate
Ця процедура призначена для валідатора зі skip rate вище 5%. Виконуйте кроки послідовно.
Крок 1. Зафіксуйте поточний стан
Збережіть вихідні дані для порівняння:
solana block-production --url https://api.mainnet-beta.solana.com --identity YOUR_VALIDATOR_PUBKEY > /tmp/skip-rate-before.txt
solana slot > /tmp/slot-before.txt
Крок 2. Визначте часовий патерн пропусків
Витягніть список пропущених слотів із журналу за останні 4 епохи:
journalctl -u solana --since "4 hours ago" --no-pager | grep -i "skipping leader slot" | awk '{print $1, $2, $NF}' > /tmp/skipped-slots.txt
Проаналізуйте: чи є пропусків групами (вказує на періодичну проблему, наприклад, фоновий процес), чи розкидані (вказує на стохастичну проблему, наприклад, мережу).
Крок 3. Перевірте синхронізацію
solana catchup --our-identity YOUR_VALIDATOR_PUBKEY --url https://api.mainnet-beta.solana.com
Якщо валідатор не в catchup і слоти синхронізовані — причина не у відставанні. Якщо відстає — усуньте відставання перш ніж аналізувати інші причини.
Крок 4. Моніторинг CPU під час лідерства
Відкрийте окрему сесію та запустіть:
mpstat 1 > /tmp/cpu-during-leadership.txt &
Дочекайтеся кількох лідерських слотів (можна відстежити за журналом: journalctl -u solana -f | grep "leader slot"). Після цього перевірте /tmp/cpu-during-leadership.txt — чи перевищує %user або %sys позначку 80–90%.
Крок 5. Моніторинг дискового I/O під час лідерства
iostat -x 1 > /tmp/io-during-leadership.txt &
Аналогічно дочекайтеся лідерських слотів. Зверніть увагу на:
- %util — близько до 100% означає, що диск насичений.
- await — значення вище 10–20 мс для NVMe вказує на проблему.
- avgqu-sz — черга запитів, що росте, свідчить про бутleneck.
Крок 6. Перевірка мережі
Кількість активних пірів:
solana gossip --url https://api.mainnet-beta.solana.com | grep -c "Peer"
Менше 50–80 активних пірів може бути недостатньо для надійної трансляції. Також перевірте latency до кількох пірів:
ping -c 5 <IP_піра_1> <IP_піра_2> <IP_піра_3>
Latency вище 50–100 мс до значної частини пірів — ймовірна причина пропусків.
Крок 7. Аналіз журналів на конкретні помилки
Шукайте не лише "skip", а й супутні повідомлення:
journalctl -u solana --since "1 hour ago" --no-pager | grep -iE "timeout|error|fail|slow|stall|bank-frozen|fork"
Зв'яжіть знайдені помилки з часом пропущених слотів із кроку 2.
Оптимізація для зниження skip rate
Після виявлення вузького місця застосуйте відповідні заходи.
Якщо причина — CPU:
- Перевірте, чи не працюють на тій самій машині ресурсомісткі процеси (моніторинг, бекапи, компіляція). Перенесіть їх на окремий вузол.
- Перевірте налаштування frequency scaling у ОС:
cpupower frequency-set -g performanceфіксує максимальну частоту та усуває затримки підняття. - За можливості — апгрейд процесора на модель з вищою одноthread-продуктивністю (Solana runtime переважно однопотоковий).
Якщо причина — дисковий I/O:
- Переконайтеся, що ledger та accounts-db розміщені на NVMe, а не на HDD або SATA SSD.
- Перевірте, що жоден інший процес не створює навантаження на цей диск (логи валідатора краще виводити на окремий накопичувач або в journalctl).
- За необхідності — перейдіть на NVMe з вищою послідовною записною швидкістю та нижчою latency.
Якщо причина — мережа:
- Збільште кількість inbound/outbound з'єднань: перевірте налаштування фаєрвола та
--known-validatorпрапорці запуску. - Переконайтеся, що порт 8000–8010 (UDP і TCP) відкритий для вхідних з'єднань.
- Використовуйте сервер у дата-центрі з хорошим пірингом, де розгорнуто інші валідатори Solana.
- Уникайте NAT та тунелів — пряме підключення зменшує latency.
Якщо причина — синхронізація ledger:
- Переконайтеся, що у вас достатньо вільного місця на диску ledger (запас мінімум 20–30% від об'єму).
- Перевірте, чи не обмежена пропускна здатність інтернет-каналу під час catchup.
- Якщо відставання критичне, розгляньте використання знімка (snapshot) від надійного джерела для швидкого відновлення замість повної синхронізації з genesis.
Загальні рекомендації:
- Не змінюйте конфігурацію валідатора під час активного лідерства. Застосовуйте зміни в паузах між слотами або під час планового обслуговування.
- Після кожної зміни зафіксуйте новий skip rate за 2–4 епохи та порівняйте з базовим значенням із кроку 1.
- Автоматизуйте моніторинг skip rate: якщо він перевищує ваш поріг, система має сповіщати оператора до того, як проблема призведе до delinquent.
Систематичний аналіз skip rate — це не разова дія, а постійна операційна практика. Регулярна кореляція пропусків із метриками CPU, I/O та мережі дозволяє виявляти деградацію до того, як вона стане критичною.