നിങ്ങളുടെ 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 ഇപ്പോഴും ലക്ഷണത്തെ പിന്തുടരുന്നില്ലെങ്കിൽ, ഊഹത്തിൽ അപ്‌ഗ്രേഡ് ചെയ്യുന്നതിന് പകരം പാത, ആപ്ലിക്കേഷൻ പരിശോധനകളിലേക്ക് മടങ്ങുക.