RE: [squid-users] Slow Squid

Perhaps it's completely off base, but would you be wiling to share a
sampling of the regular expressions you are using?

CPU utilization at the sites I was having trouble would hover around 15-20%
and spike to over 90% sporadically. The only way this was visible was by
watching top. Average CPU usage stayed about %60, and the select loop never
took more than 200ms avg to execute. Service times were in the 1 second
range for hits and up to 3 seconds for misses during peak times.

Of course, the problem sites had over 50 complex regular expressions and
were running Squid on a AMD K6-3 450Mhz, accessing the internet over
satellite, so the problem was exaggerated, but pruning the expressions has
had a dramatic effect on service time.

On the other hand, your box was using 700 MB of swap yesterday and is using
800 today. Perhaps it is I/O bound.

One other thing to look at is DNS service time. It's monitorable in MRTG
(cacheDnsSvcTime.5 & cacheDnsSvcTime.60) and would have a detrimental effect
if it is slow.

Chris

-----Original Message-----
From: Sturgis, Grant [mailto:Grant.Sturgis@arraybiopharma.com]
Sent: Tuesday, November 16, 2004 10:30 AM
To: Chris Robertson; squid-users@squid-cache.org
Subject: RE: [squid-users] Slow Squid

>
> You state that response time is slow, but not which. Is that
> average, misses, near misses or hits? What are each of the
> other rates?

I am referring to the median response time for all requests.
Hits range up to 800 - 900 ms during peak times.
Misses range up to 1500 ms during peak times.
Near misses (304 - Not Modified) range up to 800 - 900 ms during peak
times.

All of these fall down to acceptable levels (300 - 400 ms) during
non-peak times.
>
> Where are you getting your CPU Utilization numbers from?
> (top, squidclient mrg:info, MRTG)
>
CPU utilization comes from feeding an awk-ed excerpt of /proc/stat into
MRTG.

> What is your cache_mem line set to?

cache_mem 128 MB

>
> How much bandwidth do you have available? How much is being used?

3 Mbps of which we usually peak at about 1600 Kbps.

>
> One thing that really bit me was over-use of the url_regex
> acl combined with fairly complex regular expressions. That's
> not likely to be the problem here, but it might be something
> to look into.

I do have a fair number of url_regex acls, but I think their impact
would show up in CPU.

>
> Chris

Thanks for the reply, Chris.

Grant
------------------------

>
> -----Original Message-----
> From: Sturgis, Grant [mailto:Grant.Sturgis@arraybiopharma.com]
> Sent: Monday, November 15, 2004 10:24 AM
> To: squid-users@squid-cache.org
> Subject: [squid-users] Slow Squid
>
>
> Greetings List,
>
> I am writing for ideas on how I can increase the performance
> of my squid cache.
>
> I am running:
>
> RHEL ES 3.0
> cache_dir aufs on ext2
> squid-2.5.STABLE3-6.3E
> adzapper version 3.3 with wrapzap
> Two cache_dirs totalling 42.4 GB
>
>
> The hardware is:
>
> Dell PE 1650
> 2-Intel PIII 1133 MHz
> 4 GB RAM
>
> The symptom is that during our peak utilization periods, when
> HTTP requests get over about 750/min, the response time gets
> very slow, over 800 ms or so. I understand that squid is
> single threaded, but we are running a number of the
> redirector processes and it seems that the CPU workload is
> distributed fairly well. This is determined by examining
> /proc/stat with MRTG. Neither CPU seems to reach above 55%
> utilization so I do not think the system is CPU bound.
>
> One thing that is concerning:
>
> [root@proxy squid]# free -m
> total used free shared buffers
> cached
> Mem: 3778 3756 22 0 472
> 2154
> -/+ buffers/cache: 1129 2649
> Swap: 8997 715 8282
>
> Do you think this is significant? Should I adjust squid.conf
> to reduce this memory usage?
>
> Also, I do understand that reiserfs is a recommended file
> system over ext2; do you think it will make a large
> difference to change this?
>
> Any suggestions for things I can do to determine why my cache
> is slow or how to make improvements in performance?
>
> Thank you in advance,
>
> Grant
>

Pardon this rubbish:

This electronic message transmission is a PRIVATE communication which
contains
information which may be confidential or privileged. The information is
intended
to be for the use of the individual or entity named above. If you are not
the
intended recipient, please be aware that any disclosure, copying,
distribution
or use of the contents of this information is prohibited. Please notify the
sender of the delivery error by replying to this message, or notify us by
telephone (877-633-2436, ext. 0), and then delete it from your system.
Received on Tue Nov 16 2004 - 13:02:39 MST