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.

> Ce hardware era pe masina aia? (procesor, memorie)
e un bull
are un procesor copermine p3 la 666
512 mb ram
2xhd scsi puse in raid0 peste care s-a pus un reiserfs (pentru cache)

> Cite request-uri pe secunda inseamna asta?
> Nu ma intereseaza cite conexiuni sint deschise la un moment dat. O
> metrica mai buna pentru un cache este numarul de request-uri pe secunda.
> Numarul de conexiuni deschise la un moment dat e o metrica ce combina de
> fapt doua fenomene diferite: numarul de cereri pe secunda, si viteza
> retelei pe upstream.
logic.

> 
> > vei avea foarte multe mesaje in cache.log de eroare de genul
> > idns: queue... o kestie ciudata rau si dupa un timp nu prea random
> > squid-ul crapa cu un mesaj de eroare (.... Assertion failed). M-am uitat
> 
> Da, asta e. Bug #110.
> 
> 2001/03/20 13:29:44| dnsSubmit: queue overload, rejecting
> adimages.go.com
> 2001/03/20 13:29:44| assertion failed: cbdata.c:184: "c != NULL"
> 
> E din cauza de cod stupid in dns.c: e o conditie la care, in caz de
> succes se executa ramura de succes, dar in caz de failure se executa
> atit ramura de failure cit si o bucata din ramura de succes.
> E suficient sa pui un return imediat inainte de sfirsitul if-ului
> (astfel incit functia sa returneze imediat dupa executia ramurii de
> failure).
> Duane Wessels are aceeasi parere (corectia la bug #110 pe squid-bugzilla
> pentru squid-2.4 face exact asta ce ti-am zis).
man io chestia aia cu queue overload nu prea am vazut-o ci alceva gen
"checking iDns queue" cam asa ceva...
2000/12/11 06:52:12| idnsCheckQueue: ID fc0: giving up after 20 tries and
117.0 seconds
2000/12/11 07:05:21| idnsCheckQueue: ID 1116: giving up after 20 tries and
114.0 seconds
2000/12/11 07:19:33| idnsCheckQueue: ID 1231: giving up after 20 tries and
117.0 seconds
2000/12/11 09:13:40| idnsCheckQueue: ID 1cfe: giving up after 20 tries and
110.0 seconds
2000/12/11 09:16:09| idnsCheckQueue: ID 1d33: giving up after 20 tries and
113.0 seconds

asta in cache.log iar dupa un timp crapa dand in stderr (nu in cache.log):
squid: rfc1035.c:370: rfc1035RRDestroy: Assertion `n > 0' failed.
Startup: Wed Jan  3 15:25:51 EET 2001
squid: rfc1035.c:370: rfc1035RRDestroy: Assertion `n > 0' failed.
Startup: Wed Jan  3 15:26:06 EET 2001
squid: rfc1035.c:370: rfc1035RRDestroy: Assertion `n > 0' failed.
Startup: Wed Jan  3 20:39:00 EET 2001
squid: rfc1035.c:370: rfc1035RRDestroy: Assertion `n > 0' failed.
Startup: Wed Jan  3 20:39:12 EET 2001
squid: rfc1035.c:370: rfc1035RRDestroy: Assertion `n > 0' failed.
Startup: Wed Jan  3 21:38:04 EET 2001
squid: rfc1035.c:370: rfc1035RRDestroy: Assertion `n > 0' failed.
Startup: Wed Jan  3 22:02:09 EET 2001
squid: rfc1035.c:370: rfc1035RRDestroy: Assertion `n > 0' failed.
Startup: Thu Jan  4 08:29:46 EET 2001
squid: rfc1035.c:370: rfc1035RRDestroy: Assertion `n > 0' failed.
Startup: Thu Jan  4 10:36:31 EET 2001
squid: rfc1035.c:370: rfc1035RRDestroy: Assertion `n > 0' failed.

sorry ca am dat asa mult text dar am vrut sa se vada ca crapa destul de
des.

> 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?

> 
> Oricum, fenomenul apare doar cind se combina doua conditii:
> - foarte multe cereri pe secunda de la clienti
9000 de cereri pe minut ajung ? :)

> - 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).

> 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 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...

> 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) ?

----------------------------
Mihai RUSU
RoEduNet Network Engineer
"... and what if this is as good as it gets ?"


---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to 
unsubscribe from this list.

Raspunde prin e-mail lui