Re: [squid-users] suggestions for high-end dual-CPU config on Linux? (+tuning of current conf)

From: Joe Cooper <joe@dont-contact.us>
Date: Wed, 23 Oct 2002 04:51:14 -0500

Greg Sheard wrote:
> On Wed, 2002-10-23 at 04:23, Colin Campbell wrote:
>
>>Hi,
>>
>>I believe the general consensus to be:
>>
>>- don't do RAID, let squid load balance across the disks
>>- get FAST disks 10,000RPM or better
>>- lots of RAM
>>- dual CPU probably won't get you anything as squid is single-threaded
>>- reiserfs is better
>
>
> Also, you should probably look at using diskd for your cache
> directories; this is possibly (I may be wrong) the only way to use your
> second processor for anything significant.

Even though DiskD could use additional processors and aufs effectively
doesn't, aufs is still significantly faster even on an SMP machine. So
if you're using Linux, use aufs.

Disk I/O, while potentially a major bottleneck for Squid, is not
generally the major source of CPU contention, and off-loading the small
amount of work that can be offloaded by using DiskD isn't going to make
up for it being slower in general.

The only way to use a second processor to any real degree is to run two
Squid processes. How you split the traffic depends on your
network...And I've discussed how I've done it here on the mailing list
about a year ago. Nonetheless, it is /so/ much more beneficial to use a
faster single processor, that I hesitate to even tell people how to get
the most from a dual processor. Don't even bother. Get a honking fast
single P4 or Athlon system maxed out on RAM. Give it 3 or 4 15k disks.
  Use an aufs Squid on ReiserFS mounted noatime,notail and make sure
you've got enough file descriptors (I use 8192, usually). That's the
fastest you'll get with current hardware, without giving yourself more
headaches than you want trying to contend with two independently
configured Squid processes and the splitting of traffic.

-- 
Joe Cooper <joe@swelltech.com>
Web caching appliances and support.
http://www.swelltech.com
Received on Wed Oct 23 2002 - 03:48:40 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:10:52 MST