[KLUG Members] Squid setup recommendation
Tony Gettig
members@kalamazoolinux.org
Mon, 15 Dec 2003 10:51:03 -0500
Thanks a ton for the info, Bruce. I really hadn't thought of running more than
one box. I'm not sure it's an option given hardware availability, but I will
definitely look into it. I'm thinking a seperate partition for logs might be a
good idea? (My little ipcop box at home ran out of space for logs once...not cool!)
How about a partition layout like this?
/boot
/var/log
/var/cache
/
I just subscribed to the squid lists. Squid config seems to be an art in and of
itself. :)
Tony
Quoting Bruce Smith <bruce@armintl.com>:
> > I'm putting together a new caching box for work. Squid is high on the list,
> and
> > I've been charged with putting together a box for testing that, if the test
> goes
> > well, will probably be put into production.
> >
> > The hardware: HP ProLiant DL360, 2 GB RAM, dual 2.something gig Xeon CPU's,
> dual
> > 72 GB 10k SCSI drives. I can hardware RAID the disks, but I'm not sure I
> want to
> > given the massive amount of disk activity this box is destined for.
> >
> > The people: anywhere from 500 to 2,000 concurrent users, with the potential
> for
> > up to 5,000+ in the event of a news event like 9/11.
>
> Wow. You are about 20+ TIMES more users than my squid server, so my
> answers may or may not apply. (YMMV :)
>
> > I'm planning to use SuSE 9 with squid transparently. I think I can handle
> squid
> > and the other little packages that we intend to mix in with it (already
> tested
> > on a smaller scale), but I'm not sure about sizing the partitions. Is one
> file
> > system better than another for caching? How many partitions? How big?
> Should I
> > mirror the drives? I need the best performance with just a dash of fault
> > tolerance. :)
>
> For filesystems, I'd try ReiserFS first since it's good at handling
> small files, which is what squid does a lot of.
>
> Size/partitions, give yourself as much room as possible for cache.
> I can't help you with optimal sizing for something that large.
>
> > The config of the box will be backed up frequently in case it
> > needs to be rebuilt.
>
> I don't know why the config will change very often, once you have it up
> and running well. Everything but the cache should stay fairly static
> (and you don't need to backup the cache). So, I don't know of a reason
> for periodic backups.
>
> > Are there any squid configuration parms that I should be aware for a
> deployment
> > of this size? Any "gotchas" to look out for? Any on-going administrative
> > bummers? Cool tools for administration? I'd like to run the package that
> comes
> > with SuSE and can be updated with the provided tools, but I can compile
> and
> > install from source if necessary. Any arguments in favor of one over the
> other?
>
> You definitely need to optimize the config. Read through the squid
> config (lots of comments) and tune it to your hardware (sizes, etc.).
> I'm sure you can do better manually than a general GUI config.
> (you could use the GUI config output as a starting point)
>
> Also tune your Linux box for optimal performance. Stuff like mounting
> partitions with noatime parameters, etc. See Adam's performance tuning
> presentation on the KLUG site for all kinds of goodies like that.
>
> As far as hardware RAID, if configured correctly it can speed up disk
> access (like if you stripe your drives). It might be worth considering.
>
> One thing to watch out for, is your log files are going to grow REALLY
> LARGE, REALLY FAST. Make sure you have available disk space in that
> partition, rotate/nuke them often, etc.
>
> For that many users, you might want to look into multiple squid servers
> (peers). Something I've never had to worry about here! :-)
>
> It wouldn't hurt to ask your questions on the squid mailing list. You
> may run into someone who runs a huge site like yours who could be a lot
> more help.
>
> - BS
>
>
> _______________________________________________
> Members mailing list
> Members@kalamazoolinux.org
>
>
--
Tony Gettig
Voiceovers, PGP key, and more at
http://gettig.net