RE: [squid-users] cache_swap_low and high waternmark

From: Lightfoot.Michael <Lightfoot.Michael@dont-contact.us>
Date: Thu, 1 May 2003 13:53:29 +1000

 
> Just for curiosity,
> Is there any way to prevent low water mark condition ? If I
> can check remaining
> free disk space using SNMP, and before it hits 90% If I
> delete or drop cached objects
> from cache. Than may be I never this low water mark condition.
>
Why not let squid manage its own cache? Scads of code in squid are
designed to do just that.

Unless you are using a filesystem that does not suffer from block
fragmentation (like VxFS on Solaris) or you can do regular defrags, the
problem is never going to be running out of physical disk space it is
going to be running out of free unfragmented (logical) blocks.

For this reason, the FAQ and other squid docs recommend allocating
around 80% of a filesystem to a cache_dir. If your filesystems are
large (> 2GBytes) you can probably safely make the low and high
watermarks closer together and closer to 100%, but when disk is so cheap
compared to other resources, why worry and why spend sysadmin time on
marginal things?

> Is there any way to delete or drop objects from cache ( not
> entire cache ) ? I know
> about PURGE method, it will remove one object at a time. Does
> it support wild card ?
>
Purge does not support wildcards. You have to wrap a script around it
or use some other tool (I vaguely remember one existing out there
somewhere.)

Michael Lightfoot
Unix Consultant
ISG Host Systems
Comcare
+61 2 62750680
Apologies for the rubbish that follows...
------------------------------------------------------------------------
NOTICE: This e-mail message and attachments may contain confidential
information. If you are not the intended recipient you should not use or
disclose any information in the message or attachments. If received in
error, please notify the sender by return email immediately. Comcare
does not waive any confidentiality or privilege.
Received on Wed Apr 30 2003 - 21:54:04 MDT

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