-
no i elegancko:)
w sumie w drugim poscie mialem trop dotyczacy php.ini i caly czas czepialem sie poprawnosci skryptow:)
co do TIME_WAIT - powiem tak, ze na hostach produkcyjnych - nie zdarzyly mi sie wiszace w takiej ilosci - ingerencji w konfiguracje bez mojej wiedzy nie ma; natomiast na hostach testowych na ktorych do testow jest przeinstalowywane/odinstalowane/doinstalowane czy przekonfigurowane bardzo duzo elementow i testowanych jest wiele skryptow - dochodzi do takiego momentu, ze mam takie sytuacje - ale, ze sa to hosty testowe - (przed tym stopuje najwazniejsze uslugi i wykonuje fsck -y) - reboot wystarcza i jest po klopocie lub gdy maszyna juz nie jest potrzebna - postawienie innej w pare minut:)
-
dzieki za odpowiedz.
posprawdzalem te IP z TIME_WAIT'em. wyglada na to ze w 99% pochodza z tych obrazkow.
hm. na razie zuzycie serwera jest na przyzwoitym poziomie,
ale czy naprawde nie ma mozliwosci skrocenia czasu oczekiwania?
-
btw nie wiem czy spotkales sie z tym samym w php - jesli masz sporo roznych skryptow uzywajacych roznego kodu, wielu bibliotek itd... to wielkosc procesu Apache'a w RAM rozrasta sie i nie maleje :-) php najczesciej jest jako modul dynamicznie wciagniete w apache'a i stad problemy z pamieciozernoscia - calosc o wiele lepiej widac jak wywali php do fast-cgi na przyklad - wtedy dokladnie widzisz ile procesow PHP dziala na raz i ile RAM i CPU zjadaja... wiele osob jak zobaczy wtedy co sie dzieje to zaczyna szukac innej technologii do zrobienia dynamicznych czesci witryny :P
takie moje 2 grosze na zakonczenie :)