Сеть кончилась раньше диска: как понять, что упор в канал, а не в хранилище

MAATRIX

Раздача файлов ползёт, бэкап на удалённое хранилище тянется часами, реплика не догоняет мастер — и первая мысль почти всегда одна: «диск не тянет». Ставите NVMe вместо SATA, разносите тома, а скорость почти не меняется. Дело в том, что диск в такой схеме часто вообще ни при чём: узкое место — сетевой канал, число одновременных соединений или потери пакетов на маршруте. Разница в диагностике простая: диск смотрят через iostat, сеть — через iftop, nload и sar -n, и эти два набора цифр редко врут одновременно.

Симптомы одинаковые, причина разная

Медленная отдача выглядит одинаково независимо от того, где узкое место: клиент долго скачивает файл, реплика PostgreSQL растёт в отставании, rsync до внешнего хранилища ползёт со скоростью, которая не радует. Административная реакция по умолчанию — «добавить IOPS» или «переехать на NVMe». Проблема в том, что диск в раздающем сценарии почти всегда работает в режиме последовательного чтения, а это именно то, с чем современный SSD справляется без напряжения — узкое место там, где чтение случайное и мелкоблочное (это отдельная история, разобрана в статье про то, как отличить упор в IOPS).

Если вы поменяли диск, а скорость отдачи не выросла — это уже сигнал: возможно, диск был не при чём. Дальше нужно не гадать, а посмотреть на оба слоя параллельно, в реальном времени, во время самой нагрузки. Разовый замер после инцидента ничего не скажет — сеть и диск нужно смотреть именно тогда, когда идёт медленная передача.

Диск: iostat как контрольная точка

Прежде чем разбираться с сетью, закройте вопрос по диску — иначе будете гадать. Во время передачи откройте второй терминал и запустите:

iostat -x 1

Смотрите на три колонки: %util (загрузка устройства), await (среднее время ожидания операции в мс) и r/s/w/s (операции в секунду). Если %util держится в районе 100%, а await заметно выше единиц миллисекунд — диск действительно упирается, и разговор про сеть можно отложить. Но частый случай в раздающих и бэкапных сценариях другой: %util болтается на скромных значениях, await низкий, а скорость передачи всё равно низкая. Это и есть повод проверить канал.

Отдельно стоит смотреть на rkB/s — сколько диск реально отдаёт данных в секунду. Если эта цифра стабильно выше, чем то, что «уезжает» наружу по сети (см. следующий раздел), значит диск успевает подготовить данные быстрее, чем канал успевает их передать — классический упор в сеть.

Сеть в реальном времени: iftop и nload

iftop показывает, кто и с кем сейчас обменивается трафиком, по каждому соединению отдельно:

iftop -i eth0 -n -P

Флаг -n отключает резолвинг DNS (не тормозит вывод), -P показывает порты. В выводе три колонки для каждого потока — скорость за последние 2, 10 и 40 секунд, это сглаживает всплески и даёт понять, стабильно ли забита полоса или скачет. Если суммарная скорость по всем соединениям упирается в потолок и держится там ровно — это канал, а не диск.

nload даёт более грубую, но наглядную картину — суммарный график входящего и исходящего трафика по интерфейсу с текущим, средним, минимальным и максимальным значением:

nload eth0

Полезно сверить показанную скорость с номинальной пропускной способностью порта. 1 Гбит/с — это около 118 МБ/с полезной нагрузки (с учётом накладных расходов протокола, не 125 МБ/с ровно). Если nload показывает стабильные 110-115 МБ/с на интерфейсе, который физически ограничен гигабитом — упор именно в канал, и никакой диск здесь не поможет, будь он хоть в четыре раза быстрее.

Накопленная статистика: sar -n DEV и sar -n EDEV

iftop/nload хороши для наблюдения в моменте, но не оставляют истории. Если sysstat установлен и собирает данные по крону (пакет sysstat, служба sysstat/sadc в системе), можно посмотреть, что происходило на интерфейсе в конкретный час:

sar -n DEV 1 10

Колонки rxkB/s и txkB/s — это фактическая скорость приёма и передачи, %ifutil — загрузка интерфейса в процентах от его номинальной скорости (там, где ядро умеет её определить). Если %ifutil держится около 90-100% всё время передачи — вопросов нет, канал полон.

Отдельная и часто упускаемая история — ошибки и потери на уровне интерфейса:

sar -n EDEV 1 10

Здесь важны rxdrop/s, txdrop/s, rxerr/s, coll/s. Ненулевые дропы на исходящем трафике — это не «медленный диск», это переполнение очереди на сетевой карте или коллизии где-то на пути (иногда причина — виртуальный интерфейс, который не успевает разгребать пакеты). Такие потери TCP компенсирует ретрансмитами, а на прикладном уровне это выглядит как «сеть вроде не забита, а скорость низкая» — если смотреть только на rxkB/s/txkB/s, не видя дропов, легко сделать неверный вывод.

Как отличить упор в сеть от упора в диск, если симптомы похожи

Сравнивать нужно не абсолютные цифры, а соотношение потолков. Практический порядок проверки:

