Limitado ba ng CPU ang iyong VPN gateway? Basahin muna ang load kada core

Magpasya kung alin sa tatlong limitasyon ang naabot mo bago bumili ng mas malaking instance. Isang core na puno habang walang ginagawa ang iba ay tumutukoy sa crypto work kada flow. Lahat ng core na puspos habang naglilipat ay tumutukoy sa kabuuang kapasidad. Mababang CPU na may tumataas na bilang ng retransmit ay tumutukoy sa landas. Bawat isa ay may ibang unang hakbang, at isa lamang ang nasosolusyunan ng mas malaking instance.

Tatlong limitasyon, isang talahanayan, tatlong pagwawasto

Basahin ang mga hilera bilang diagnosis, hindi yugto. Isang thread sa 100% habang walang ginagawa ang iba ang pinakakaraniwang resulta sa gateway na may isang malaking tunnel, dahil ang encryption ng flow na iyon ay tumatakbo sa isang core. Lahat ng core na abala habang naglilipat ay nangangahulugang ginagawa na ng makina ang lahat ng kaya nito. Mababang CPU na may tumataas na retransmit ay nangangahulugang hinihintay ng processor ang network na patuloy na nagtatapon ng data.

Ayusin ang mga ito sa ganoong pagkakasunod-sunod ng ebidensya. Ang pagkalat ng flow sa mga worker ay tumutulong sa unang kaso at walang ginagawa sa pangalawa. Ang mas malaking instance ay tumutulong sa pangalawa at nag-aaksaya ng pera sa una. Ang pagwawasto ng MTU o pagkawala ang tanging humahawak sa pangatlo. Bumili ng kapasidad bago malaman kung aling hilera ka ang mamahaling bersyon ng paghula.

Ihiwalay ang naka-pin na thread mula sa abalang host

Simulan sa paggamit kada core, upang ang isang naka-pin na core ay hindi makapagtago sa isang average. Ang isang pagtakbo habang naglilipat ay nagpapakita kung ang load ay patag o may taluktok. Ang dalawang hugis ay nagbibigay-alam, at ang profile na may taluktok ay kadalasang nangangahulugang nahuli ng sampling window ang aktibidad ng scheduler kaysa sa encryption.

mpstat -P ALL 1 5

Iugnay ang abalang core sa isang proseso, pagkatapos sa isang thread. Ang follow-up na pagtakbo sa ibaba ay nagpapanatili ng magkakasama ang parent at child thread, na mahalaga kapag nag-fork ang daemon kada koneksyon:

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

Hindi kailanman lumalabas ang kernel crypto sa isang counter ng proseso sa user space. Mag-sample ng thread nang hiwalay at ihambing ang pananaw na iyon sa accounting ng proseso:

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

Basahin ang mga counter ng socket sa huli, dahil sila ang nagpapasya kung makakatulong ba talaga ang mas maraming CPU. Ang tumataas na retransmit habang patag ang CPU ay hindi problema ng processor. Panatilihing tumatakbo ang paglilipat habang nag-sample ka, kung hindi ay ilalarawan ng mga numero ang isang walang ginagawang makina:

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

Isang kontroladong paglilipat, pinatakbo nang dalawang beses

Walang pinatutunayan ang mga walang ginagawang counter, at napakaliit ang pinatutunayan ng benchmark laban sa isang random na endpoint. Pumili ng isang client, isang destinasyon at isang representatibong paglilipat na pinapayagan kang patakbuhin, pagkatapos ay i-record ang throughput at interactive na pagkaantala sa parehong window. Maaaring maging puspos ang gateway habang natatapos pa ang malaking kopya, at ang kurba ng pagkaantala ang tunay na nararamdaman ng mga user. Isulat ang paglilipat, bilang ng client at bersyon ng daemon sa tabi ng mga numero.

Ulitin ang pagtakbo na may ilang parallel na flow. Ang pagtaas sa mga flow ay nagmumungkahi ng window kada flow; ang pananatiling patag na may isang naka-pin na core ay nagmumungkahi ng pagproseso.

Pagkatapos ay ulitin muli nang naka-pause ang mga opsyonal na workload. Ang backup, log shipper o database sa parehong host ay maaaring gumawa ng abalang average na walang kinalaman sa mga tunnel. Kung naka-pin pa rin ang CPU habang tahimik ang host sa ibang aspeto, ang ebidensya ay tumuturo sa proseso ng VPN. Kung bumaba ito, sinukat mo ang kapitbahay, at hindi kailanman naging problema ang gateway.

Ibukod ang landas bago bumili ng hardware

Ang tumataas na retransmit, lumiliit na congestion window at lumalaking round-trip time ay lahat tumuturo palayo sa processor. Ihambing ang MTU ng tunnel sa MTU ng landas, suriin ang pinagbabatayang link para sa pagkawala, at tiyakin na ang sariling uplink ng client ay hindi ang limitasyon. Ang mas malaking gateway ay hindi nag-aayos ng link na nagtatapon ng packet, at inilalarawan ng mga user ang dalawang depekto sa parehong salita. Ang counter ng retransmit ay naghihiwalay sa kanila sa ilang minuto.

Sa isang virtual server, idagdag ang metrics ng provider sa sarili ng guest. Ang ninakaw na oras ang paraan kung paano nagiging nakikita ang sobrang benta sa loob ng guest, at walang tuning sa loob ng guest ang nag-aalis nito. Hindi nakikita ng mga counter ng guest ang host, kaya ang malinis na graph ng guest ay hindi patunay ng malusog na host.

Isang pagbabago, isang pagsukat

Piliin ang hypothesis na sinusuportahan ng ebidensya, pagkatapos ay baguhin ang eksaktong isang suportadong setting: bilang ng worker, isang dokumentadong opsyon sa offload, o ang laki ng instance. Naglalathala ang OpenVPN ng gabay sa pag-troubleshoot ng performance tungkol sa parehong paghahati sa pagitan ng processing at transport: Pag-troubleshoot ng performance ng OpenVPN.

Tiyakin na talagang aktibo ang opsyon sa offload sa halip na magtiwala sa flag, pagkatapos ay patakbuhin muli ang parehong paglilipat at ihambing ang katulad sa katulad. Iyon lamang ang paraan upang makilala ang tunay na pagbuti mula sa isang tahimik na hapon. Panatilihin ang isang checkpoint na maaari mong ibalik, dahil sa pangalawang pagbabago nawawala sa mga tao kung alin ang tumulong. Ang isang variable kada pagtakbo ay mabagal sa isang araw at mabilis sa isang buwan.

Huwag pahinain ang authentication o ang cipher suite upang gawing mas maganda ang graph. Kung hindi pa rin sinusundan ng CPU ang sintomas, bumalik sa mga pagsusuri ng landas at application sa halip na mag-upgrade batay sa hula.