Apache Tomcat: vyčerpání TCP spojení

[jane.d]

Ahoj,

jedná se spíše o takovou zajímavost a nečekám, že mi tady pomůžete najít konkrétní řešení.

Na Win Server 2012 R2 mi běží Tomcat 8.5, pod kterým běží další 3 webové aplikace. V celku mám problém s tím, že v systemu se hromadí TCP spojení (procesu tomcat) na místní smyčce.... časem jejich počet překročí 65 tisíc a dojde k vyčerpání možných portu. Ten počet zřejmě více míně narůsta v úměru využití daných (nebo aspoň jedné) aplikace, která pod tomcatem běží.

Pro ukázku přes $ Get-NetTCPConnection vyjel spojení (viz příloha)

Je možné, že by to mohlo být někdo v systému Windows, respektivě někde v nastavení networku?

Ty spojení jsem analyzoval přes wireshark. Dokola to posílá to samé. Jedná pouze o jeden bajt (konkrétně hex(54))

[Reklama]

[neregistrovany]

Je možné, že by to mohlo být někdo v systému Windows, respektivě někde v nastavení networku?

Podle toho co pisete ta spojeni vyvolava tomcat, takze bych to primarne ladil tam.

[listoper]

Tomcat sam od sebe takovy kraviny delat nebude.
To se chce podivat do tech aplikaci co delaji...
Nekde si to proste otevira sockety a neco posila... Proc? Co je to zac?

[neregistrovany]

Tomcat sam od sebe takovy kraviny delat nebude.

Blbe jsem to napsal, mel jsem na mysli to co bezi v tomcatu. Proste at nehleda chybu v OS...

[PanVP]

Blbe jsem to napsal

Že si nedáte s tím raděním pokoj, ve vedlejším vláknu radíte stoletý software, tady ...jste prý nebyl dobře pochopen...

Zkuste napsat něco svéprávného, jako třeba: "Protože asi nejste autor těchto programů, rozdělte aplikace do samostatných instancí Tomcatu, pokud to lze. Zjistíte konkrétní aplikaci, která to způsobuje. Dále, spojení vždy vede odněkud někam, podle cílového portu pak v konfiguračních souborech možná naleznete konkrétní zdroj problému."

Ono je dost možné, že to nepůjde opravit, možná se pro určitou činnost vždy vytváří nový objekt, který znovu a znovu navazuje spojení na.... ale pak lze pravidelně, třeba o půlnoci, tuto JEDNU problematickou službu restartovat. Což samozřejmě není stejně dobré, jako opravit chybu, ale o poznání lepší, než nechat vyčerpat všechna spojení.

[Reklama]

[jane.d]

.... "Protože asi nejste autor těchto programů, rozdělte aplikace do samostatných instancí Tomcatu, pokud to lze. Zjistíte konkrétní aplikaci, která to způsobuje. Dále, spojení vždy vede odněkud někam, podle cílového portu pak v konfiguračních souborech možná naleznete konkrétní zdroj problému."

Ono je dost možné, že to nepůjde opravit, možná se pro určitou činnost vždy vytváří nový objekt, který znovu a znovu navazuje spojení na.... ale pak lze pravidelně, třeba o půlnoci, tuto JEDNU problematickou službu restartovat. Což samozřejmě není stejně dobré, jako opravit chybu, ale o poznání lepší, než nechat vyčerpat všechna spojení.

Ano, momentálně se problém řeší na denní bázi restartu. Problém je, že si nemohu dovolit rozdělit applikace do jednotlivých instancí tomcatu. Nemůžu je ani přesunout jinam, kde si to sice dovolit mohu, ale nebudou řádně fungovat kvůli absenci okolních služeb + licence. Ale je pravda, že když budu un-deploy(ovat) jednotlivé applikace v tomcatu, tak pokud bude zdrojem jedna z nich, měla by vzít všechny TCP spojení sebou. Toto ukončení sice může trvat pořádně dlouho, ale za otestování to rozhodně stojí. Není to moc, ale získat přesnější lokalizaci problému je posun. Díky

[PanVP]

un-deploy(ovat) jednotlivé applikace v tomcatu

Mňo, zajímavá myšlenka, ale abyste si nepřidělal problémy.
Předtím bych si určitě udělal velmi dobrou zálohu   

Můžete zveřejnit výstup z netstatu nebo nějakého lepšího monitoru všech spojení a v jakém jsou stavu?
V konfiguračních souborech by mohlo být uvedené číslo portu, možná dokonce s IP adresou.
Třeba 127.0.0.1:12345

Obvykle se jedná o připojování k nějaké službě, licenční, db, errorlog, možná systémová služba.
(Tato idea se mi náramně líbí, ale úplně to nedopovídá výstupu v z přílohy.)

V konfiguraci by každopádně někde mohla být uvedena IP adresa, možná i s nějakým portem.

Případně, Tomacat může logovat každé odchozí spojení, navíc jsou nástroje, které zobrazují která aplikace co vytváří.
Přes "Tomcat performance metrics" by neměl být problém najít vám vyhovující monitorovací nástroj a zdrojovou aplikaci.
Jen se obávám, že nalezení zdroje nepostačí, oddělením aplikace jsem vám chtěl nabídnout řešení.

Dále, naposledy jsem psal věci do Tomcatu okolo roku 2012, proto jsem se nechtěl původně vůbec vyjadřovat.

A také, když se podívám blíž na ty porty... zajímavé.

[Jiří Havel]

Něco podobného jsem už viděl. Jestli nějakou z těch appek psali Izraelci, tak bych se koukal primárně tam.

