Ваш 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 ўсё яшчэ не адпавядае сімптому, вярніцеся да праверак шляху і праграмы, а не абнаўляйце на здагадку.