Číslo otázky: |
|
Otázka: | Jakým způsobem server Firebird 2.1 detekuje přerušení klientských spojení ? |
|
Odpověď: |
Pokud uživatel klientské stanice ukončí aplikaci nekorektním způsobem, například vypnutím nebo restartem počítače bez ukončení aplikace, zůstanou na straně serveru otevřená jeho spojení. K podobné situaci může dojít po výpadku proudu na klientské stanici nebo při poruše síťového spojení mezi klientem a serverem. Tato situace je nežádoucí a může pro ostatní uživatele přinést komplikace od zpomalení odezvy serveru až po nemožnost vykonat některé operace, jejichž zámky ztracený klient v době výpadku vlastnil. Aby se minimalizovaly problémy s takovým výpadkem spojené, databázový server má dvě možnosti jak ztracená spojení odhalit a uzavřít.
-
Ve Firebirdu 2.1. je doporučenou možností využítí následujících konfiguračních proměnných TCP protokolu. Jedná se o parametry se systémovou platností, ovlivňující všechny IP spojení, které daný počítač obsluhuje (přijímá).
- Windows
Parametry jsou v registru ve větvi \HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP\Parameters
Všechny parametry jsou celočíselného typu (DWORD).
Nejsou-li proměnné přítomny, platí jejich výchozí hodnoty.
KeepAliveTime - výchozí stav 7200000 (milisekund, tj. dvě hodiny), je potřeba snížit např. na 60000 (jedna minuta).
KeepAliveInterval - výchozí stav 1000 (milisekund), doporučujeme zvýšit např. na 10000 (10 sekund).
TcpMaxDataRetransmissions - výchozí stav 5 (počet opakování), lze ponechat. Windows Vista a novější mají pevně nastaveno 10 opakování.
Celková doba detekce spadlého spojení je zhruba KeepAliveTime/1000 + KeepAliveInterval/1000 * TcpMaxDataRetransmissions [s]
- Linux
Parametry jsou v proměnných v adresáři /proc/sys/net/ipv4
tcp_keepalive_time - výchozí stav 7200 (dvě hodiny), je potřeba snížit např. na 60 (jedna minuta).
tcp_keepalive_probes - výchozí stav 9 (počet opakování)
tcp_keepalive_intvl - výchozí stav 75 (sekund)
Alespoň jednu z hodnot tcp_keepalive_probes nebo tcp_keepalive_intvl je také vhodné snížit.
Celková doba detekce spadlého spojení je zhruba tcp_keepalive_time + tcp_keepalive_probes * tcp_keepalive_intvl [s]
Ve výchozím stavu trvá detekce spadlého spojení tímto způsobem přes 2 hodiny, což je pro zjištění ztracených klientů příliš dlouhá doba. Program MRP-K/S proto nastavuje tyto proměnné během instalace serveru pod Windows tak, aby se doba detekce zkrátila na cca 2-3 minuty. Pokud server instalujete sami mimo instalační program MRP-K/S, doporučujeme příslušné proměnné, případně zápisy v registru po instalaci serveru popsaným způsobem upravit.
Na platformě Linux můžete proměnné změnit například následující sekvencí příkazů, které je vhodné umístit do skriptu, který se spouští po startu počítače. Obvykle (v závislosti na distribuci) se k tomu dá použít skript /etc/rc.local nebo /etc/rc.d/rc.local :
sysctl -w net.ipv4.tcp_keepalive_time=60
sysctl -w net.ipv4.tcp_keepalive_intvl=15
sysctl -w net.ipv4.tcp_keepalive_probes=5
-
Druhou možností je konfigurační parametr DummyPacketInterval, přítomný v konfiguračním souboru firebird.conf. Je-li nastaven na hodnotu větší než nula, server zasílá klientům kontrolní pakety v intervalu zadaném v hodnotě parametru (v sekundách). Pokud klient na doručené pakety nereaguje, server spojení ukončí. Server Firebird má hodnotu tohoto parametru nastavenou na 0, takže server kontrolní pakety negeneruje. Důvodem jsou podle dokumentace problémy s implementací TCP/IP protokolu na klientských stanicích běžících pod systémem Windows, které mohou způsobit pád klientských aplikací pokud jsou aplikace delší dobu neaktivní (neprovádějí žádné operace s databází) a kontrolní pakety včas neruší. Klientské aplikace MRP-K/S se nicméně tento problém závažně nedotýká, protože používá jen malý počet spojení k databázi a navíc se neočekává, že zůstane spuštěná neaktivní po dobu několika dnů nebo týdnů. Pokud tedy databázový server nepoužíváte zároveň pro jiné aplikace které vytvářejí velký počet spojení a mohou být neaktivní po dlouhou dobu, můžete parametr změnit. Doporučujeme hodnotu 60, kterou používal i starší server Interbase. Tento způsob byl systémem MRP-K/S dříve využíván u serveru Firebird 1.5. Parametr zadáte v konfiguračním souboru firebird.conf odkomentováním řádku (odstraněním znaku # na začátku řádku) a změnou hodnoty např. takto:
DummyPacketInterval = 60
Na Linuxových serverech závisí tento způsob detekce spadlého spojení ještě na hodnotě parametru /proc/sys/net/ipv4/tcp_retries2, která určuje jak dlouho se má server pokoušet kontaktovat neodpovídajícího klienta. Pokud necháte parametr na jeho výchozí hodnotě 15 a klientský počítač zůstane po výpadku vypnutý, ukončí server spojení až po cca 17 minutách. Jestliže Vám tato prodleva nevyhovuje, je potřeba hodnotu proměnné tcp_retries2 snížit, např. na 5. Pokud po výpadku klienta počítač znovu zapnete, bývá reakce serveru daleko rychlejší - cca 3 minuty.
Upozornění: Ve Firebirdu podverze 2.1.0 je tento způsob nefunkční, jakákoliv změna parametru DummyPacketInterval z výchozí hodnoty 0 vede k ukončování spojení klientů v době nečinnosti po uplynutí zadaného intervalu. Verze Firebird 2.1.1 sice tento problém odstranila, ale obsahuje bohužel jinou chybu, v důsledku které při nenulovém nastavení proměnné DummyPacketInterval dochází k restartu serveru v průběhu dlouho trvajících operací, jako je například obnovování databází. Z tohoto důvodu nedoporučujeme způsob detekce přerušených spojení pomocí proměnné DummyPacketInterval nadále používat. Pokud jej přesto potřebujete, ověřte si, že verze serveru Firebird, kterou používáte, je alespoň 2.1.3. Verzi Firebirdu lze zjistit například z jeho ovládacího panelu Firebird 2.1 Server Manager.
Program MRP-K/S v rámci instalace serveru používá první z obou řešení, tedy změnu konfiguračních proměnných TCP protokolu, která je provedena během instalace serveru instalačním programem MRP-K/S. Na serverech s operačním systémem Linux je potřeba příslušné proměnné po instalaci serveru Firebird změnit ručně.
Další informace lze nalézt zde.
Poznámka: Použití druhého způsobu, tedy proměnné DummyPacketInterval, může jako vedlejší efekt v některých sítích vyřešit problémy se samovolným ukončováním spojení, pokud je klientská aplikace ponechána spuštěná bez aktivity. Tento problém bývá způsoben síťovými aplikacemi (firewally, antiviry) nebo prvky (routery apod.), které z důvodu uvolnění alokovaných zdrojů automaticky ukončují spojení, která nevykazují aktivitu. Standardně se takto chová například většina Linuxových firewallů, které výjimku pro spojení iniciované z vnitřní sítě udržují jen omezenou dobu po zastavení aktivity na tomto spojení. Pakety posílané serverem při nenulovém nastavení hodnoty DummyPacketInterval mohou podle našich informací tento problém odstranit, zřejmě proto, že kontrolní paket pravidelně odesílaný serverem je vyhodnocen jako probíhající komunikace a spojení je ponecháno. První způsob, tedy odesílání KeepAlive paketů podle nastavení proměnných TCP protokolu, tuto vlastnost mít nemusí, síťový prvek jim pravděpodobně "rozumí" a nebere je jako plnohodnotnou komunikaci. Lepším řešením tohoto problému je samozřejmě změna nastavení příslušné aplikace nebo síťového prvku tak, aby spojení odstraňovaly až po delší době nečinnosti (např. několik hodin), pokud je lze konfigurovat.
|
* Berte prosím v potaz, že otázka a odpověď mohou být úzce svázané s verzí programu aktuální v době zveřejnění odpovědi.
Související otázky najdete ve skupinách:
|
|