VPN വഴി Oracle സെഷൻ വിച്ഛേദിക്കപ്പെട്ടോ? keepalive പാളികൾ പരിശോധിക്കുക

ഇരുപത്തിയഞ്ച് മിനിറ്റ് ഉപയോഗപ്രദമായ ഡാറ്റാബേസ് ജോലി ഏതാണ്ട് ഒരു ഔട്ട്പുട്ടും നൽകുന്നില്ല, പാതയിലെ ഓരോ ഉപകരണത്തിൽ നിന്നും ആ പ്രവാഹം നിഷ്ക്രിയമായി തോന്നുന്നു. നിഷ്ക്രിയാവസ്ഥ തന്നെയാണ് ശേഖരിക്കപ്പെടുന്നത്. തുടർന്നുള്ള റിപ്പോർട്ടിന് എപ്പോഴും ഒരേ ആകൃതി: ക്വറി പ്രവർത്തിക്കുകയായിരുന്നു, പിന്നീട് സെഷൻ അപ്രത്യക്ഷമായി, ഫലം ഒരിക്കലും എത്തിയില്ല.

നാല് പരിശോധനകൾ ശാന്തമായ സെഷൻ നിലനിൽക്കുമോ എന്ന് തീരുമാനിക്കുന്നു, അവ സോക്കറ്റിൽ നിന്ന് പുറത്തേക്ക് പോകുന്നു. അവ ക്രമത്തിൽ ചെയ്യുക, കാരണം ഓരോന്നും മുൻ പാളി അതിന്റെ ജോലി ചെയ്യുന്നു എന്ന് അനുമാനിക്കുന്നു.

ഏത് പ്രവാഹം ശാന്തമാകുന്നു

പ്രധാനമായ കണക്ഷൻ ഡാറ്റാബേസ് ട്രാഫിക് വഹിക്കുന്നതാണ്, അതിന്റെ സ്വന്തം വിലാസങ്ങളും പോർട്ടുകളും കൊണ്ട് തിരിച്ചറിയപ്പെടുന്നു. മറ്റൊന്നും അതിനെ പുതുക്കുന്നില്ല. ഗേറ്റ്വേയിലേക്ക് പിംഗ്, അതേ ഹോസ്റ്റിൽ നിന്നുള്ള രണ്ടാമത്തെ SQL കണക്ഷൻ, ടണലിന്റെ സ്വന്തം ഹൃദയമിടിപ്പ് എന്നിവ വെവ്വേറെ പ്രവാഹങ്ങളാണ്, അവയെ ട്രാക്ക് ചെയ്യുന്ന ഓരോ ഉപകരണത്തിലും വെവ്വേറെ അവസ്ഥയുണ്ട്.

ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

സോക്കറ്റ് പട്ടിക ജീവനുള്ള കണക്ഷന്റെ ടൈമറുകളും ക്യൂ അവസ്ഥയും കാണിക്കുന്നു, ഇത് എത്തിച്ചേരൽ പരീക്ഷയെക്കാൾ കൂടുതൽ വിവരം നൽകുന്നു. sysctl മൂല്യങ്ങൾ keepalive പെരുമാറ്റത്തിനുള്ള കേണൽ ഡീഫോൾട്ടുകളാണ്, അടുത്ത ഭാഗം അവ നിങ്ങളുടെ സെഷനിൽ ഒരിക്കലും ബാധകമാകാത്തത് എന്തുകൊണ്ടെന്ന് വിശദീകരിക്കുന്നു. ഒരിക്കലും പ്രവർത്തിക്കാത്ത ഡീഫോൾട്ടിനെ ഒരു ഡീഫോൾട്ടും ഇല്ലാതിരിക്കുന്നതിൽ നിന്ന് വേർതിരിക്കാനാവില്ല.

കണക്ഷൻ ഉപയോഗിക്കുന്ന വിലാസങ്ങളും പോർട്ടുകളും ഇന്റർഫേസും എഴുതിവയ്ക്കുക. സെഷൻ മരിക്കുമ്പോൾ, അത് എന്ത് ചെയ്തു എന്ന് ശരിയായ ഉപകരണത്തോട് ചോദിക്കാൻ ഈ വിശദാംശങ്ങളാണ് സഹായിക്കുന്നത്, നെറ്റ്‌വർക്ക് പ്രവർത്തിച്ചിരുന്നോ എന്ന് ചോദിക്കുന്നതിന് പകരം.

നിഷ്ക്രിയതാ നയം അവസാനിക്കുന്നുണ്ടോ അതോ പരിമിതപ്പെടുത്തുന്നുണ്ടോ

രണ്ട് നയങ്ങൾ ഒരേ ലക്ഷണം സൃഷ്ടിക്കുകയും വിപരീത പ്രതികരണങ്ങൾ ആവശ്യപ്പെടുകയും ചെയ്യുന്നു. നിഷ്ക്രിയതാ കാലപരിധി യോഗ്യമായ ട്രാഫിക് പുതുക്കാമായിരുന്ന അവസ്ഥ നീക്കുന്നു, keepalive അത് തടയാം. സെഷന്റെ സമ്പൂർണ പരിധി പ്രവർത്തനം പരിഗണിക്കാതെ നിശ്ചിത കാലയളവിന് ശേഷം പ്രവാഹം നീക്കുന്നു, ഒരു keepalive അത് മാറ്റുന്നില്ല.

