«Нода медленная»: сервер, канал или путь — разбор по шагам

Задача

Пользователи на одной локации жалуются на скорость — например 2–3 МБ/с на разных устройствах. Надо понять, кто виноват: сам сервер, провайдер ноды или путь до неё (расстояние, кривой backhaul аплинка). Без этого разделения исправляют не то: крутят конфигурацию, когда виноват маршрут, или наоборот. Алгоритм — несколько замеров с ноды по SSH.

Шаг 1. Сервер-сайд здоров?

sysctl net.ipv4.tcp_congestion_control net.core.default_qdisc   # ждём bbr + fq
ethtool eth0 | grep -i speed                                    # ширина NIC
tc qdisc show dev eth0                                          # нет ли rate-limit (htb/tbf)
uptime; free -h

Шаг 2. Канал наружу: один поток против многих

Ключевая развилка:

curl -o /dev/null -s -w "%{speed_download} B/s\n" --max-time 25 http://<test-mirror>/100mb.test
for i in 1 2 3 4; do curl -o /dev/null -s -w "поток$i: %{speed_download}\n" --max-time 20 http://<test-mirror>/100mb.test & done; wait

• 1 поток ≈ N, а 4 потока ≈ 4×N → жёсткого потолка нет. Одиночный поток упёрся в TCP и латентность — это норма, лечится мультиплексом на клиенте.
• 1 поток ≈ 4 потокам (сумма не растёт) → жёсткий потолок провайдера, оверселл канала.

Шаг 3. Путь до ноды — главный виновник далёких локаций

Замер с узла в регионе пользователей:

ssh root@<узел-в-регионе> 'ping -c4 -q <адрес-целевой-ноды>'
ssh root@<узел-в-регионе> 'mtr -rwc 5 <адрес-целевой-ноды>'   # где теряется, через какие страны идёт backhaul

Одиночный Reality-поток по каналу с RTT около 140 мс физически даёт 15–25 Мбит, то есть 2–3 МБ/с. Конфигурацией не лечится, это плата за расстояние.

Имена хопов в mtr выдают географию. «Близкая» локация может тормозить из-за кривого backhaul: если трафик идёт крюком через третью страну (видно по hostname хопов) — это плюс 60–70 мс. Такое — сетевая претензия хостеру (поднять прямой пиринг), которую он способен устранить. «В первый день было быстро, потом упало» — почти всегда деградация маршрута аплинка, а не сервер.

Шаг 4. Память «занята», а процессов нет — оверселл виртуалки

free -h
ps -eo rss --no-headers | awk '{s+=$1} END{print s/1024" MB"}'   # сумма RSS
lsmod | grep -i balloon                                          # vmw_balloon / virtio_balloon

Если used сильно больше суммы процессов, slab и cache, а balloon-модуль загружен — гипервизор раздул balloon и отжал RAM под соседей. Это маркер оверселла хоста: вероятно, оверселлят и CPU с сетью в пик. Кандидат на смену хостера.

Подводные камни

• Часть тест-зеркал режется в ноль из некоторых сетей — держите пару опорных зеркал.
• mtr -z (ASN-режим) и иногда -rwc роняют buffer overflow на части ядер — снимайте трассу с другой стороны или без -z.
• Низкий одиночный TCP-поток — не всегда «нода медленная». Если 4 потока масштабируются линейно, потолка нет.
• Далёкую локацию не держать в скоростном авто-балансировщике: балансер по RTT-пробе не видит реальный медленный exit и льёт на него трафик. Помечать локацию честно.