[Pavlus73]

.... "Protože asi nejste autor těchto programů, rozdělte aplikace do samostatných instancí Tomcatu, pokud to lze. Zjistíte konkrétní aplikaci, která to způsobuje. Dále, spojení vždy vede odněkud někam, podle cílového portu pak v konfiguračních souborech možná naleznete konkrétní zdroj problému."

Ono je dost možné, že to nepůjde opravit, možná se pro určitou činnost vždy vytváří nový objekt, který znovu a znovu navazuje spojení na.... ale pak lze pravidelně, třeba o půlnoci, tuto JEDNU problematickou službu restartovat. Což samozřejmě není stejně dobré, jako opravit chybu, ale o poznání lepší, než nechat vyčerpat všechna spojení.

Ano, momentálně se problém řeší na denní bázi restartu. Problém je, že si nemohu dovolit rozdělit applikace do jednotlivých instancí tomcatu. Nemůžu je ani přesunout jinam, kde si to sice dovolit mohu, ale nebudou řádně fungovat kvůli absenci okolních služeb + licence. Ale je pravda, že když budu un-deploy(ovat) jednotlivé applikace v tomcatu, tak pokud bude zdrojem jedna z nich, měla by vzít všechny TCP spojení sebou. Toto ukončení sice může trvat pořádně dlouho, ale za otestování to rozhodně stojí. Není to moc, ale získat přesnější lokalizaci problému je posun. Díky

Aplikace běžící na Tomcat by mělo stačit reloadnout, pokud to budete zkoušet, měla by se Vám ta spojení ukončit.

[jane.d]

Můžete zveřejnit výstup z netstatu nebo nějakého lepšího monitoru všech spojení a v jakém jsou stavu?
V konfiguračních souborech by mohlo být uvedené číslo portu, možná dokonce s IP adresou.
Třeba 127.0.0.1:12345

Obvykle se jedná o připojování k nějaké službě, licenční, db, errorlog, možná systémová služba.
(Tato idea se mi náramně líbí, ale úplně to nedopovídá výstupu v z přílohy.)

V konfiguraci by každopádně někde mohla být uvedena IP adresa, možná i s nějakým portem.

Případně, Tomacat může logovat každé odchozí spojení, navíc jsou nástroje, které zobrazují která aplikace co vytváří.
Přes "Tomcat performance metrics" by neměl být problém najít vám vyhovující monitorovací nástroj a zdrojovou aplikaci.
Jen se obávám, že nalezení zdroje nepostačí, oddělením aplikace jsem vám chtěl nabídnout řešení.

Dále, naposledy jsem psal věci do Tomcatu okolo roku 2012, proto jsem se nechtěl původně vůbec vyjadřovat.

A také, když se podívám blíž na ty porty... zajímavé.

Výstup z tomcatu by vypadal zcela stejně. Akorát s tímhle nástrojem šlo hezky filtrovat spojení podle PID.  Všechna spojení jsou established. Na destinačních portech nic v systému nenaslouchá (aspoň v době výpisu). Je to celé divné. Jako by se ten požadavek točil dokola.

V konfiguraci rozhodně není uvednené žadné spojení s těmito čísly portu.

Nakonec to asi tedy budu muset oddělit. Jen to nemůžu rozhodnout sám.

[PanVP]

Měl byste využít inkluze a jít pomáhat postiženým dětem do školy, tam můžete radit i bez znalostí.

Případně si můžete nainstalovat Tomcat, zde http://tomcat.apache.org/ a autorovi tohoto postu ukázat, jak zjistí, který z kontejnerů v Tomcatu otvírá ta spojení. Rozhodně byste mě příjemně překvapil.

Nicméně, zatím z vás padají jen nesmyslné výkřiky, blbosti a radíte používat zastaralé, možná zavirované programy: https://forum.root.cz/index.php?topic=21952.msg318789;topicseen#new

[PanVP]

Nakonec to asi tedy budu muset oddělit. Jen to nemůžu rozhodnout sám.

Ano, skutečně to vypadá, jako by se to připojovalo samo na sebe.
Velmi zajímavé chování. Bez znalosti funkce toho programu mohu říct jen Hmmmm.
Třeba to je logické chování, opravdu nevím.

Pokud to není jen na vás, asi bych se pokusil najít a vyzkoušet jeden z monitorů prostředků, mělo by být vidět, co je za tento problém zodpovědné. Nebo alespoň nastavit logování, na FINEST/ALL by mohly být vidět i otvírané porty.
Nicméně, už je to poměrně dlouho, co jsem Tomcatem pracoval a verzi 8.5 neznám prakticky vůbec.

Je dost dobře možné, že vám dodavatel poskytne opravenou verzi nebo poradí parametr, který problém vyřeší.

Nastavení logování - inspirovat se můžete například zde (jsou tam i ukázky logu):
https://stackoverflow.com/questions/4119213/how-to-set-level-logging-to-debug-in-tomcat

Nemusím vám říkat, že takové logování může mít negativní dopad na funkci služby resp. vytížení serveru.

Osobně, možná bych si napsal Powershellový skript, který od spuštění zaznamená každé další otevření portu pro naslouchání. Tj. výstupem skriptu je port 12345 otevřen v 11:20. A zároveň připíše poznámku do logu Tomcatu echo ****** port >> log.tomcatu  Totiž, log bude nejspíš obrovský, tak aby se v tom člověk nemusel tolik hrabat. (A nebo použít nějaký z vhodných už hotových nástrojů.)

A nebo se naučit s nějakým z těch nástrojů na monitorování prostředků pro Tomcat