ഓരോ ഇടനിലക്കാരന്റെയും ഉടമയോട് രണ്ടിൽ ഏതാണ് നടപ്പാക്കുന്നതെന്ന് ചോദിക്കുക. ഫയർവാൾ, NAT ഉപകരണം, ലോഡ് ബാലൻസർ, ക്ലൗഡ് ഗേറ്റ്വേ എന്നിവയ്ക്കെല്ലാം അവസ്ഥ സൂക്ഷിക്കാം, അവ യോജിക്കേണ്ടതില്ല. ഏറ്റവും ഇടുങ്ങിയത് നിങ്ങൾ തോൽപ്പിക്കേണ്ട സമയപരിധി നിശ്ചയിക്കുന്നു.

ഈ വ്യത്യാസം എപ്പോൾ ട്യൂണിംഗ് നിർത്തണം എന്നും പറയുന്നു. നയം സമ്പൂർണ പരിധിയാണെങ്കിൽ, ശരിയായ പരിഹാരം ചെറിയ ജോലി യൂണിറ്റ്, വീണ്ടും തുടങ്ങാവുന്ന ജോലി അല്ലെങ്കിൽ അംഗീകരിച്ച ഒഴിവാക്കൽ ആണ്, താഴെയുള്ള പരിശോധന keepalive ഒന്നും മാറ്റിയില്ല എന്ന് മാത്രം സ്ഥിരീകരിക്കും.

Linux ഡീഫോൾട്ടുകൾക്ക് പിന്നിലെ സോക്കറ്റ് സ്വിച്ച്

keepalive ഓരോ സോക്കറ്റിനും ഓപ്ഷണലാണ്. കേണൽ ഡീഫോൾട്ടുകൾ സോക്കറ്റ് സംവിധാനം സജീവമാക്കിയ ശേഷം പ്രോബുകൾ എങ്ങനെ പെരുമാറുന്നു എന്ന് വിവരിക്കുന്നു, അവ നിലവിലുള്ള കണക്ഷനുകൾക്ക് അത് സജീവമാക്കുന്നില്ല. ഒരിക്കലും ആവശ്യപ്പെടാത്ത ആപ്ലിക്കേഷന് ഒരു പ്രോബും ലഭിക്കുന്നില്ല, sysctl മൂല്യങ്ങൾ എന്ത് പറഞ്ഞാലും.

അതിനാൽ അക്കങ്ങൾ കൂട്ടുന്നത് മാത്രം ഡാറ്റാബേസ് ക്ലയന്റിന് ഒന്നും മാറ്റുന്നില്ല. സംവിധാനം ക്ലയന്റ് ലൈബ്രറി അല്ലെങ്കിൽ ആപ്ലിക്കേഷൻ സജീവമാക്കണം, സ്റ്റാക്ക് ഓരോ കണക്ഷനും നിയന്ത്രണങ്ങൾ നൽകുന്നിടത്ത്, ബന്ധമില്ലാത്ത സേവനങ്ങളെ ബാധിക്കുന്ന മുഴുവൻ ഹോസ്റ്റ് മാറ്റത്തെക്കാൾ പരിമിതമായ ക്രമീകരണം മികച്ചതാണ്.

ആദ്യ പ്രോബ് വരെയുള്ള ഇടവേളയും ക്വറി കാലപരിധിയല്ല. ആരോഗ്യകരമായ കണക്ഷൻ പ്രോബുകൾക്കിടയിൽ ശാന്തമായിരിക്കും, മരിച്ച പങ്കാളി പ്രോബ് ഇടവേളയും എണ്ണവും അനുസരിച്ച് തിരിച്ചറിയപ്പെടുന്നു. ഈ മൂന്ന് മൂല്യങ്ങളും ഒരു കാലപരിധിയായി വായിക്കുന്നത് വളരെ വൈകിയോ വളരെ തിരക്കിലോ പരാജയം കണ്ടെത്തുന്ന ക്രമീകരണങ്ങളിലേക്ക് നയിക്കുന്നു. അവ തിരിച്ചറിയലിനെ നിയന്ത്രിക്കുന്നു, ആപ്ലിക്കേഷന്റെ ക്ഷമയെയല്ല.

EXPIRE_TIME ഡാറ്റാബേസ് ക്രമീകരണമാണ്, നെറ്റ്‌വർക്ക് അറ്റകുറ്റപ്പണിയല്ല

Oracle Net അതിന്റെ സ്വന്തം ജീവനക്ഷമതാ സംവിധാനം നൽകുന്നു, അത് പ്രക്രിയയുടെ ഫലപ്രദമായ പ്രൊഫൈലിൽ ക്രമീകരിക്കപ്പെടുന്നു, യാദൃശ്ചികമായി സമാനമായ പേരുള്ള ഏതോ ഫയലിൽ അല്ല. മൂല്യം മിനിറ്റുകളിൽ പ്രകടിപ്പിക്കുന്നു.

