Ваш VPN-шлюз упирается в CPU? Сначала читайте нагрузку по ядрам
Средние значения скрывают важный поток. Читайте нагрузку по ядрам на фоне контролируемой передачи, исключите путь, затем меняйте одну документированную настройку за прогон.
Определите, какой из трёх пределов достигнут, прежде чем покупать более крупный инстанс. Одно ядро загружено полностью, а остальные простаивают — это указывает на шифрование в расчёте на поток. Все ядра насыщены во время передачи — это указывает на общую пропускную способность. Низкий CPU и растущее число повторных передач указывают на путь. У каждого свой первый шаг, и только один решается более крупным инстансом.
Три предела, одна таблица, три исправления
| Limit | Reading during a transfer | First move |
|---|---|---|
| Single thread | one core near 100%, siblings idle | spread flows across workers |
| Aggregate CPU | every core busy, load average climbs | capacity, or less work per byte |
| Path or provider | low CPU, retransmits or steal time high | MTU, loss, host contention |
Читайте строки как диагнозы, а не как этапы. Один поток на 100%, пока остальные простаивают, — самый частый результат на шлюзе с одним большим туннелем, потому что шифрование этого потока идёт на одном ядре. Все ядра заняты во время передачи — значит, машина уже делает столько, сколько может. Низкий CPU при растущих повторных передачах означает, что процессор ждёт сеть, которая постоянно теряет данные.
Исправляйте их в этом порядке доказательств. Распределение потоков по воркерам помогает первому случаю и ничего не даёт второму. Более крупный инстанс помогает второму и тратит деньги на первом. Исправление MTU или потерь — единственное, что затрагивает третий. Покупка мощности до того, как вы узнали, в какой вы строке — дорогая версия догадки.
Отделите закреплённый поток от занятого хоста
Начните с использования по ядрам, чтобы одно закреплённое ядро не могло спрятаться внутри среднего. Один прогон во время передачи покажет, ровная нагрузка или с пиками. Обе формы информативны, а профиль с пиками часто означает, что окно выборки поймало активность планировщика, а не шифрование.
mpstat -P ALL 1 5Привяжите занятое ядро к процессу, затем к потоку. Следующий прогон ниже держит родительские и дочерние потоки вместе, что важно, когда демон ветвится на каждое соединение:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10Криптография ядра никогда не появляется в счётчике процесса пользовательского пространства. Снимайте выборку по потокам отдельно и сравните эту картину с учётом процесса:
top -H -b -n 1 | head -20Счётчики сокетов читайте последними, потому что они решают, поможет ли вообще больше CPU. Рост повторных передач при ровном CPU — не проблема процессора. Держите передачу запущенной во время выборки, иначе числа опишут простаивающую машину:
ss -ti | grep -E 'retrans|cwnd|rtt'Контролируемая передача, выполнена дважды
Простаивающие счётчики ничего не доказывают, а тест против случайной конечной точки доказывает очень мало. Выберите одного клиента, одно назначение и одну представительную передачу, которую вам разрешено запускать, затем запишите пропускную способность и интерактивную задержку в одном окне. Шлюз может насыщаться, пока массовое копирование ещё завершается, и именно кривую задержки пользователи реально чувствуют. Запишите передачу, число клиентов и версию демона рядом с числами.
Повторите прогон с несколькими параллельными потоками. Рост при нескольких потоках указывает на окна на поток; ровное поведение при закреплённом ядре указывает на обработку.
Затем повторите ещё раз с остановленными дополнительными нагрузками. Резервное копирование, отправщик журналов или база данных на том же хосте могут дать занятое среднее, не имеющее отношения к туннелям. Если CPU по-прежнему закреплён, а хост в остальном тих, доказательства указывают на процесс VPN. Если он падает, вы измеряли соседа, и шлюз никогда не был проблемой.
Исключите путь до покупки оборудования
Растущие повторные передачи, сжимающееся окно перегрузки и растущее время кругового обхода указывают прочь от процессора. Сравните MTU туннеля с MTU пути, проверьте нижележащее звено на потери и подтвердите, что собственный восходящий канал клиента не является пределом. Более крупный шлюз не чинит звено, теряющее пакеты, а пользователи описывают обе неисправности одинаковыми словами. Счётчик повторных передач разделяет их за минуты.
На виртуальном сервере добавьте метрики провайдера к собственным метрикам гостя. Украденное время — это то, как перепродажа становится видимой внутри гостя, и никакая настройка внутри гостя этого не убирает. Счётчики гостя не видят хост, поэтому чистый график гостя не является доказательством здорового хоста.
Одно изменение, одно измерение
Выберите гипотезу, которую поддерживают доказательства, затем измените ровно одну поддерживаемую настройку: число воркеров, документированную опцию разгрузки или размер инстанса. OpenVPN публикует руководство по устранению проблем с производительностью о том же разделении обработки и транспорта: Устранение проблем с производительностью OpenVPN.
Убедитесь, что опция разгрузки действительно активна, а не полагайтесь на флаг, затем повторите ту же передачу и сравните сопоставимое. Это единственный способ отличить настоящее улучшение от тихого дня. Сохраняйте точку восстановления, потому что именно на втором изменении люди теряют след того, что помогло. Одна переменная за прогон — медленно на день и быстро на месяц.
Не ослабляйте аутентификацию или набор шифров, чтобы график выглядел лучше. Если CPU по-прежнему не следует за симптомом, вернитесь к проверкам пути и приложения, вместо того чтобы обновляться на основе догадки.