પચ્ચીસ મિનિટનું ઉપયોગી ડેટાબેઝ કામ લગભગ કોઈ આઉટપુટ આપતું નથી, અને માર્ગના દરેક ઉપકરણથી એ પ્રવાહ નિષ્ક્રિય દેખાય છે. નિષ્ક્રિય સ્થિતિ જ એ છે જે એકઠી કરવામાં આવે છે. પછીનો અહેવાલ હંમેશા એક જ આકારનો હોય છે: ક્વેરી ચાલી રહી હતી, પછી સેશન ગાયબ થઈ ગયું, અને પરિણામ કદી પહોંચ્યું નહીં.

ચાર તપાસ નક્કી કરે છે કે શાંત સેશન ટકશે કે નહીં, અને તે સોકેટથી બહાર તરફ જાય છે. તેને ક્રમમાં કરો, કારણ કે દરેક ધારે છે કે પાછલું સ્તર પોતાનું કામ કરી રહ્યું છે.

કયો પ્રવાહ શાંત થાય છે

મહત્ત્વનું જોડાણ તે છે જે ડેટાબેઝ ટ્રાફિક વહન કરે છે, તેના પોતાના સરનામાં અને પોર્ટથી ઓળખાય છે. બીજું કંઈ તેને તાજું કરતું નથી. ગેટવેને પિંગ, એ જ હોસ્ટથી બીજું 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 કોઈ શેડ્યુલર નથી.

સંબંધિત લેખો