SQUID+ext3 +diskd --> problemy fs

[Vitezslav T. Se'm]

"Ing. Pavel PaJaSoft Janousek" wrote:

> Vitezslav T. Se'm wrote:
> > small margin.  But last time I tried (admittedly in a Red Hat 2.4.9
> > kernel--so pretty old now) I could oops it at will within a few minutes
> > with a moderate Squid workload.
>
>         Jinymi slovy, jedno jakesi nejmenovane a blize nespecifikovane jadro
> produkovane firmou RedHat melo problem... - to neni o Ext3 vs.
> Squid...:-) - u technicke debaty bych predpokladal trosku presnejsi
> argumentaci (vim Travisi, ze za to nemuzes, spis mne to v tomto kontextu
> preqapilo od Coopera)

Nikoli, Joe Cooper tento problem reprodukoval na nekolika verzich jader 2.4.0+.
Predpokladam, ze to testuje prubezne.

> > Tudiz - mnohem lepsi reseni, je pouzit jednotlive disky a na kazdy dat jeden
> > cache_dir. Squid dokaze k temto diskum pristupovat najednou a tudiz je to mnohem
> > vhodnejsi reseni. Z hlediska rychlosti je take vhodne mit filesystem naplneny max na
>
>         Existuji nejaka mereni, ktera by to dokazovala? Logika veci mi totiz rika
> presny opak:

http://www.squid-cache.org/Benchmarking/Number-of-Disks/

> a) kde se aktualne vyskytuje hlava disku vi jen radic na disku
> b) kde se aktualne zrejme pohybuje hlava disku vi jen SCSI radic,
> protoze vyrizuje (nepresne se da rici, ze serializuje - ale ne zpusobem
> FIFO) veskere I/O pozadavky na disk (u IDE tyto finty nehrozi:->)
> c) o tom, na ktery disk to nacpat rozhoduje Squid => procesor - proc
> mame ty inteligentni SCSI radice s vlastnim procesorem? K tomu, aby nam
> aplikace zraly vypocetni vykon?
>
>         Muze tyto argumenty nekdo _vecne_ napadnout?
>
> PS: Prohlasit se to da o sunkach nekterych uzivatelu, ale obecne o teto
> problematice... nevim nevim...
>
> -----------------------------------------------------------------------
> Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.

Vitezslav T. Se'm

--

It's nice to be important, but it's more important to be nice.