VPN સર્વર લોડ સમજૂતી: વપરાશકર્તાઓ, CPU કે અપલિંક?
નીચો લોડ સ્કોર નિષ્ક્રિય વપરાશકર્તાઓ, વધારાનું CPU અથવા પહોળી અપલિંક દર્શાવી શકે છે. તેને ઝડપી કહેતા પહેલાં loadavg, ઇન્ટરફેસ કાઉન્ટરો અને સ્ટેટસ ફાઇલ વાંચો.
0.4 લોડ પર બેઠેલું ગેટવે તેની પાછળના દરેક વપરાશકર્તા માટે હજી પણ ઘસાઈને ચાલી શકે છે. સરેરાશ લોડ એવા કાર્યો ગણે છે જે ચલાવી શકાય તેવા છે અથવા અવિરત ઊંઘમાં ફસાયેલા છે, અને ચાર કોરના હોસ્ટ પર એક જ સંતૃપ્ત પ્રક્રિયા તેને 1.0 તરફ ધકેલવા માટે પૂરતી છે જ્યારે ત્રણ કોર નકામા બેઠા હોય. તે સંખ્યાને અનામત તરીકે વાંચવી એ એન્ડપોઇન્ટ પસંદગીમાં સૌથી સામાન્ય ભૂલ છે. ટનલને ખરેખર મર્યાદિત કરનારી વસ્તુ સામાન્ય રીતે ચારમાંથી એક હોય છે: એક વ્યસ્ત કોર, અપલિંક, તેની સામેની કતાર, અથવા પ્રતિ-સત્ર નીતિ જે કોઈએ દસ્તાવેજ ન કરી.
સરેરાશ લોડ કાર્યો ગણે છે, થ્રુપુટ નહીં
કર્નલ રન ક્યૂ અને ઇનપુટ-આઉટપુટની રાહ જોતા કાર્યોની સંખ્યાના નમૂના લે છે, પછી બંનેને એક, પાંચ અને પંદર મિનિટમાં સરળ કરે છે. તે વ્યાખ્યામાં બાઇટ, પેકેટ કે ટનલનો કોઈ ઉલ્લેખ નથી. જેનું સ્ટોરેજ અટકી ગયું છે તેવું હોસ્ટ લગભગ કોઈ ટ્રાફિક વિના ઊંચો લોડ જણાવી શકે છે, અને કર્નલ ડેટા પથ દ્વારા ગીગાબિટ ધકેલતું હોસ્ટ આરામદાયક લોડ જણાવી શકે છે.
તેથી લોડને ટનલ પ્રદર્શન સાથે સહસંબંધિત કરવા માટે પ્રતિ-કોર દૃશ્ય જરૂરી છે. જો એક કોર સંપૂર્ણ ભરાયેલું હોય, તો ડેશબોર્ડ પરની કુલ ટકાવારી હજી પણ સારી દેખાશે:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20ત્રીજો આદેશ VPN હોસ્ટ્સ પર સૌથી વધુ મહત્ત્વનો છે. OpenVPN 2.x માં યુઝરસ્પેસ પેકેટ પ્રોસેસિંગ મોટે ભાગે પ્રતિ પ્રક્રિયા ક્રમિક છે, તેથી એક જ વ્યસ્ત થ્રેડ ટોચમર્યાદા બની શકે છે જ્યારે ડેશબોર્ડ પુષ્કળ નિષ્ક્રિય ક્ષમતા જણાવે છે. જો તમારા ધીમા સમયગાળા દરમિયાન એક થ્રેડ કોરનો મોટાભાગનો ભાગ ધરાવે છે, તો હોસ્ટ એકંદરે ઓછું સજ્જ નથી; તે એ પરિમાણમાં મર્યાદિત છે જે સંજોગવશાત્ મહત્ત્વનું છે.
સમય પર પણ ધ્યાન આપો. પંદર મિનિટના સરેરાશ કોલ બગાડનારા વિસ્ફોટને છુપાવે છે, તેથી ફરિયાદ પછી લીધેલો સ્ક્રીનશોટ નબળો પુરાવો છે. સમસ્યા દરમિયાન નમૂના લો, અને આઉટપુટ સાથે ટાઇમસ્ટેમ્પ રાખો.
અપલિંક અને તેની સામેની કતાર
ઇન્ટરફેસ કાઉન્ટરો બેન્ડવિડ્થના પ્રશ્નનો જવાબ આપે છે જે CPU આંકડા આપી શકતા નથી. તેઓ ક્ષમતાને નુકસાનથી પણ અલગ પાડે છે, અને આ જુદા જુદા નિષ્ફળતાઓ જુદા જુદા ઉપાયો સાથે છે:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitતમારી પરીક્ષા દરમિયાન તેના ફાળવેલા દરની નજીકની લિંક એ જ સમજૂતી છે, અને વધારાના CPU ની કોઈ માત્રા તેને બદલતી નથી. qdisc લીટી ઇન્ટરેક્ટિવ ટ્રાફિક માટે મહત્ત્વની વિગત ઉમેરે છે: બેકલોગ અને ડ્રોપ જણાવે છે કે પેકેટ નીકળતાં પહેલાં કતારમાં રાહ જુએ છે કે નહીં. મોટા અપલોડ હેઠળ ભરાતી કતાર એ જ લક્ષણ ઉત્પન્ન કરે છે જે લોકો દૂરના સર્વર પર આરોપ મૂકે છે, એટલે કે એવા કનેક્શન પર ધીમા કોલ જે બેન્ચમાર્કમાં હજી સારું દેખાય છે.
રીટ્રાન્સમિશન કાઉન્ટરો એ કેસ પકડે છે જ્યાં પેકેટ નીકળે છે પણ ક્યારેય સ્વચ્છ રીતે પહોંચતા નથી. જો ધીમી વિન્ડોમાં રીટ્રાન્સમિશન વધે અને ઇન્ટરફેસ ક્ષમતાની નજીક ન હોય, તો સમસ્યા હોસ્ટ પર નહીં પથમાં છે, અને એ જ શહેરમાં બીજા એન્ડપોઇન્ટ પર જવાથી મદદ નહીં મળે.
સત્ર ગણતરી માંગણી વર્ણવે છે, અનામત નહીં
દરેક જાહેર ડિરેક્ટરી અમુક સંખ્યામાં જોડાયેલા વપરાશકર્તાઓ બતાવે છે, અને તેમાંથી લગભગ કોઈ પણ તમને કહેતું નથી કે તે વપરાશકર્તાઓ શું કરી રહ્યા છે. ઇન્ટરેક્ટિવ કામ કરતા વીસ સત્રો અને મોટી ફાઇલો ખેંચતા ચાર સત્રો એક જ હાર્ડવેર પર ઘણા જુદા લોડ ઉત્પન્ન કરે છે. બીજી પેટર્ન વપરાશકર્તા ગણતરીમાં અદૃશ્ય છે, અને તે જ સાંજ બગાડે છે. તેથી સત્રની સંખ્યા માંગણીની સૂચના તરીકે વાંચવી જોઈએ, ક્યારેય અનામત ક્ષમતા વિશેના નિવેદન તરીકે નહીં.
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
તમે નિયંત્રિત કરો છો તેવા હોસ્ટ પર, સ્ટેટસ ફાઇલ ખૂટતું પરિમાણ આપે છે. OpenVPN સામયિક સ્નેપશોટ લખે છે જેમાં પ્રતિ-ક્લાયન્ટ બાઇટ કાઉન્ટરોનો સમાવેશ થાય છે, અને એ જોવા માટે પૂરતું છે કે એક જ સત્ર આખી અપલિંક માટે જવાબદાર છે કે નહીં:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusદસ સેકન્ડના અંતરે બે નમૂના તે સંચિત ગણતરીઓને પ્રતિ ક્લાયન્ટ દરમાં ફેરવે છે. એ જ માપ છે જેના માટે વપરાશકર્તા ગણતરી ઊભી રહે છે, અને એમ જ તમે શોધો છો કે એક ખોટી રીતે ગોઠવાયેલો ક્લાયન્ટ દરરોજ રાત્રે એ જ કલાકે લિંકને સંતૃપ્ત કરે છે.
પ્રતિ-સત્ર મર્યાદાઓ નીતિમાં છુપાયેલી છે
સર્વર નિષ્ક્રિય હોઈ શકે છે અને તેમ છતાં તમને બેન્ડવિડ્થ આપવાનો ઇનકાર કરી શકે છે. દર મર્યાદાઓ, પ્રતિ-ક્લાયન્ટ બેન્ડવિડ્થ કેપ્સ અને ટ્રાફિક શેપિંગ ઘણી વાર સામાન્ય નામ અથવા પૂલ દીઠ લાગુ થાય છે, તેથી એક જ ગેટવે પરના બે વપરાશકર્તાઓ ખૂબ જુદા પરિણામો મેળવી શકે છે. પદ્ધતિ સૂક્ષ્મ નથી, પણ બહારથી અદૃશ્ય છે કારણ કે બંને કિસ્સામાં ટનલ સામાન્ય રીતે ઉપર આવે છે.
શેપિંગ ટનલ ઇન્ટરફેસ પર શોધો, ભૌતિક પર નહીં. મર્યાદા વપરાશકર્તા, પ્રમાણપત્ર કે સરનામા પૂલને અનુસરે છે કે નહીં તે તપાસો. જો તમારું પરીક્ષણ ખાતું મર્યાદા વગરના પૂલમાં પડે, તો તમે તારણ કાઢશો કે સર્વર ઠીક છે અને ફરિયાદ કરનાર વપરાશકર્તા ખોટો છે. તે તારણ કોઈ તારણ ન હોવા કરતાં ખરાબ છે, કારણ કે તે ટિકિટ બંધ કરે છે.
એક નિશ્ચિત કાર્ય સાથે બે એન્ડપોઇન્ટની તુલના કરો
ક્લાયન્ટ બાજુનો પ્રયોગ હજી કરવા યોગ્ય છે, પણ ફક્ત જો ચલો નિશ્ચિત હોય. એ જ ઉપકરણ, એ જ એક્સેસ નેટવર્ક, એ જ પ્રોટોકોલ અને એ જ ગંતવ્ય ફાઇલ વાપરો, પછી સમાન અંતરે બીજા એન્ડપોઇન્ટ સામે પુનરાવર્તન કરો. રન વચ્ચે બદલાતું કોઈપણ વસ્તુ, દિવસનો સમય સહિત, પરિણામને દૂષિત કરે છે.
નિષ્ફળતાઓને સફળતાઓ જેટલી કાળજીથી નોંધો. જે શ્રેણીમાં ત્રણ એન્ડપોઇન્ટ કામ કરે છે અને એક સમયસીમા પર પહોંચે છે તે ચાર ઝડપ આંકડાઓ કરતાં વધુ માહિતીપ્રદ છે, કારણ કે તે ક્ષમતાની નહીં પથ કે નીતિની સમસ્યા તરફ ઇશારો કરે છે. દરેક કેસ ઓછામાં ઓછા બે વાર ચલાવો; શેર કરેલા નેટવર્ક પર એક ધીમો નમૂનો કંઈ સાબિત કરતો નથી.
છેલ્લે, તમે એકઠા કરેલા આંકડા તે જે દાવાને ટેકો આપે છે તેની સાથે રાખો. "આ એન્ડપોઇન્ટે જે વિન્ડોમાં બીજાએ અટકી ગયું તે જ વિન્ડોમાં ટ્રાન્સફર પૂરો કર્યો" એ સમર્થનીય છે, જ્યારે "આ એન્ડપોઇન્ટ ઝડપી છે" એ એવી દલીલને આમંત્રે છે જે હોમપેજ સ્કોરથી જીતી શકાતી નથી. OpenVPN 2.6 મેન્યુઅલ સ્ટેટસ ફાઇલ અને શેપિંગ વિકલ્પોનું દસ્તાવેજીકરણ કરે છે જો તમને હોસ્ટ બાજુની ચોક્કસ સૂચનાઓની જરૂર હોય.