Ретрансмиты 8%: виновником оказался один патч-корд в стойке

MAATRIX

Сервис работает, ничего не падает, в логах приложения пусто, CPU и память на графиках ровные — а пользователи всё равно жалуются, что всё «подвисает». Знакомая ситуация: искать нечего, но что-то явно не так. В этом разборе — реальный сценарий, где виновником замедления оказался не код и не база данных, а один физически повреждённый патч-корд в стойке дата-центра.

Симптомы: сервис не падает, а просто «вязнет»

Жалобы были расплывчатые: «долго грузится», «иногда подвисает на пару секунд», «то быстро, то медленно». Ни одной ошибки 5xx, ни одного таймаута в логах приложения. Первым делом посмотрели стандартную триаду:

• CPU — в среднем 20-30%, пиков нет;
• память — стабильна, swap не используется;
• диск — свободного места достаточно, iostat не показывает узких мест.

Формально сервер «здоров». Но пользователи ощущают задержку, которую нельзя объяснить нагрузкой. Это классический случай, когда проблема прячется не в стеке приложения, а в том, что происходит между сервером и клиентом на уровне передачи данных — и именно поэтому её так долго не находили.

Первая волна: грешим на приложение и базу

Естественная реакция в такой ситуации — искать проблему там, где она обычно и бывает: в приложении. Прогнали профилировщик, посмотрели медленные запросы в базе, проверили пул соединений — всё в пределах нормы, никаких аномальных долгих транзакций. Добавили индексы «на всякий случай», перезапустили воркеры — субъективно как будто стало чуть лучше, но жалобы продолжились через день-два.

Это типичная ловушка: «работает медленно, но не падает, без явных ошибок» почти всегда сначала списывают на приложение или базу данных, потому что там проще смотреть и проще что-то подкрутить. Сетевую статистику в такой ситуации проверяют в последнюю очередь — а зря, потому что именно она в итоге дала ответ.

Что такое ретрансмит TCP и почему это важный сигнал

TCP — надёжный протокол: если отправитель не получил подтверждение (ACK) доставки пакета за ожидаемое время, он решает, что пакет потерялся или задержался, и отправляет его повторно. Это и есть ретрансмит (retransmit). Механизм рассчитан на то, чтобы приложение вообще не заметило единичную потерю пакета в сети — TCP всё «залечивает» сам, без единой ошибки на уровне приложения.

Проблема в том, что каждый такой повтор стоит времени: пока не истечёт таймаут (или не сработает быстрый механизм fast retransmit по дублирующимся ACK), пакет просто не долетает до получателя. Один ретрансмит — это доли или единицы миллисекунд, но если их много и они происходят регулярно, суммарная задержка на каждый запрос ощутимо растёт, а пропускная способность TCP-соединения проседает, потому что окно перегрузки (congestion window) при потере пакета сокращается.

Именно поэтому доля повторных передач относительно общего числа отправленных пакетов (retransmit rate) — один из ключевых индикаторов здоровья сетевого пути на самом низком уровне. Фоновый уровень ретрансмитов в реальных сетях никогда не равен нулю — доли процента считаются нормой. А вот когда этот показатель заметно выше — это уже не шум, а сигнал, что где-то на пути пакеты систематически теряются или повреждаются, и TCP просто маскирует эту проблему повторными отправками. Пользователь при этом не видит явной ошибки — он видит просто «медленно».

Хронология: как всплыли 8% ретрансмитов

После того как гипотезы про приложение и базу не подтвердились, решили посмотреть сетевую статистику на уровне ОС — то, что обычно проверяют в последнюю очередь именно потому, что «с интернетом вроде всё в порядке» (пинг проходит, страницы открываются, просто медленно).

Первым делом — общая сетевая статистика ядра:

netstat -s | grep -i retrans

Вывод показал что-то в духе:

1284932 segments retransmitted
15987421 segments send out

Грубая прикидка: 1 284 932 / 15 987 421 ≈ 8%. Это существенно выше нормального фонового уровня (обычно речь о десятых долях процента на здоровом канале). Для уточнения посмотрели ретрансмиты по конкретным TCP-соединениям:

ss -ti

В выводе у соединений, которые шли через конкретный сетевой интерфейс сервера, в статистике retrans стояли ненулевые значения почти у каждого активного сокета — то есть проблема была не в одном «неудачном» соединении, а системной для трафика через этот интерфейс. Дальше нужно было понять — виновата вся сеть целиком или что-то локальное, на стороне именно этого сервера и его порта.

Спускаемся на уровень порта: CRC и ошибки кадра

Ретрансмиты на уровне TCP — это симптом, а не диагноз: они могут говорить о перегрузке где-то в сети, о проблемах на маршруте, а могут — о локальной проблеме на самом сервере, ещё до того, как пакет ушёл в сеть дальше. Чтобы разделить эти случаи, посмотрели статистику конкретного сетевого интерфейса:

ip -s link show eth0

RX: bytes  packets  errors  dropped  missed  mcast
    ...      ...       1284      312       0      0
TX: bytes  packets  errors  dropped  carrier  collsns
    ...      ...        897       0        204      0

Ненулевые errors и особенно carrier errors на TX — это уже прямой намёк на физический/канальный уровень, а не на что-то выше. Для детализации посмотрели расширенную статистику драйвера сетевой карты:

ethtool -S eth0 | grep -iE 'crc|error|align|drop'

