Nawala ang sesyon ng Oracle sa VPN? Suriin ang mga layer ng keepalive

Dalawampu't limang minuto ng kapaki-pakinabang na gawain sa database ay halos walang output, at mula sa bawat device sa landas ay mukhang hindi aktibo ang daloy na iyon. Ang hindi aktibong estado ang eksaktong kinokolekta. Ang ulat pagkatapos ay laging pareho ang hugis: tumatakbo ang query, pagkatapos ay nawala ang sesyon, at hindi kailanman dumating ang resulta.

Apat na pagsusuri ang nagpapasya kung mabubuhay ang isang tahimik na sesyon, at dumadaan sila mula sa socket pakanluran. Gawin sila nang sunud-sunod, dahil ipinapalagay ng bawat isa na ginagawa ng naunang layer ang trabaho nito.

Aling daloy ang tumatahimik

Ang mahalagang koneksyon ay ang nagdadala ng trapiko ng database, nakikilala sa sarili nitong mga address at port. Walang ibang nagre-refresh nito. Ang ping sa isang gateway, pangalawang koneksyong SQL mula sa parehong host at ang sariling tibok ng tunnel ay magkakahiwalay na daloy na may magkakahiwalay na estado sa bawat device na sumusubaybay sa kanila.

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

Ipinapakita ng listahan ng socket ang mga timer at estado ng pila para sa buhay na koneksyon, na mas nagbibigay-kaalaman kaysa sa pagsubok ng maabot. Ang mga halaga ng sysctl ay ang mga default ng kernel para sa pag-uugali ng keepalive, at ipinapaliwanag ng susunod na seksyon kung bakit maaaring hindi kailanman mailapat ang mga ito sa iyong sesyon. Ang default na hindi kailanman pumuputok ay hindi makikilala mula sa walang default talaga.

Isulat ang mga address, port at interface na ginagamit ng koneksyon. Kapag namatay ang isang sesyon, ang mga detalyeng iyon ang nagpapahintulot sa iyong tanungin ang tamang device kung ano ang ginawa nito, sa halip na itanong kung buhay ang network.

Nag-expire ba o naglilimita ang patakaran sa idle

Dalawang patakaran ang gumagawa ng parehong sintomas at nangangailangan ng magkasalungat na tugon. Ang idle timeout ay nag-aalis ng estado na maaaring na-refresh ng kwalipikadong trapiko, at mapipigilan ito ng keepalive. Ang absolutong limitasyon ng sesyon ay nag-aalis ng daloy pagkatapos ng takdang tagal anuman ang aktibidad, at walang keepalive ang makapagbabago niyon.

Itanong sa may-ari ng bawat tagapamagitan kung alin sa dalawa ang ipinapatupad nito. Ang firewall, NAT device, load balancer at cloud gateway ay maaaring lahat mag-hold ng estado, at hindi kailangang magkasundo. Ang pinakamakitid ang nagtatakda ng deadline na kailangan mong lampasan.

Sinasabi rin ng pagkakaibang iyon kung kailan itigil ang pag-tune. Kung ang patakaran ay absolutong limitasyon, ang tamang solusyon ay mas maikling yunit ng trabaho, isang job na maaaring ipagpatuloy o isang aprubadong eksepsyon, at ang pagsusuri sa ibaba ay magpapatunay lamang na walang nabago ang keepalive.

Ang switch ng socket sa likod ng mga default ng Linux

Ang keepalive ay opsyonal sa bawat socket. Inilalarawan ng mga default ng kernel kung paano kumikilos ang mga probe kapag na-enable na ng socket ang mekanismo, at hindi nila ito ini-enable para sa mga umiiral nang koneksyon. Ang aplikasyong hindi kailanman humihingi nito ay walang nakukuhang probe, anuman ang sabihin ng mga halaga ng sysctl.

