On 22 Mar 2001 21:49:13 +0200, Mihai RUSU wrote:
>
> On 22 Mar 2001, Florin Andrei wrote:
>
> > Cite requesturi pe secunda primea squid-ul ala?
> pai faci tu calculul pentru /s dar cachemgr-ul imi spunea ca in media
> 8000-10000 de request-uri pe minut.
Deci cam 130...160 / secunda.
La mine urca pina la vreo 100...110 / secunda la orele de virf (imediat
inainte si dupa masa de prinz), dar nu e transparent, e proxy-cache
normal (dar nu cred ca e vreo diferenta).
> man io chestia aia cu queue overload nu prea am vazut-o ci alceva gen
> "checking iDns queue" cam asa ceva...
Aha. Deci *alt* bug. :-(
> > Bug #110 (daca asta e cauza) nu e din cauza de non-compliance, e din
> > cauza de coada de cereri DNS care nu se opreste din umplere atunci cind
> > trebuie. Iar cind coada e prea plina... BANG!!!
> oare?
Da.
Downloadeaza 2.4.PRE-STABLE1 si uita-te in dns.c la functia dnsSubmit().
Nu ti se pare ca imediat dupa callback trebuie un return? (inauntrul lui
if, nu in afara)
Oricum, exact asta a facut Wessels la PRE-STABLE2 si la versiunea finala
care a aparut ieri: a pus un return acolo. Insa eu sint inca pe
versiunea necorectata. :-(
> >
> > Oricum, fenomenul apare doar cind se combina doua conditii:
> > - foarte multe cereri pe secunda de la clienti
> 9000 de cereri pe minut ajung ? :)
Pai daca ai dns-ul suficient de rapid, poti sa bagi cite cereri vrei tu,
pina iti moare procesorul.
Apropo, ce load average si ce CPU usage ai pe masina aia cind urci la
150 / sec?
> > - servere DNS lente
> eh. rula dnscache. interesant este ca dupa ce l-am mutat pe bind nu a mai
> dat (ce-i drept bind-ul ala era pe alta masina si nu prea mai facea
> altceva acea masina).
Aha! Pai asta era! Noul nameserver e mult mai relaxat, deci raspunde
mult mai repede, deci nu lovesti bug-ul.
> > Uite, m-am gindit si eu la asta, si nu prea mi-e clar. Oare intr-adevar
> > daca folosesti dnsserver se reduce incarcarea pe serverele DNS?
> io zic sa incerci si tu. s-ar putea ca masuratorile mele sa nu fie prea
> corecte si schimbarea cu dnsserver-ul sa fi coincis cu bind-ul extern...
> dar io imi aduc aminte ca inainte de dnsserver (chiar pe bind) era mai
> incarcat ...
Eu sint obligat sa folosesc dnsserver, din cauza ca sint obligat sa
folosesc un anume dns search path din resolv.conf (legacy stuff).
Pina cind resolverul intern din squid n-o sa invete sa foloseasca si el
search path, eu o sa tot folosesc dnsserver aicea.
> > Eu as zice ca nu. Daca folosesti dnsserver-ele, de fapt squid foloseste
> > resolverul masinii pe care ruleaza, adica paseaza cererile dns la
> > masina, care se uita in resolv.conf si intreaba serverele DNS pe care le
> > gaseste acolo. Deci tot la serverele DNS ajungi, cu singura deosebire ca
> pai da iar tu pui in resolv.conf dnscache sau un bind...
Right.
Deci nu e o diferenta esentiala. Senzatia mea este totusi ca, in
principiu, resolverul intern e mai rapid decit dnsserver (nu ai IPC care
sa introduca intirzieri), dar nu am numere care sa arate asta clar.
> > in cazul cu dnsserver-e se mai tine cont si de search path din
> > resolv.conf (nu squid tine cont, ci masina tine cont), pe cind squid
> > fara dnsserver-e intreaba direct serverele DNS fara sa mai tina cont de
> > search path, deci s-ar putea sa fie chiar mai rapid *fara* dnsserver-e
> > (ceea ce ar fi conform si cu documentatia squid, care zice ca
> > dnsserver-ele sint "deprecated" incepind cu squid-2.3).
> > Gresesc?
> e posibil daca ne gandim ca cache-ul era impartit in 3 cache_dir-uri pe
> asyncufs de 128 procese... sau alea 128 procese fac doar scrierea si
> citirea din cache in paralel si nu rezolva si cererile in paralel
> (squid-2.3.STABLE4) ?
In 2.3 resolverul intern ar trebui sa fie ok, ar trebui sa nu se
impiedice in bucla de alte evenimente. Cel putin asa zic Wessels,
Nordstrom & Comp. ;-)
dnsserver e o smecherie veche din 2.2, pe care o foloseau pentru ca pe
atunci nu stiau sa bage cereri DNS neblocabile in programul principal.
Se pare ca intre timp au invatat cum s-o faca. Din nefericire, pe drum
au pierdut faza cu search path care imi trebuie mie... :-(
Din cite stiu (dar s-ar putea sa ma insel), thread-urile multiple din
2.3 sint doar pentru disc, nu si pentru alte smecherii. Oricum, pe Linux
e cam nashpa cu thread-urile...
Eu folosesc diskd in 2.4, care genereaza cite un proces (proces, nu
thread) pentru fiecare cache_dir, procesul principal ramine sa se ocupe
strict de partea de proxy, iar procesele child se ocupa strict de
caching (disk i/o). Modelul are eleganta teoretica, si suna rezonabil,
dar inca n-a fost exploatat complet (diskd in 2.4 nu e inca net mai
rapid decit thread-urile din 2.3), dar va fi. ;-) Teoretic, as fi putut
sa folosesc linistit async-io (deci thread-uri), pentru ca Squid-ul meu
merge pe Irix, care nu are thread-uri nashpa ca Linux-ul, dar am zis ca
what the heck, hai sa folosesc o tehnologie mai avansata. :-)
--
Florin Andrei
---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
unsubscribe from this list.
