మీ VPN గేట్వే CPU-చే పరిమితమా? మొదట ప్రతి కోర్ లోడ్ చదవండి
సగటులు ముఖ్యమైన థ్రెడ్ను దాచుతాయి. నియంత్రిత బదిలీ సమయంలో ప్రతి కోర్ లోడ్ చదవండి, మార్గాన్ని మినహాయించి, తర్వాత ప్రతి రన్కు ఒక డాక్యుమెంటెడ్ సెట్టింగ్ మార్చండి.
పెద్ద ఇన్స్టాన్స్ కొనడానికి ముందు మూడు పరిమితుల్లో ఏది చేరుకున్నారో నిర్ణయించండి. ఒక కోర్ పూర్తిగా బిజీగా ఉండి మిగతావి నిష్క్రియంగా ఉంటే అది ప్రతి ఫ్లోకు క్రిప్టో పనిని సూచిస్తుంది. బదిలీ సమయంలో అన్ని కోర్లు నిండి ఉంటే అది మొత్తం సామర్థ్యాన్ని సూచిస్తుంది. తక్కువ 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 ఇంకా లక్షణాన్ని అనుసరించకపోతే, ఊహపై అప్గ్రేడ్ చేయడం బదులు మార్గం మరియు అప్లికేషన్ తనిఖీలకు తిరిగి వెళ్లండి.