SQLNET.EXPIRE_TIME = 5

അതിന്റെ പ്രധാന ലക്ഷ്യം സെർവർ വശത്ത് മരിച്ച കണക്ഷനുകൾ കണ്ടെത്തുകയാണ്, മെച്ചപ്പെട്ട മാതൃക പിന്തുണയ്ക്കുന്ന പ്ലാറ്റ്ഫോമുകളിൽ ആ കണക്ഷനുകൾക്കുള്ള TCP keepalive പെരുമാറ്റവും ക്രമീകരിക്കുന്നു. ഇത് ഉപയോഗപ്രദമായ സ്വഭാവമാണ്: ഡാറ്റാബേസ് പാളിക്ക് ക്ലയന്റ് ആപ്ലിക്കേഷനോട് മാറാൻ ആവശ്യപ്പെടാതെ പ്രോബുകൾ ക്രമീകരിക്കാം.

മുകളിലെ ഉദാഹരണ മൂല്യം അനുമാനിച്ച സമയപരിധിക്കെതിരായ ഏകോപിത തിരഞ്ഞെടുപ്പാണ്, ശുപാർശയല്ല. രേഖപ്പെടുത്തിയ പൊതു മാർഗനിർദേശം നീണ്ട ഇടവേളയാണ്, ശരിയായ സംഖ്യ ഇൻസ്റ്റാൾ ചെയ്ത നടപ്പാക്കലിനെയും നിങ്ങൾ സ്വീകരിക്കുന്ന പ്രോബ് ചെലവിനെയും പാതയിലെ യഥാർത്ഥ പുതുക്കൽ നിയമങ്ങളെയും ആശ്രയിച്ചിരിക്കുന്നു. ക്രമീകരണം ബന്ധപ്പെട്ട പ്രക്രിയ വായിക്കുന്ന പ്രൊഫൈലിൽ ഇടുക, പ്രക്രിയ അത് എടുത്തു എന്ന് ഉറപ്പാക്കുക. Oracle പ്രൊഫൈൽ സ്ഥാനങ്ങളും തിരിച്ചറിയൽ പെരുമാറ്റവും തന്റെ പാരാമീറ്റർ റഫറൻസിൽ രേഖപ്പെടുത്തുന്നു.

ശാന്ത ഇടവേള പരീക്ഷിക്കുക, പിന്നീട് വീണ്ടെടുപ്പ് ആസൂത്രണം ചെയ്യുക

നിങ്ങൾ തോൽപ്പിക്കാൻ ശ്രമിക്കുന്ന സമയപരിധിയെക്കാൾ നീണ്ട ശാന്ത കാലയളവിലൂടെ പുതിയ അനുവദനീയമായ കണക്ഷൻ കടത്തിവിടുക, ജീവനക്ഷമതാ ട്രാഫിക്കും ആപ്ലിക്കേഷൻ ഫലവും നിരീക്ഷിക്കുക. നിങ്ങൾക്ക് വേണ്ടാത്ത പേലോഡ് ഉള്ളടക്കം പിടിക്കരുത്; ടൈമറുകളും കണക്ഷൻ അവസ്ഥയും ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.

ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"

സെഷൻ ഇപ്പോഴും അപ്രത്യക്ഷമായാൽ, സമയപരിധി നിങ്ങൾ ഇനിയും ചോദിക്കാത്ത ഉപകരണത്തിനുള്ളതാണ്, അല്ലെങ്കിൽ നയം സമ്പൂർണ പരിധിയാണ്. അത് നിലനിന്നാൽ, ഏത് പാളി മാറി എന്ന് രേഖപ്പെടുത്തുക, അടുത്ത ശാന്ത പ്രവർത്തനം അന്വേഷണം ആവർത്തിക്കാതിരിക്കാൻ.

അവസാനം, കണക്ഷൻ യഥാർത്ഥത്തിൽ വീഴുമ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്ന് തീരുമാനിക്കുക, കാരണം ജീവനക്ഷമതാ പരിശോധനകൾ ആവൃത്തി കുറയ്ക്കുന്നു, സാധ്യത ഒരിക്കലും നീക്കുന്നില്ല. വീണ്ടും അയയ്ക്കുന്നതിന് മുമ്പ് ഡാറ്റാബേസ് പ്രവർത്തനത്തിന്റെ രേഖപ്പെടുത്തിയ ഫലം ഉറപ്പാക്കുക: മറുപടി നഷ്ടപ്പെടുന്നത് ജോലി സ്ഥിരീകരിക്കപ്പെട്ടോ എന്നതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ലാപ്ടോപ്പ് അടയ്ക്കുന്നതോ ടണൽ പുനഃപ്രവർത്തനമോ അതിജീവിക്കേണ്ട എല്ലാത്തിനും, സെർവറിന്റെ ഉടമസ്ഥതയിലുള്ള ദീർഘകാല ഫലമുള്ള ജോലി ശക്തമായ രൂപകൽപ്പനയാണ്, keepalive ഒരു ഷെഡ്യൂളറല്ല.