വലിയ അപ്‌ലോഡുകൾക്കിടയിൽ VPN വിച്ഛേദിക്കുന്നു: ആദ്യം ക്യൂ വായിക്കുക
നിറഞ്ഞ അപ്‌ലോഡ് ക്യൂ നിയന്ത്രണ ട്രാഫിക്കിനെയും ആപ്ലിക്കേഷനുകളെപ്പോലെ വൈകിപ്പിക്കുന്നു. ഒഴിഞ്ഞതും ഭാരമുള്ളതുമായ പെരുമാറ്റം താരതമ്യം ചെയ്യുക, തുടർന്ന് ഒരു കാര്യം മാറ്റി പരിശോധന ആവർത്തിക്കുക.
ടണൽ ദിവസം മുഴുവൻ സ്ഥിരമായിരിക്കും, പിന്നെ വലിയ അപ്‌ലോഡ് തുടങ്ങുമ്പോഴെല്ലാം വിച്ഛേദിക്കുന്നു. ഇന്ററാക്ടീവ് അഭ്യർത്ഥനകൾ ആദ്യം കുടുങ്ങുന്നു, ക്ലയന്റ് സമയപരിധി കഴിഞ്ഞതായി റിപ്പോർട്ട് ചെയ്യുന്നു, കൈമാറ്റം തീരുമ്പോൾ ബന്ധം തിരികെ വരുന്നു. ഈ മാതൃക വിദൂര സെർവർ നിലച്ചതല്ല, ക്യൂവിനെയും പ്രോസസ്സിംഗിനെയുമാണ് സൂചിപ്പിക്കുന്നത്, കാരണം സെർവറിന് സമയത്തിന് മറുപടി നൽകാൻ അവസരം ഒരിക്കലും ലഭിച്ചില്ല. ചെയ്യേണ്ടത് നിയന്ത്രിത ഭാരത്തിൽ ഇത് പുനർനിർമ്മിച്ച് ശരിയായ കൗണ്ടറുകൾ വായിക്കുകയാണ്.
ഓരോ പ്രവർത്തനത്തിനും ഒരു വേരിയബിൾ മാറ്റുക, എൻഡ്‌പോയിന്റ് സ്ഥിരമായി നിർത്തുക.
ആവർത്തിക്കാവുന്ന ഭാര താരതമ്യം നിർമ്മിക്കുക
ലിങ്ക് ഒഴിഞ്ഞിരിക്കുമ്പോൾ അടിസ്ഥാന രേഖ രേഖപ്പെടുത്തുക: റൗണ്ട്-ട്രിപ്പ് സമയം, കുറച്ച് ആപ്ലിക്കേഷൻ അഭ്യർത്ഥനകൾ, ടണലിന്റെ സ്വന്തം ഇവന്റ് ലോഗ്. പിന്നെ അറിയാവുന്ന വലിപ്പത്തിൽ ഒരു അപ്‌ലോഡ് തുടങ്ങി അത് പ്രവർത്തിക്കുമ്പോൾ അതേ അളവുകൾ ആവർത്തിക്കുക. എൻഡ്‌പോയിന്റ്, ക്ലയന്റ്, പരിശോധനാ ലക്ഷ്യം എന്നിവ മാറ്റാതെ നിർത്തുക, കാരണം അവയിൽ രണ്ടെണ്ണം ഒരുമിച്ച് മാറ്റുന്നത് നിങ്ങൾക്ക് ഒന്നും പറയുന്നില്ല.
ഏത് ഇവന്റാണ് ആദ്യം പ്രത്യക്ഷപ്പെടുന്നതെന്ന് ശ്രദ്ധിക്കുക. ഏതെങ്കിലും പിശകിന് മുൻപ് കൂടുന്ന റൗണ്ട്-ട്രിപ്പ് സമയം ക്യൂവിനെ സൂചിപ്പിക്കുന്നു; സ്ഥിരമായ കാലതാമസത്തോടെയുള്ള കഠിന സമയപരിധി മറ്റെന്തോ സൂചിപ്പിക്കുന്നു, ഉദാഹരണത്തിന് കീ പുതുക്കൽ അല്ലെങ്കിൽ അക്കൗണ്ടിലെ നടപടി. രണ്ട് മാതൃകകളും വ്യത്യസ്ത അടുത്ത ഘട്ടങ്ങളിലേക്ക് നയിക്കുന്നു. എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് നിരീക്ഷണം എഴുതിവയ്ക്കുക.
ഔട്ട്‌പുട്ട് സമയ മുദ്രകളോടെ സൂക്ഷിക്കുക, അപ്പോൾ ഭാരമുള്ളതും ഒഴിഞ്ഞതുമായ പ്രവർത്തനങ്ങൾ വരി തോറും താരതമ്യം ചെയ്യാം.
വേഗതയല്ല, ക്യൂ വായിക്കുക
ഉപഭോക്തൃ ലിങ്കുകൾ പ്രൊവൈഡറുടെ ഉപകരണങ്ങളിൽ പാക്കറ്റുകൾ ബഫർ ചെയ്യുന്നു, നിറഞ്ഞ അപ്‌ലോഡ് ക്യൂ ടണലിനെ ജീവനോടെ നിർത്തുന്ന ചെറിയ നിയന്ത്രണ പാക്കറ്റുകൾ ഉൾപ്പെടെ എല്ലാം വൈകിപ്പിക്കുന്നു. ഉയർന്ന സംഖ്യ റിപ്പോർട്ട് ചെയ്യുന്ന വേഗതാ പരിശോധന ആ കാലതാമസത്തെക്കുറിച്ച് വളരെ കുറച്ചേ പറയുന്നു, അതുകൊണ്ടാണ് ഒഴിഞ്ഞ ലിങ്കിൽ പരിശോധന വിജയിക്കുന്നതും നിറഞ്ഞ ലിങ്ക് പരാജയപ്പെടുന്നതും.
ping -c 20 -i 0.2 203.0.113.10 mtr -rwc 20 203.0.113.10 tc -s qdisc show dev eth0 ss -ti dst 203.0.113.10 nstat -az | grep -E 'Retrans|Timeout'
ഭാരമുള്ള കാലതാമസത്തിന്റെ സംഖ്യകൾ ഒഴിഞ്ഞതുമായി താരതമ്യം ചെയ്യുക. പാക്കറ്റ് നഷ്ടമില്ലാതെ പത്തിലധികം മില്ലിസെക്കൻഡിൽ നിന്ന് നൂറുകളിലേക്കുള്ള കുതിപ്പ് ക്യൂ ആണ്; സ്ഥിരമായ കാലതാമസത്തോടെയുള്ള നഷ്ടം മറ്റൊരു തകരാറിനെ സൂചിപ്പിക്കുന്നു.
ഉപകരണവും നിയന്ത്രണ പാതയും പരിശോധിക്കുക
എൻക്രിപ്ഷനും ഫോർവേഡിംഗും പ്രോസസറിന്റെ സമയം എടുക്കുന്നു, ചെറിയ റൗട്ടറിനോ ചൂടിൽ പരിമിതപ്പെടുത്തിയ ലാപ്‌ടോപ്പിനോ തിരക്കിലിരിക്കുമ്പോൾ പാക്കറ്റുകൾ വീഴ്ത്താം. ഒരു പ്രോസസിന്റെ ശതമാനമല്ല, മൊത്തത്തിലുള്ള ഭാരം നോക്കുക, കാരണം കെർണൽ ഫോർവേഡിംഗും ഇന്ററപ്റ്റ് കൈകാര്യം ചെയ്യലും ആളുകൾ സാധാരണ നോക്കുന്നിടത്ത് പ്രത്യക്ഷപ്പെടുന്നില്ല.
uptime mpstat -P ALL 1 3 dmesg | grep -i -E 'thermal|throttl' journalctl -u openvpn-server@server --since '10 min ago' | tail -20
ക്ലയന്റിന്റെ സമയപരിധി ഷെഡ്യൂൾ ചെയ്ത കീ പുതുക്കലിനോട് അല്ലെങ്കിൽ സെഷൻ നയത്തിലെ ഒരു ഇവന്റിനോട് ഒത്തുപോകാം. ഇവന്റുകളുടെ ക്രമത്തിന് ആപ്ലിക്കേഷന്റെ പിശക് സന്ദേശം മാത്രമല്ല, ക്ലയന്റിന്റെ സ്വന്തം ലോഗ് വായിക്കുക.
ഒരു കാര്യം മാറ്റി ആവർത്തിക്കുക
പ്ലാറ്റ്ഫോം പിന്തുണയ്ക്കുന്നിടത്ത് അപ്‌ലോഡ് നിരക്ക് പരിമിതപ്പെടുത്തുകയോ ബൾക്ക് ട്രാഫിക്ക് ഇന്ററാക്ടീവ് ട്രാഫിക്കിന് താഴെ തരംതിരിക്കുകയോ ചെയ്യുക, ക്യൂ ഒരിക്കലും നിറയാതിരിക്കാൻ. പിന്നെ അതേ ജോലിഭാരം ആവർത്തിച്ച് മുൻപത്തെപ്പോലെ അതേ മൂന്ന് സംഖ്യകൾ താരതമ്യം ചെയ്യുക. വേഗതാ പരിശോധന മെച്ചപ്പെടുത്തിയിട്ടും സമയപരിധി നിലനിർത്തുന്ന മാറ്റം ഒന്നും ശരിയാക്കിയിട്ടില്ല.
എല്ലായിടത്തും സമയപരിധി ഉയർത്തുന്നതും എൻക്രിപ്ഷൻ ദുർബ്ബലമാക്കുന്നതും ഏത് അതിർത്തി പരാജയപ്പെട്ടുവെന്ന് തിരിച്ചറിയാതെ ലക്ഷണം അപ്രത്യക്ഷമാക്കുന്ന രണ്ട് മാറ്റങ്ങളാണ്. രണ്ടും അറ്റകുറ്റപ്പണിയല്ല. രണ്ടും പരാജയത്തെ കൂടുതൽ വൈകി, കാരണം കണ്ടെത്താൻ ബുദ്ധിമുട്ടുള്ളിടത്തേക്ക് മാറ്റുന്നു.
പുതിയ ഒരു അഭ്യർത്ഥനയും ഉപയോക്താവ് യഥാർത്ഥത്തിൽ ആശ്രയിക്കുന്ന വീണ്ടും ബന്ധിപ്പിക്കൽ സ്വഭാവവും പരിശോധിച്ച് അവസാനിപ്പിക്കുക. പരാതിക്ക് കാരണമായ ഭാരത്തിന് കീഴിലുള്ള സ്ഥിരത മാത്രമാണ് രേഖപ്പെടുത്താൻ യോഗ്യമായ ഫലം.