On Tue, 13 Jul 1999, Scott Hess wrote:
> It would probably be worth trying a different OS. We're using FreeBSD3.1
> and 3.2, and it seems to work well. I like Linux, also, but have never
> tried to see how far Squid would go on Linux.
Squid is running on the firewall, and as such we have a very conservative
attitude towards any upgrades on that machine. The knowledge in-house (and
my own knowledge) is Linux- (and Solaris-) based, so I would definitely
upgrade to a 2.2 kernel before moving to a BSD variant. Besides, from what
I hear, most if not all of the network performance difference between
Linux and FreeBSD was removed when 2.2 was released.
> Eh, probably not worth that much, given the types of error situations you
> could get into - besides, you generally don't expect to shutdown, much less
> in a controlled fashion!
Plus, in my case, I'm talking about 10-20MB of images, sent over a 100bT
link. I have the init.d script deleting the cache metadata logfile
already, to minimize start times as much as possible for those times when
I need to restart squid.
> A similar alternative to the ramdisk would be to fully enable soft updates
> on the Squid cache partition, and then do squid -z on every startup (or,
> potentially, only on those startups without a sane shutdown involved). That
> would hopefully minimize the amount of time spent waiting for seeks due to
> write ordering.
What do you mean by "soft updates"? Other than that, it sounds like what
I'm doing. 'squid -z' doesn't work for me (strange permission problems),
so rather than fool too much with that machine, I just kill the logfile.
If the cache grows due to orphan files, I'll just set up some kind of
purge script myself.
I suppose another option for me would be to mount 'noatime' on that mount.
That might help a bit.
Received on Tue Jul 13 1999 - 15:09:28 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:47:22 MST