Ограничен ли е вашият VPN шлюз от процесора? Първо четете натоварването по ядра
Средните стойности скриват нишката, която има значение. Четете натоварването по ядра при контролиран трансфер, изключете пътя, след което променяйте по една документирана настройка на пускане.
Определете коя от трите граници сте достигнали, преди да купите по-голям инстанс. Едно ядро натоварено докрай, а останалите бездействат, сочи към крипто работа за поток. Всички ядра наситени по време на трансфер сочат към общ капацитет. Нисък 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 все още не следва симптома, върнете се към проверки на пътя и приложението, вместо да надграждате на догадка.