1. Посчитайте теоретический потолок канала. 1GbE — около 118 МБ/с, 10GbE — около 1,18 ГБ/с (в обоих случаях это верхняя граница, реальная цифра всегда чуть ниже из-за оверхеда протокола и других потребителей канала). Если наблюдаемая скорость передачи близка к этому потолку — упор в сеть, диск можно не трогать.
2. Сравните rkB/s диска и txkB/s интерфейса. Если диск способен отдавать в разы больше, чем уходит по сети — узкое место не в нём.
3. Проверьте число одновременных соединений. ss -s даёт сводку, ss -tn state established | wc -l — точное число активных TCP-сессий. Если раздача идёт через один поток (одно TCP-соединение, например простой rsync без --parallel или один wget), скорость может упираться не в физический канал, а в размер TCP-окна и задержку до клиента — это отдельная причина, разобранная в статье про то, почему канал через океан тормозит из-за TCP-окна. В этом случае несколько параллельных потоков дадут прирост даже без апгрейда канала.
4. Проверьте потери и задержку до получателя. mtr -rw target.example.com за минуту покажет, есть ли потери на конкретных хопах и насколько скачет задержка. Стабильные потери 1-2% на промежуточном узле съедают пропускную способность TCP сильнее, чем кажется — протокол снижает окно при каждой потере.
5. Проверьте, не делит ли канал кто-то ещё. На виртуальной машине сосед по гипервизору или другой процесс на этом же сервере может забирать полосу параллельно с вашей задачей — iftop покажет все активные соединения, а не только то, которое вы тестируете.

Если после этих пяти шагов картина неоднозначная — скорее всего, дело не в одном узком месте, а в сумме факторов: канал не полностью забит, но близко к потолку, плюс не самое удачное число потоков.

Типичные сценарии: репликация, раздача статики, бэкап наружу

Репликация БД. Отставание реплики часто списывают на диск реплики, хотя причина — недостаточная пропускная способность между узлами или загруженность канала другим трафиком в то же окно времени. Проверка та же: смотрите sar -n DEV на обеих сторонах во время активного применения WAL/binlog, сравнивайте с объёмом изменений. Если между площадками канал общий с другими сервисами — стоит посмотреть, не совпадает ли отставание с пиками стороннего трафика (подробнее логика отставания разобрана в статье о том, как работает репликация и почему реплика отстаёт).

Раздача статики. Если сайт или файловое хранилище отдаёт контент медленно при низкой загрузке диска и CPU — почти наверняка это канал или число одновременных подключений (лимит воркеров nginx, лимит соединений на IP). Здесь же стоит прикинуть, не выгоднее ли часть трафика увести на CDN — это разбор экономики, а не техники, сделанный отдельно.

Бэкап на удалённое хранилище. Самый частый случай упора в канал: локальный диск отдаёт данные значительно быстрее, чем rclone/restic/borg успевают их залить наружу. Здесь же обычно всплывает вопрос сжатия — оно снижает объём передаваемых данных, но платит за это временем CPU, и в паре с уже загруженным CPU может оказаться дороже, чем просто отправить сырые данные (когда именно сжатие того не стоит — отдельный разбор про то, когда gzip на лету дороже трафика).

Что делать, если упёрлись именно в канал

Если диагностика однозначно указывает на сеть, а не на диск, вариантов обычно четыре, и они комбинируются:

• Шейпинг и приоритизация. Если проблема не в объёме, а в том, что бэкап или репликация душат интерактивный трафик сайта — ограничьте фоновую задачу через tc (например, tc qdisc add dev eth0 root tbf rate 50mbit burst 32kbit latency 400ms для грубого ограничения исходящей полосы конкретного интерфейса) или встроенный лимит инструмента (rclone --bwlimit, borg с ограничением через ionice/внешний шейпер). Это не увеличивает пропускную способность, но убирает конкуренцию за неё.
• Сжатие там, где оно оправдано. Для текстовых дампов и логов сжатие почти всегда выигрывает — объём падает в разы, а CPU на современных ядрах справляется быстро. Для уже сжатых данных (архивы медиа, бинарники) повторное сжатие тратит CPU почти без пользы — проверяйте на выборке, а не на глазок.
• Несколько параллельных потоков вместо одного. Один TCP-поток на канале с задержкой (особенно межконтинентальном) не выбирает всю номинальную полосу из-за размера окна. rclone --transfers, параллельный rsync по частям каталога, несколько одновременных соединений вместо одного — часто дают прирост без апгрейда канала вообще.
• Несколько каналов или другая локация. Если один интерфейс физически ограничен (1GbE), а несколько параллельных потоков уже не помогают — либо переходите на порт с большей номинальной скоростью, либо разносите нагрузку по нескольким интерфейсам (bonding в режиме балансировки), либо переносите задачу ближе к источнику данных — например, держите приёмник бэкапов в той же локации, что и сервер-источник, чтобы не гонять трафик через межконтинентальный канал с его задержкой и потерями.

Важный нюанс: увеличение диска (больше IOPS, NVMe вместо SATA) в сценарии «упор в канал» не даст прироста вообще — это деньги, потраченные не на ту проблему. Диагностика перед апгрейдом стоит десяти минут, апгрейд не туда — стоит бюджета.

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