Njëzet e pesë minuta punë të dobishme në bazën e të dhënave pothuajse nuk prodhojnë asnjë dalje, dhe nga çdo pajisje në rrugë ajo rrjedhë duket joaktive. Gjendja joaktive është pikërisht ajo që mblidhet. Raporti më pas ka gjithmonë të njëjtën formë: pyetja po ekzekutohej, pastaj sesioni u zhduk, dhe rezultati nuk mbërriti kurrë.

Katër kontrolle vendosin nëse një sesion i qetë mbijeton, dhe ato shkojnë nga socketi nga jashtë. Bëji me radhë, sepse secili supozon se shtresa e mëparshme po bën punën e vet.

Cila rrjedhë hesht

Lidhja që ka rëndësi është ajo që mbart trafikun e bazës së të dhënave, e identifikuar nga adresat dhe portat e saj. Asgjë tjetër nuk e rifreskon atë. Një ping drejt një portë, një lidhje e dytë SQL nga i njëjti host dhe rrahja e vetë tunelit janë rrjedha të ndara me gjendje të ndarë në çdo pajisje që i ndjek.

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

Lista e socketeve tregon kohëmatësit dhe gjendjen e radhës për lidhjen aktive, çka është më informuese se një test arritshmërie. Vlerat sysctl janë parazgjedhjet e kernelit për sjelljen keepalive, dhe seksioni tjetër shpjegon pse ato mund të mos zbatohen kurrë për sesionin tuaj. Një parazgjedhje që nuk aktivizohet kurrë nuk dallohet nga asnjë parazgjedhje fare.

Shkruaj adresat, portat dhe ndërfaqen që përdor lidhja. Kur një sesion vdes, janë pikërisht këto detaje që të lejojnë të pyesësh pajisjen e duhur çfarë bëri, në vend që të pyesësh nëse rrjeti ishte lart.

Nëse politika e pasivitetit skadon apo kufizon

Dy politika prodhojnë të njëjtin simptomë dhe kërkojnë përgjigje të kundërta. Një kohëmatës pasiviteti heq gjendje që trafiku kualifikues mund ta kishte rifreskuar, dhe një keepalive mund ta parandalojë atë. Një kufi absolut sesioni e heq rrjedhën pas një kohezgjatjeje fikse pavarësisht aktivitetit, dhe asnjë keepalive nuk e ndryshon këtë.

Pyet pronarin e çdo ndërmjetësi cilin nga të dy zbaton. Një firewall, një pajisje NAT, një balancues ngarkese dhe një portë cloud mund të mbajnë të gjithë gjendje, dhe nuk duhet të bien dakord. Më i ngushti vendos afatin që duhet të kalosh.

Ky dallim të tregon gjithashtu kur të ndalesh së rregulluari. Nëse politika është një kufi absolut, zgjidhja e saktë është një njësi pune më e shkurtër, një punë e rinovueshme ose një përjashtim i miratuar, dhe kontrolli më poshtë thjesht do të konfirmojë që keepalive nuk bënë asnjë ndryshim.

Çelësi i socketit prapa parazgjedhjeve të Linux

Keepalive është opsional për socket. Parazgjedhjet e kernelit përshkruajnë si sillen sondat pasi një socket të ketë aktivizuar mekanizmin, dhe ato nuk e aktivizojnë atë për lidhjet ekzistuese. Një aplikacion që nuk e kërkon kurrë nuk merr sonda, çfarëdo që thonë vlerat sysctl.

Kjo është arsyeja pse rritja e numrave vetëm nuk ndryshon asgjë për një klient baze të dhënash. Biblioteka e klientit ose aplikacioni duhet të aktivizojë mekanizmin, dhe aty ku stiva ofron kontrolle për çdo lidhje, një cilësim i kufizuar ia kalon një ndryshimi për të gjithë hostin që prek shërbime të palidhura.

Intervali deri në sondën e parë nuk është gjithashtu një kohëmatës pyetjeje. Një lidhje e shëndetshme mbetet e qetë midis sondave, dhe një partner i vdekur njihet sipas intervalit dhe numrit të sondave. Leximi i këtyre tre vlerave si një kohëmatës i vetëm është mënyra se si njerëzit arrijnë në cilësime që e zbulojnë dështimin ose shumë vonë ose shumë me nxitim. Ato kontrollojnë zbulimin, jo durimin e aplikacionit.

EXPIRE_TIME është cilësim i bazës së të dhënave, jo rregullim rrjeti

Oracle Net ofron mekanizmin e vet të gjallërisë, i konfiguruar në profilin efektiv për procesin dhe jo në një skedar arbitrar që ndodh të ketë një emër të ngjashëm. Vlera shprehet në minuta.

SQLNET.EXPIRE_TIME = 5

Qëllimi kryesor i tij është zbulimi në anën e serverit i lidhjeve të vdekura, dhe në platformat që mbështesin modelin e përmirësuar ai rregullon gjithashtu sjelljen keepalive të TCP për ato lidhje. Kjo është një veti e dobishme: shtresa e bazës së të dhënave mund të organizojë sonda pa i kërkuar aplikacionit klient të ndryshojë.

Vlera ilustruese më sipër është një zgjedhje e koordinuar kundrejt një afati të supozuar, jo një rekomandim. Udhëzimi i përgjithshëm i dokumentuar është një interval më i gjatë, dhe numri i saktë varet nga zbatimi i instaluar, nga kostoja e sondave që pranoni dhe nga rregullat reale të rifreskimit në rrugë. Vendos cilësimin në profilin që lexon procesi përkatës, dhe konfirmo që procesi e ka marrë atë. Oracle dokumenton vendndodhjet e profilit dhe sjelljen e zbulimit në referencën e parametrave.

Testo intervalin e qetë, pastaj planifiko rikuperimin

Lëre një lidhje të re të lejuar të kalojë nëpër një periudhë të qetë më të gjatë se afati që po përpiqesh të kalosh, dhe vëzhgo trafikun e gjallërisë dhe rezultatin e aplikacionit. Mos kap përmbajtje ngarkese që nuk të duhet; kohëmatësit dhe gjendja e lidhjes e përgjigjen pyetjen.

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

Nëse sesioni zhduket përsëri, afati i përket një pajisjeje që nuk e ke pyetur ende, ose politika është një kufi absolut. Nëse mbijeton, shëno cila shtresë ndryshoi, që operacioni i qetë i radhës të mos e përsëritë hetimin.

Më në fund, vendos çfarë ndodh kur lidhja bie vërtet, sepse kontrollet e gjallërisë e ulin shpeshtësinë dhe nuk e heqin kurrë mundësinë. Përcakto rezultatin e regjistruar të operacionit të bazës së të dhënave përpara se ta dërgosh përsëri: humbja e përgjigjes nuk provon asgjë nëse puna u konfirmua. Për çdo gjë që duhet t’i mbijetojë mbylljes së një laptopi ose rinisjes së një tuneli, një punë në pronësi të serverit me një rezultat të qëndrueshëm është dizajni më i fortë, dhe një keepalive nuk është planifikues.

Artikuj të ngjashëm