On Wed, 25 May 2011 20:27:05 -0700, Tory M Blue wrote:
On Wed, May 25, 2011 at 8:01 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx>
wrote:
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.
Kind of what I thought but iowait didn't show enough to cause cpu
backup, so I was leary. CPU cycles sure, but the squid process shows:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30766 squid 20 0 6284m 6.1g 3068 S 13.9 38.8 91:51.50 squid
However most of today the resident memory sat at 6.4gb, as did all my
squid servers. So figured this is kind of the high end for memory
during busy times. Now it's dropped to 6.1gb, so I'm guessing we are
slowing down and thus squid is slowly shrinking its in memory
footprint.
Look at using COSS either way for high number of small files.
Yes, I tried this and it was a complete fail. Load went through the
roof. Was a complete failure. this server should be complete
overkill
for squid, 12 cores, 16gb mem, 12 15K sas drives. Even my boxes that
are using all 8 15K sas drives, have this weird load thang, (and
let's
be honest, 4-5 load is nothing, but it's the weird spike and not
knowing what is causing the load and if it's something I can fix, is
the real issue).
Have tried various raid levels, including 0. Using LVM across all 8
disks, to match squid 4K write/read block size so that the VG/LVM
would write across all 8 disks equally etc.
earlier Coss config attempts
#### coss cache file system ####
#cache_dir coss /cache1/coss 30000 max-size=256000 block-size=8192
<--initial
#cache_dir coss /cache1/coss 3000 max-size=256000 block-size=2048
<--2nd testl
#cache_dir coss /cache2/coss 3000 max-size=256000 block-size=2048
<-2nd
#cache_dir coss /cache3/coss 3000 max-size=256000 block-size=2048
<-2nd
#cache_dir coss /cache4/coss 3000 max-size=256000 block-size=2048
<-2nd
#cache_swap_log /cache/%s
#### coss cache file system ####
Could also be dumping cache_mem content to the disk for some reason.
Though
why it would do that without traffic is a mystery.
Misunderstood, or mistyped. This was during a peak period, but seems
to happen without significant increase in traffic. Like load is 4-5
now, and we are beyond peak.
ââsquid(30763)âââsquid(30766)âââunlinkd(30767)
â ââ{squid}(30768)
â ââ{squid}(30769)
â ââ{squid}(30770)
â ââ{squid}(30771)
â ââ{squid}(30772)
â ââ{squid}(30773)
â ââ{squid}(30774)
â ââ{squid}(30775)
â ââ{squid}(30776)
â ââ{squid}(30777)
â ââ{squid}(30778)
â ââ{squid}(30779)
â ââ{squid}(30780)
â ââ{squid}(30781)
â ââ{squid}(30782)
â ââ{squid}(30783)
â ââ{squid}(30784)
â ââ{squid}(30785)
â ââ{squid}(30786)
â ââ{squid}(30787)
â ââ{squid}(30788)
â ââ{squid}(30789)
â ââ{squid}(30790)
â ââ{squid}(30791)
Hold up a minute. This diagram worries me. Squid-2 should not have any
{squid} entries. Just helpers with their own names.
Are they helpers running with the process name of "squid" instead of
their own binary names like unlinkd?
Or are they old squid which are still there after something like a
crash?
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?
No, :) just didn't want the system even with hash to have to deal
with a ton of files that are mostly stale within 10-30 minutes.
Squid uses a hash, so its lookup time is good. You can tune L1/L2
for faster
disk IO speeds with large caches.
l1/l2 cache? Have not considered or looked into it. New concept for
me :)
Sorry terminology mixup.
L1 L2 values on the cache_dir line. Sub-directories within the dir
structure.
The URL hash is mapped to a 32-bit binary value which then gets split
into FS path: path-root/L1/L2/filename
cache_dir type path-root size L1 L2
Tuned to larger values to decrease file count in each directory. To
avoid iowait on ext-like FS while the disk scans inodes for a particular
filename in the L2 directory.
Amos
