Czy Twoja brama VPN jest ograniczona przez CPU? Najpierw czytaj obciążenie na rdzeń

Zdecyduj, który z trzech limitów osiągnąłeś, zanim kupisz większą instancję. Jeden rdzeń zajęty w pełni, a reszta bezczynna wskazuje na pracę kryptograficzną na przepływ. Wszystkie rdzenie nasycone podczas transferu wskazują na łączną wydajność. Niskie CPU i rosnąca liczba retransmisji wskazują na ścieżkę. Każdy ma inny pierwszy krok, a tylko jeden rozwiązuje większa instancja.

Trzy limity, jedna tabela, trzy poprawki

Czytaj wiersze jako diagnozy, nie jako etapy. Jeden wątek na 100%, gdy pozostałe są bezczynne, to najczęstszy wynik na bramie z jednym dużym tunelem, bo szyfrowanie tego przepływu działa na jednym rdzeniu. Wszystkie rdzenie zajęte podczas transferu oznaczają, że maszyna robi już tyle, ile może. Niskie CPU i rosnące retransmisje oznaczają, że procesor czeka na sieć, która ciągle gubi dane.

Napraw je w tej kolejności dowodów. Rozłożenie przepływów na workery pomaga pierwszemu przypadkowi i nic nie robi dla drugiego. Większa instancja pomaga drugiemu i marnuje pieniądze na pierwszym. Poprawka MTU lub strat to jedyna, która dotyka trzeciego. Kupowanie wydajności, zanim wiesz, w którym wierszu jesteś to droga wersja zgadywania.

Oddziel przypięty wątek od zajętego hosta

Zacznij od wykorzystania na rdzeń, żeby jeden przypięty rdzeń nie mógł schować się w średniej. Jeden przebieg podczas transferu pokazuje, czy obciążenie jest płaskie, czy z pikami. Oba kształty są pouczające, a profil z pikami często oznacza, że okno próbkowania złapało aktywność planisty, a nie szyfrowanie.

mpstat -P ALL 1 5

Przypisz zajęty rdzeń do procesu, potem do wątku. Poniższy przebieg kontrolny trzyma razem wątki nadrzędne i podrzędne, co ma znaczenie, gdy demon rozwidla się dla każdego połączenia:

pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10

Krypto jądra nigdy nie pojawia się w liczniku procesu w przestrzeni użytkownika. Próbkuj wątki osobno i porównaj ten obraz z rozliczeniem procesu:

top -H -b -n 1 | head -20

Liczniki gniazd czytaj na końcu, bo to one decydują, czy więcej CPU w ogóle pomoże. Rosnące retransmisje przy płaskim CPU to nie problem procesora. Utrzymuj transfer w ruchu podczas próbkowania, inaczej liczby opiszą bezczynną maszynę:

ss -ti | grep -E 'retrans|cwnd|rtt'

Kontrolowany transfer, wykonany dwa razy

Bezczynne liczniki niczego nie dowodzą, a test na tle losowego punktu końcowego dowodzi bardzo niewiele. Wybierz jednego klienta, jedno miejsce docelowe i jeden reprezentatywny transfer, który wolno Ci wykonać, a potem zapisz przepustowość i opóźnienie interaktywne w tym samym oknie. Brama może się nasycić, gdy masowa kopia jeszcze się kończy, a krzywa opóźnienia jest tym, co użytkownicy naprawdę czują. Zapisz transfer, liczbę klientów i wersję demona obok liczb.

Powtórz przebieg z kilkoma równoległymi przepływami. Skalowanie przez przepływy sugeruje okna na przepływ; pozostawanie płaskim przy przypiętym rdzeniu sugeruje przetwarzanie.

Następnie powtórz jeszcze raz z zatrzymanymi opcjonalnymi obciążeniami. Kopia zapasowa, wysyłka logów albo baza danych na tym samym hoście mogą dać zajętą średnią, która nie ma nic wspólnego z tunelami. Jeśli CPU nadal jest przypięte, a host poza tym cichy, dowody wskazują na proces VPN. Jeśli spada, mierzyłeś sąsiada, a brama nigdy nie była problemem.

Wyklucz ścieżkę, zanim kupisz sprzęt

Rosnące retransmisje, kurczące się okno przeciążenia i rosnący czas rundy wskazują z dala od procesora. Porównaj MTU tunelu z MTU ścieżki, sprawdź łącze bazowe pod kątem strat i potwierdź, że własny uplink klienta nie jest ograniczeniem. Większa brama nie naprawi łącza, które gubi pakiety, a użytkownicy opisują obie usterki tymi samymi słowami. Licznik retransmisji rozdziela je w kilka minut.

Na serwerze wirtualnym dodaj metryki dostawcy do metryk gościa. Skradziony czas to sposób, w jaki nadsubskrypcja staje się widoczna w gościu, i żadne strojenie w gościu tego nie usunie. Liczniki gościa nie widzą hosta, więc czysty wykres gościa nie jest dowodem zdrowego hosta.

Jedna zmiana, jeden pomiar

Wybierz hipotezę, którą wspierają dowody, a potem zmień dokładnie jedno obsługiwane ustawienie: liczbę workerów, udokumentowaną opcję offload albo rozmiar instancji. OpenVPN publikuje przewodnik rozwiązywania problemów z wydajnością o tym samym podziale między przetwarzaniem a transportem: Rozwiązywanie problemów z wydajnością OpenVPN.

Potwierdź, że opcja offload jest naprawdę aktywna, zamiast ufać fladze, a potem powtórz identyczny transfer i porównaj to, co porównywalne. To jedyny sposób, by odróżnić prawdziwą poprawę od cichego popołudnia. Zachowaj punkt kontrolny do przywrócenia, bo przy drugiej zmianie ludzie tracą rachubę, która pomogła. Jedna zmienna na przebieg jest wolna przez dzień i szybka przez miesiąc.

Nie osłabiaj uwierzytelniania ani zestawu szyfrów, żeby wykres wyglądał lepiej. Jeśli CPU nadal nie podąża za objawem, wróć do kontroli ścieżki i aplikacji, zamiast aktualizować na podstawie domysłu.