sockets disabled, out-of-fds

[Dan Lukes]

Miroslav Lachman wrote:
> Uz podruhe v relativne kratkem case se mi na jednom serveru stalo
> nasledujici:
>
> Dec  7 14:09:30 XXX kernel: sonewconn: pcb 0xfffff80185dad188: Listen
> queue overflow: 193 already in queue awaiting acceptance (4946 occurrences)

Tohle je celkem jasne - "nasluchajici" socket ma frontu prichozich 
pozadavku na navazani TCP spojeni.  Tato fronta ma nejakou delku a toto 
hlaseni rika, ze prihozi pozadavek byl zahozen, protoze na nej ve fronte 
uz nebylo misto.

> Dec  7 14:10:24 XXX kernel: [zone: pf states] PF states limit reached

Tohle pro zmenu rika, ze v PF byl vycerpan prostor pro uchovavani 
nejakych stavu. Intuitivne hadam, ze to budou stavy TCP spojeni a tedy 
jde o projev stejne veci (velky pocet prichozich pozadavku na navazani 
spojeni), jen na jine urovni.

> 2016-12-07 14:08:53: (connections.c.139) (warning) close: 55 Connection reset by peer

Behem TCP spojeni prisel od protistrany RST, tedy "abort spojeni" (misto 
normalniho uzavreni). Toreticky takove RST nemusi nutne prijit az od 
protistrany, zdrojem muze byt take firewall po ceste, vcetne tveho 
vlastniho. Nebo muze prijit od protistrany, napriklad pokud se rozhodla, 
ze jiz dele nehodla na data cekat.

> 2016-12-07 14:08:59: (server.c.1759) [note] sockets disabled, out-of-fds

Nekoukal jsem do zdrojaku, takze hadam - zrejme jde o prekroceni 
FD_SETSIZE (viz man FD_ZERO) - a to znamena prilis velky pocet 
otevrenych spojeni (zatimco predchozi hlasky byly o prilis velkem poctu 
pozadavku an otevreni dalsich spojeni).

> Takze predpokladam, ze ta sonewconn hlaska a PF states limit je az dusledek problemu Lighttpd.

Nejsme si uplne jisty. Podle vseho jde o prilis velky pocet otevrenych 
spojeni, prilis velky pocet pozadavku an otevreni dalsich spojeni.

Jasne je to, ze pocet prichozich pozadavku prevysuje pocet pozadavku, 
ktere lighttpd vyridi.

To muze znamenat proste jen prilis velky pocet prichozich pozadavku 
(velky zajem o server nebo utok), ne az tak velky pocet prichozich 
pozadavku, ale takoveho typu, ze jejich vyrizeni trva velmi dlouho (mj. 
napriklad proto, ze o velka data zada klient s pomalym spojenim, takze 
prilis dlouho trva prenos), priblem lighttpd (z nejakeho duvodu i 
normalni a male pozadavky vyrozuje velmi pomalu - napriklad jsou data na 
vzdalenem disku a problemy jsou s nim).

> Proces Lighttpd bezi, ale neodpovida

Ja myslim, ze odpovida - ale musis se s prichozim pozadavkem trefit do 
toho okamziku, kdy se ve fronte prichozich pozadavku zrovna uvolni misto 
- a pak si pockat, nez pozadavek prijde na radu a TCP spojeni je 
skutecne navazano (coz se navic musi trefit do okamziku, kdy ma lighttpd 
prostor pro navazani dalsiho spojeni) a kdy je skutecne vyrizeno.

Statisticky to muze vypadat, ze neodpovida vubec.

> "service lighttpd restart" problem vyresi.

To porad jeste nedokazuje, ze problem je nutne v nem (ale nerikam ani, 
ze neni).

Je treba zjistit jake pozadavky ma ten server "rozdelane" v okamziku, 
kdy problem nastal, zda je vubec vyrizuje (a nove jen pribyvaji moc 
rychle) nebo data nepodava vubec (pak je dobre identifikovat jaka data 
to ma problem podavat a zacit hledat proc by mel byt problem je podat).

Dan