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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
