Ваш VPN-шлюз упирається в CPU? Спершу читайте навантаження по ядрах

Визначте, якої з трьох меж досягнуто, перш ніж купувати більший інстанс. Одне ядро завантажене повністю, а решта простоюють — це вказує на шифрування в розрахунку на потік. Усі ядра насичені під час передачі — це вказує на загальну пропускну здатність. Низький CPU і зростання кількості повторних передач указують на шлях. Кожен має свій перший крок, і лише один вирішується більшим інстансом.

Три межі, одна таблиця, три виправлення

Читайте рядки як діагнози, а не як етапи. Один потік на 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 досі не слідує за симптомом, поверніться до перевірок шляху й застосунку, замість оновлюватися на основі здогадки.