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