તમારો 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 હજી લક્ષણને અનુસરતું ન હોય, તો અનુમાન પર અપગ્રેડ કરવાને બદલે માર્ગ અને એપ્લિકેશન તપાસ પર પાછા ફરો.