> Well, I based my argument from the 10 instances of reverse proxies
> I'm running. It has 266,268,230 objects and 3.7 TB of space. CPU
> usage is always around 0.2 according to ganglia. So unless you have
> some other statistics to prove CPU is that important, I'm stick w/ my
> argument that disk and RAM is way more important that CPU.
>
ok, reverse proxy does not so very much, so sure it depends on what you do with the
machine
> mike
>
> At 03:41 AM 7/6/2008, Michel wrote:
>
>> > The cpu doesn't do any IO, it's WAITING for the disk most of the
>> > time. If you want fast squid performance, CPU speed/count is
>> > irrelevant; get more disks and ram. When I mean more disk, I mean
>> > more spindles. eg: 2x 100GB will is better than a 200GB disk.
>> >
>>
>>
>>well well, get prepared ... take your cpu out and then you'll see
>>who is waiting
>>forever :)
>>
>>even if IO wait is an issue it is or better WAS one on "old" giant
>>lock systems
>>where the cpu was waiting until getting the lock on a busy thread
>>because there was
>>only ONE CPU and even on multi-cpu-systems there was only one core a
>>time bound to
>>the kernel
>>
>>to get around this issue good old posix aio_*calls where used in
>>order not to wait
>>for a new lock what I believe is squid's aufs cache_dir model which
>>is still very
>>good and even better on modern smp machines and even with squid's
>>not-smp-optimized
>>code - you really can drain disks to their physical limits - but
>>that is not all
>>
>>SMP (modern) works around the global giant lock, the kernel is not
>>anymore limited
>>to get one core a time
>>
>>SMP sistems are going to work with spin locks (Linux) and sleep
>>locks (freebsd)
>>where the linux way is focusing thread synchronizing which is going to be
>>outperformanced by the sleep lock mechanism. Spin locks certainly
>>still waste cpu
>>while spinning what sleeplocks do not, cpu is free to do other work.
>>This was kind
>>of benefit for Linux last couple of years when freebsd was in deep
>>developing of
>>it's new threading model which is now on top I think, especially in
>>shared memory
>>environments.
>>
>>basicly is it not important if you use one or ten disks, this you
>>should consider
>>later as fine tuning but the threading model works the same, for one
>>or two disks,
>>or for 2 our 32Gigs of memory - so you certainly do NOT get araound
>>your IO-Wait
>>with more memory or more disk when the cpu(s) can not handle it
>>"waiting for locks"
>>as you say ...
>>
>>So IMO your statement is not so very true anymore, with a modern
>>SMP-OS on modern
>>smp hardware of course.
>>
>>michel
>>
>>
>>
>>
>>****************************************************
>>Tecnologia Internet Matik http://info.matik.com.br
>>Sistemas Wireless para o Provedor Banda Larga
>>Hospedagem e Email personalizado - e claro, no Brasil.
>>****************************************************
>
>
>
>
>
>
>
>
> A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
> Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
>
michel
****************************************************
Tecnologia Internet Matik http://info.matik.com.br
Sistemas Wireless para o Provedor Banda Larga
Hospedagem e Email personalizado - e claro, no Brasil.
****************************************************
Received on Mon Jul 07 2008 - 10:34:20 MDT
This archive was generated by hypermail 2.2.0 : Mon Jul 07 2008 - 12:00:04 MDT