Когда Linux-сервер начинает терять пакеты, медленно передавать данные или связь с ним становится нестабильной, первая ошибка — сразу лезть в логи приложения. На самом деле Linux предоставляет несколько слоёв сетевой статистики: стандартные счётчики интерфейса, счётчики по протоколам и метрики, специфичные для драйвера. Правильный порядок действий поможет быстро понять, где именно проблема: на физическом уровне, в драйвере, в очередях или выше по стеку.
В этой статье — практический алгоритм диагностики с помощью ip -s и ethtool, который сэкономит вам часы поиска.
Cтандартные счётчики
Первым делом посмотрите базовую статистику интерфейса. Команды:
В документации ядра ip -s -s link — это обычный интерфейс к стандартной статистике линка. Обратите внимание на:
- ошибки RX и TX;
- drops и overruns;
- счётчики, связанные с carrier.
Эти цифры дадут первое представление о том, есть ли потери на уровне интерфейса.
Определите драйвер
Многие аппаратные счётчики не видны в общей статистике. Чтобы добраться до них, нужно знать драйвер и прошивку. Команды:
Сохраните вывод — это часть записи об инциденте. Пригодится, если придётся обращаться к вендору или сравнивать поведение на разных машинах.
Посмотрите счётчики драйвера
Важно: не считайте, что каждый счётчик означает одно и то же у разных производителей NIC. Имена вроде missed packets, buffer exhaustion, CRC errors или queue drops нужно читать с оглядкой на документацию драйвера. Универсальной расшифровки нет.
Физические ошибки против перегрузки очередей
Это ключевой момент. Ошибки CRC и framing обычно указывают на проблемы с кабелем, оптикой, трансивером или согласованием линка. Дропы очередей — на то, что трафик приходит быстрее, чем приёмная очередь успевает его обработать.
Это разные классы отказов, и чинятся они по-разному. Замена кабеля не решит программное узкое место в приёмной очереди. И наоборот, тюнинг RSS не починит грязный оптический линк, который сыпет физическими ошибками.
Проверьте состояние линка и согласованную скорость
Убедитесь, что скорость и дуплекс согласованы, а линк в состоянии UP. Если у вас управляемая инфраструктура, сверьте счётчики на стороне хоста со счётчиками порта коммутатора. Расхождение статистики хоста и свитча быстро сужает домен отказа.
Снимите базовый срез
В стабильный период сохраните статистику интерфейса. Во время инцидента снимите ещё один срез. Так проще отличить накопительные счётчики от тех, которые растут прямо сейчас.
Типичные симптомы и что делать
Растут RX drops
Смотрите статистику очередей, размеры ring buffer, конфигурацию RSS, насыщение CPU и распределение прерываний. Не увеличивайте ring buffer вслепую: при перегрузке большие очереди могут обменять дропы на задержку.
Растут ошибки CRC
Проверьте кабель или оптику, порт коммутатора, совместимость трансивера и согласованное состояние линка — прежде чем менять тюнинг Linux.
Пропускная способность низкая, а ошибки на нуле
Смотрите дальше счётчиков интерфейса. Управление перегрузкой TCP, лимиты удалённого сервера, пропускная способность диска, частота CPU и поведение приложения могут ограничивать throughput, не порождая ошибок NIC.
Пример с линками 25GbE
Линк 25GbE теоретически может передавать 25 гигабит в секунду на уровне линейной скорости, но само по себе приложение до этой цифры не доходит. Важны размер пакета, накладные расходы протокола, обработка на CPU, топология PCIe и ёмкость удалённой стороны. Если ошибок нет, а скорость низкая — ищите узкое место за пределами сетевой карты.
Краткий алгоритм
ip -s -s link show dev eth0— базовая статистика.ethtool -i eth0— драйвер и прошивка.ethtool -S eth0— счётчики драйвера.- Разделите физические ошибки и перегрузку очередей.
- Проверьте линк и согласованную скорость.
- Снимите срезы до и во время инцидента.
- Если ошибок нет, а throughput низкий — смотрите выше по стеку.
Такой порядок помогает не гадать, а методично сужать область поиска. И да, не забывайте сохранять выводы команд — в следующий раз будет с чем сравнить.