rx_crc_errors: 48213
rx_align_errors: 1904
rx_frame_errors: 302
tx_errors: 897

CRC-ошибки (несовпадение контрольной суммы кадра) и ошибки выравнивания кадра (frame alignment) — это не про софт и не про перегрузку канала пропускной способностью. Это конкретные признаки того, что кадры на физическом уровне приходят повреждёнными: либо сигнал искажается по пути, либо соединение физически нестабильно. Именно наличие CRC-ошибок и ошибок кадра на конкретном интерфейсе, а не общая загрузка канала, стало тем фактом, который перевёл расследование с уровня «сеть тормозит» на уровень «конкретный физический линк неисправен».

Стоит сразу оговориться: у CRC- и frame-ошибок нет единого «нормального» порога, который одинаков для всех сетей и всех железок — но рост этих счётчиков во времени (а не разовый всплеск) и их привязка к конкретному порту почти всегда указывает на проблему именно физического уровня: кабель, коннектор, разъём на коммутаторе или сетевой карте.

Корневая причина: один патч-корд в стойке

Дальнейшая проверка была уже физической, а не программной. В стойке дата-центра проверили конкретный патч-корд, идущий от сервера к порту коммутатора: визуально ничего криминального — ни явного излома, ни видимого повреждения оболочки. Но именно поэтому такие проблемы и трудно заподозрить в первую очередь: кабель может выглядеть абсолютно нормально и при этом быть источником постоянных ошибок на физическом уровне — из-за перетёртой изнутри жилы, окислившегося или плохо обжатого коннектора, или заводского брака в самом кабеле.

Патч-корд заменили на заведомо исправный. После замены счётчики rx_crc_errors и rx_align_errors на интерфейсе перестали расти, а retransmit rate по netstat -s за следующие сутки наблюдения вернулся к фоновому уровню — заметно ниже прежних 8%. Это и стало подтверждением причины: не совпадение по времени, а прямая причинно-следственная связь — заменили конкретную физическую деталь, и конкретные счётчики ошибок перестали расти.

Деталь настолько простая и «неайтишная» — обычный кабель ценой в несколько сотен рублей, — что её действительно редко подозревают в первую очередь, когда разбирают проблему производительности. Гораздо привычнее искать причину в коде, конфигурации базы или настройках сети, чем в куске меди в патч-панели. Но именно кабели и коннекторы — самые дешёвые и самые массовые компоненты в любой стойке, и именно поэтому статистически они регулярно оказываются источником подобных проблем.

Что делать: практический чек-лист против скрытых потерь

Из этого случая можно вывести рабочий набор практик, которые стоит держать под рукой, а не изобретать заново при следующем «необъяснимом торможении»:

1. Смотрите не только на загрузку канала, но и на счётчики ошибок интерфейса. Полоса пропускания и утилизация канала ничего не скажут о качестве передачи. Регулярно (а не только в момент инцидента) проверяйте ip -s link и ethtool -S на предмет растущих errors, dropped, crc, align, carrier.

1. Держите под рукой базовую сетевую диагностику ОС. ss -ti и netstat -s | grep -i retrans — быстрый способ понять, есть ли аномальный retransmit rate вообще, до того как копать глубже.

1. Считайте retransmit rate относительно общего трафика, а не абсолютным числом. Абсолютное число ретрансмитов растёт вместе с трафиком само по себе — важен именно процент от общего числа переданных пакетов/сегментов.

1. Замена кабеля/патч-корда — легитимный диагностический шаг, а не «шаманство». Если есть подозрение на физический уровень, а визуальный осмотр ничего не показал — проще и быстрее заменить подозрительный патч-корд на заведомо исправный, чем часами анализировать трафик. Если проблема исчезла после замены — причина подтверждена практикой, а не только теорией.

1. Не игнорируйте «мелкие» аппаратные компоненты. Кабели, коннекторы, патч-панели, сетевые модули (SFP) — самые дешёвые и самые массовые элементы инфраструктуры, и именно поэтому они статистически чаще всего оказываются точкой отказа. Проблема производительности, которая выглядит программной, может корениться именно здесь.

1. Заведите алерт на рост ошибок интерфейса, а не только на доступность сервиса. Если бы счётчики CRC-ошибок мониторились с порогом, инцидент нашёлся бы за минуты, а не за дни разбора логов приложения. Подробнее о том, какие метрики железа вообще стоит держать под наблюдением, — в статье про мониторинг здоровья железа.

1. Помните, что «пинг хороший» не значит «сеть здорова». Обычный ICMP-пинг может проходить стабильно даже при заметной потере пакетов на других типах трафика — это разные механизмы проверки, и об этом стоит помнить, чтобы не закрывать вопрос по сети преждевременно. Если тема кажется знакомой — есть отдельный разбор о том, почему хороший пинг не гарантирует быстрый сайт, и статья про потерю пакетов, которую не видно в обычном ping.

Если вы арендуете сервер, а не строите инфраструктуру с нуля, повлиять на физический патч-корд в стойке провайдера вы напрямую не можете — но можете (и стоит) регулярно проверять счётчики ошибок на своём сетевом интерфейсе и обращаться в поддержку с конкретными цифрами (ethtool -S, ip -s link), а не с общей формулировкой «у нас всё тормозит». Конкретные счётчики резко ускоряют диагностику на стороне дата-центра.

Частые вопросы