Kaya't ang pagtataas lamang ng mga numero ay walang binabago para sa isang kliyente ng database. Kailangang i-enable ng kliyenteng library o ng aplikasyon ang mekanismo, at kung saan nag-aalok ang stack ng mga kontrol sa bawat koneksyon, ang limitadong setting ay mas mabuti kaysa sa pagbabago para sa buong host na nakakaapekto sa walang kaugnay na serbisyo.

Ang pagitan hanggang sa unang probe ay hindi rin timeout ng query. Ang malusog na koneksyon ay nananatiling tahimik sa pagitan ng mga probe, at ang patay na kapareha ay nakikilala ayon sa pagitan at bilang ng probe. Ang pagbasa sa tatlong halagang iyon bilang isang timeout ay humahantong sa mga setting na nakaka-detect ng pagkabigo nang huli na o masyadong sabik. Kinokontrol nila ang pag-detect, hindi ang pasensya ng aplikasyon.

Ang EXPIRE_TIME ay setting ng database, hindi pag-aayos ng network

Nag-aalok ang Oracle Net ng sarili nitong mekanismo ng pagiging buhay, na naka-configure sa epektibong profile para sa proseso sa halip na sa isang arbitraryong file na nagkataong may katulad na pangalan. Ang halaga ay ipinapahayag sa minuto.

SQLNET.EXPIRE_TIME = 5

Ang pangunahing layunin nito ay ang pag-detect sa panig ng server ng mga patay na koneksyon, at sa mga platform na sumusuporta sa pinahusay na modelo, inaayos din nito ang pag-uugali ng TCP keepalive para sa mga koneksyong iyon. Kapaki-pakinabang na katangian iyon: maaaring mag-ayos ang layer ng database ng mga probe nang hindi hinihiling sa kliyenteng aplikasyon na magbago.

Ang halimbawang halaga sa itaas ay isang koordinadong pagpili laban sa inaasahang deadline, hindi rekomendasyon. Ang dokumentadong pangkalahatang gabay ay mas mahabang pagitan, at ang tamang bilang ay nakasalalay sa naka-install na implementasyon, sa gastos ng probe na tinatanggap mo at sa aktwal na mga tuntunin ng pag-refresh sa landas. Ilagay ang setting sa profile na binabasa ng kaugnay na proseso, at kumpirmahin na nakuha ito ng proseso. Idinodokumento ng Oracle ang mga lokasyon ng profile at ang pag-uugali ng pag-detect sa reference ng parameter nito.

Subukan ang tahimik na pagitan, pagkatapos planuhin ang pagbangon

Padaanin ang isang bagong pinapayagang koneksyon sa isang tahimik na panahon na mas mahaba kaysa sa deadline na sinusubukan mong lampasan, at panoorin ang trapiko ng pagiging buhay at ang resulta ng aplikasyon. Huwag kunin ang nilalaman ng payload na hindi mo kailangan; sinasagot ng mga timer at estado ng koneksyon ang tanong.

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

Kung nawawala pa rin ang sesyon, ang deadline ay pag-aari ng device na hindi mo pa tinanong, o ang patakaran ay absolutong limitasyon. Kung mabubuhay ito, itala kung aling layer ang nagbago upang hindi ulitin ng susunod na tahimik na operasyon ang pagsisiyasat.

Sa huli, magpasiya kung ano ang mangyayari kapag talagang bumagsak ang koneksyon, dahil binabawasan ng mga pagsusuri ng pagiging buhay ang dalas at hindi kailanman inaalis ang posibilidad. Itatag ang naitalang kinalabasan ng operasyon sa database bago ito ipadalang muli: walang pinatutunayan ang pagkawala ng tugon tungkol sa kung nakumpirma ang trabaho. Para sa anumang dapat mabuhay sa pagsasara ng laptop o pag-restart ng tunnel, ang trabahong pag-aari ng server na may matibay na resulta ang mas matibay na disenyo, at ang keepalive ay hindi scheduler.