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 കൈപ്പുസ്തകം സ്റ്റാറ്റസ് ഫയലും രൂപപ്പെടുത്തൽ ഓപ്ഷനുകളും രേഖപ്പെടുത്തുന്നു.