problemy s Lighttpd na FreeBSD 6.0

[Miroslav Lachman]

Divacky Roman wrote:
[...]
> no.... ja ti muzu akorat tak poradit jak to zkusit oddebugovat...
> 
> budto muzes zkusit pustit zkusebne ten lighttpd pod ktrace, ale to asi
> nepujde pac mu za chvilku dojde logovaci misto. nebo muzes zkusit
> hwpmc - s tim jsem si nikdy nehral, ale snad by to mohlo pomoct.
> nebo si nekde zkusebne nainstaluj -current, opatchuj to na podporu dtrace
> a v tom dtrace si zjisti co se deje.

V debugovani jsem hodne slabej, moc tam tem vypisum nikdy nerozumim 
(parkrat jsem videl vypis truss / ktrace a "nic" mi to nereklo), navic 
pustit pod tim tohle, to by asi nebyl dobry napad. Je to produkcni 
stroj, se kterym si nemuzu moc hrat a datove prutoky jsou tam vazne 
znacne, testovaci s podobnou konfiguraci nemam k dispozici :(

> pripadne i samotny fbsd kernel se da sprovoznit s profilovanim a to by
> ti mohlo napovedet (i kdyz analyza rozhodne nebude trivialni) na cem to vazne.

[...]

> nemas nejak poddimenzovane $neco? nevim, ale web ktery obsluhuje az 300mbps
> to uz neni uplne male ne? nepotrebuje to nejaky spesl tuning? (otazka do plena)

Kdybych tak vedel, co je $neco, tak bych i rad odpovedel. Koukal jsem po 
netu na nejaky tuning site a jedine, co jsem nasel a zkusil nastavit:
net.inet.tcp.sendspace=65536
net.inet.tcp.recvspace=32768

Puvodne byly hodnoty obracene a nekde jsem nasel i doporuceni jit s 
recvspace na jeste mnohem nizsi hodnoty (okolo 4k), ale to uz si moc 
netroufam, protoze mi tak uplne neni jasne, co presne tyhle hodnoty 
ovlivnuji a jaky to ma dopad na provoz site. (pokud by mi to nekdo 
zdejsi dokazal dobre vysvetlit, budu jedine rad)

>>2006-11-04 23:00:02: (connections.c.588) connection closed: write failed 
>>on fd 81
>>2006-11-04 23:00:03: (server.c.1148) NOTE: a request for 
>>/690f2254338267ee9101f9ec6a4be976/454d0ca9/X-Isle_Demo_V.0.1.exe timed 
>>out after writing 73955 bytes. We waited 180 seconds. If this a problem 
>>increase server.max-write-idle
>>
>>Ta posledni hlaska (server.max-write-idle) se tam vyskytuje hodne casto, 
>>ale to je, predpokladam, spis problem klienta, ktery prestal prijimat 
>>data, ne?
> 
> 
> no ja bych rekl ze ta hlaska je konsekvence toho predtim... httpd nemuze
> odesilat data a pote co se to timeoutne tak zahlasi todlencto

Ta posledni hlaska se tam vyskytuje velice casto (treba kazdou minutu), 
ty predesle jen obcas (tak jednou za hodinu, nekdy mene, nekdy casteji, 
podle provozu), takze bych spis rekl, ze je to to, co pise Dan - klient 
ukonci spojeni.

>>Oba vyse uvedene problemy bych rad nejak vyresil, bohuzel ani poradne 
>>nevim, po cem patrat. Pokud by mi tu nekdo dokazal poradit, po cem zacit 
>>v systemu patrat, pripadne jestli by to slo (ten pokles datoveho toku) 
>>resit nejakym tuningem systemu, budu rad za kazdou radu.
> 
> 
> no.. mne tak napada... pokud server loguje hlasky typu "sendfile: broken pipe 32"
> tak neni tam zaple nejake debugovani atd.? pokud jo tak to na produkci
> zkus vypnout...

Debug zapnuty neni.

Zatim jsem to vyresil (a zda se ze uspesne) bud tou zmenou sysctl, ale 
spis jeste tim, ze jsem v konfiguraci lighttpd.conf nastavil:
server.max-worker = 4

je to SMP stroj s dvema CPU (a v pripade HTT jeste dalsi 2 virtualni CPU)

Tim se v systemu misto jednoho procesu lighttpd objevi 4 a kazdy 
obsluhuje "ctvrtinu" konekci. Tudiz nevznikne tak velky pocet konekci na 
jeden proces a zatim to jede dobre, nedochazi k tomu omezeni rychlosti.
Na druhou stranu ted nemam k dispozici presne statistiky vyuziti 
Lighttpd, protoze ty jsou ted pro kazdy proces zvlast a neni moznost 
identifikovat, kdy se mi vraci statistika pro ktery proces (url je jen 
jedna), takze je ani nemohu secist :o(