Re: [squid-users] squid becomes very slow during peak hours

From: nyoman karna <balique8061_at_yahoo.com>
Date: Wed, 1 Jul 2009 01:31:09 -0700 (PDT)

I use Squid 2.7.STABLE4 on FreeBSD7.1
with these settings in squid.conf
(explained by Amos about 3 months ago):

maximum_object_size 16384 KB
minimum_object_size 0 KB
maximum_object_size_in_memory 512 KB
cache_replacement_policy lru
memory_replacement_policy lru
cache_dir aufs /webcache 163840 256 256

and it works fine with hundreds of users
(HIT ratio is above 75%)

and yes, I also change my dedicated harddrive
(for webcache) from SATA to IDE, since my problem was
the Squid is rejecting all request when it's so busy
calculating the cached object.

hope it helps

------------------------
Nyoman Bogi Aditya Karna
       IM Telkom
 http://imtelkom.ac.id
------------------------

--- On Tue, 6/30/09, Chris Robertson <crobertson_at_gci.net> wrote:

> From: Chris Robertson <crobertson_at_gci.net>
> Subject: Re: [squid-users] squid becomes very slow during peak hours
> To: squid-users_at_squid-cache.org
> Date: Tuesday, June 30, 2009, 5:25 PM
> goody goody wrote:
> > Hi there,
> >
> > I am running squid 2.5 on freebsd 7,
>
> As Adrian said, upgrade.  2.6 (and 2.7) support kqueue
> under FreeBSD.
>
> >  and my squid box respond very slow during peak
> hours. my squid machine have twin dual core processors, 4
> ram and following hdds.
> >
> > Filesystem     Size   
> Used   Avail Capacity  Mounted on
> > /dev/da0s1a    9.7G    241M 
>   8.7G     3%    /
> > devfs          1.0K 
>   1.0K     
> 0B   100%    /dev
> > /dev/da0s1f     73G 
>    35G     32G 
>   52%    /cache1
> > /dev/da0s1g     73G   
> 2.0G     65G 
>    3%    /cache2
> > /dev/da0s1e     39G   
> 2.5G     33G 
>    7%    /usr
> > /dev/da0s1d     58G   
> 6.4G     47G    12% 
>   /var
> >
> >
> > below are the status and settings i have done. i need
> further guidance to  improve the box.
> >
> > last pid: 50046;  load averages: 
> 1.02,  1.07,  1.02       
>                
>                
>                 up
> >
> > 7+20:35:29  15:21:42
> > 26 processes:  2 running, 24 sleeping
> > CPU states: 25.4% user,  0.0% nice,  1.3%
> system,  0.8% interrupt, 72.5% idle
> > Mem: 378M Active, 1327M Inact, 192M Wired, 98M Cache,
> 112M Buf, 3708K Free
> > Swap: 4096M Total, 20K Used, 4096M Free
> >
> >   PID USERNAME      THR
> PRI NICE   SIZE    RES STATE 
> C   TIME   WCPU COMMAND
> > 49819 sbt    1 105   
> 0   360M   351M
> CPU3   3  92:43 98.14% squid
> >   487 root       
>     1  96    0  4372K 
> 2052K select 0  57:00  3.47% natd
> >   646 root       
>     1  96    0 16032K 12192K select
> 3  54:28  0.00% snmpd
> >   
> SNIP
> > pxy# iostat
> >       tty     
>        da0     
>       pass0         
>    cpu
> >  tin tout  KB/t tps 
> MB/s   KB/t tps  MB/s  us ni sy in
> id
> >    0  126
> 12.79   5 
> 0.06   0.00   0 
> 0.00   4  0  1  0 95
> >
> > pxy# vmstat
> >  procs      memory   
>   page             
>       disks 
>    faults      cpu
> >  r b w     avm   
> fre   flt  re  pi  po 
>   fr  sr da0
> pa0   in   sy   cs
> us sy id
> >  1 3 0  458044 103268   
> 12   0   0   0 
>  
> 30   5   0   0 
> 273 1721 2553  4  1 95
> >   
>
> Those statistics show wildly different utilization. 
> The first (top, I
> assume) shows 75% idle (or a whole CPU in use).  The
> next two show 95%
> idle (in effect, one CPU 20% used).  How close (in
> time) were the
> statistics gathered?
>
> >
> > some lines from squid.conf
> > cache_mem 256 MB
> > cache_replacement_policy heap LFUDA
> > memory_replacement_policy heap GDSF
> >
> > cache_swap_low 80
> > cache_swap_high 90
> >
> > cache_dir diskd /cache2 60000 16 256 Q1=72 Q2=64
> > cache_dir diskd /cache1 60000 16 256 Q1=72 Q2=64
> >
> > cache_log /var/log/squid25/cache.log
> > cache_access_log /var/log/squid25/access.log
> > cache_store_log none
> >
> > half_closed_clients off
> > maximum_object_size 1024 KB
> >   
> > if anyother info required, i shall provide.
> >   
>
> The types (and number) of ACLs in use would be of interest
> as well.
>
> > Regards,
> > .Goody.
> >   
>
> Chris
>
>
Received on Wed Jul 01 2009 - 08:31:18 MDT

This archive was generated by hypermail 2.2.0 : Mon Jul 13 2009 - 12:00:03 MDT