Re: [squid-users] Anyway to tell if squid is actively using unlinkd?

 On Wed, 25 May 2011 18:29:55 -0700, Tory M Blue wrote:
> I've got weird load behavior that crops up and this box is only
> running squid. I am close to what I set my cache_dirs to in terms of
> size, so wondering if that's it.
>
> Just trying to figure out why my server will run at a load of 1 -1.5
> and next thing it's up to 5-6, no real increase in traffic.
>
> Cache_mem is high, this is a very robust.beefy server. So trying to
> figure it out.
>
> Reverse Proxy config.
> Squid 2.7STABLE9
> Fedora 12 64bit
> 16gb Mem
> 4 raid 10 15K sas drives for OS
> 8 15K sas drives in jbod config..
> ---- currently testing with 2 cache_dirs against 2 drives.
>
> Very little iowait.
>
> Resident memory for the squid process is around 6.4gb, cache_mem set
> at 4gb. We have tons of small images (3K), so I like to attempt to
> keep all hot objects in cache.
>
> high and low water for the disk were at 85 and 95%, bumped it just to

 The watermark difference and total size determine how much disk gets
 erased when it overflows. Could be lots or not much. Very likely this is
 it. When the cache_dir reached high watermark it consumes a lot more
 disk IO and CPU erasing the cache until low watermark is reached.

 Look at using COSS either way for high number of small files.

 Could also be dumping cache_mem content to the disk for some reason.
 Though why it would do that without traffic is a mystery.

> see but made really no difference. My cache dirs are just 5gb each
> (10gb total), on 150gb disks ya, but I don't really want to have to
> weed through all of these files looking for an image.

 You wade through them manually?

 Squid uses a hash, so its lookup time is good. You can tune L1/L2 for
 faster disk IO speeds with large caches.

>
> Just wondering where I can look and or what type of information would
> be helpful to see if Squid is in fact causing these spikes, vs
> something in the OS.

 strace info during a spike should be useful to show what is going on.

 Amos
Received on Thu May 26 2011 - 03:01:56 MDT