On 22 Mar 2001, Florin Andrei wrote:
> 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).
nici io :)
>
> > 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. :-(
:(
> 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. :-(
>
man io te cred ca chiar nu am timp de download si uitat in surse acum, asa
ca te cred pana la proba contrarie (apropos de un flame de-al nostru de
mai demult)
> Pai daca ai dns-ul suficient de rapid, poti sa bagi cite cereri vrei tu,
> pina iti moare procesorul.
mdeah sau ajungi la limite de fd-uri..
apropos tu cum ai rezolvat limita de fd-uri a squid-ului ? ca io am
modificat prin libc printr-un include la SET_FDSIZE (sau cam asa
ceva) apoi am facut ulimit si la compilare si cand pornesc squid-ul...
>
> Apropo, ce load average si ce CPU usage ai pe masina aia cind urci la
> 150 / sec?
>
well, ajungea pe la 3-4 load average.
dar cred ca reiserfs-ul peste RAID0 peste 2x SCSI ajuta mult ca io am
incercat de curand pe o masina muult mai puternica (un dual p3 la 900) si
aveam load average de 2 la 1000 de conexiuni (dar era pe ext2 ide udma66)
heh, scsi rulz
> Aha! Pai asta era! Noul nameserver e mult mai relaxat, deci raspunde
> mult mai repede, deci nu lovesti bug-ul.
pai da. acum pe un bull echivalent cu cache-ul (doar ca are 256 mb
ram) ruleaza ns-ul ala si cred ca se plictiseste de moarte.
> 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.
nashpa.
> 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.
pai da dar ma intreb e in stare sa rezolva mai multe query-uri simultan
klumea (desi ar trebui daca e nonblocking).
> 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... :-(
dnsserver-ele alea nu fac si cache ?
>
> 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...
care-i faza cu threadurile ?
> 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. :-)
>
simpatica idea cu diskd-ul dar io sunt mai retinut cu privire la noile
versiuni de software (kernel 2.4.x, squid-2.4.x, bind-9.x.y ), prefer sa
las sa se "coaca" putin.
----------------------------
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.
