> 
> On 15.11 12:23, Sturgis, Grant wrote:
> > I am writing for ideas on how I can increase the performance of my 
> > squid cache.
> > 
> > I am running:
> > 
> > cache_dir aufs on ext2
> [...]
> 
> > 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.
> 
> 55% is already quite much, however that is probably not the problem.
> 
> 
> > One thing that is concerning:
> > 
> > [EMAIL PROTECTED] squid]# free -m
> >              total       used       free     shared    buffers
> > cached
> > Mem:          3778       3756         22          0        472
> > 2154
> > -/+ buffers/cache:       1129       2649
>                            ^^^^
> this says you only use a bit more than 1GB of memory.

Another shot from today:

[EMAIL PROTECTED] root]# free -m
             total       used       free     shared    buffers
cached
Mem:          3778       3758         20          0        497
2194
-/+ buffers/cache:       1065       2713
Swap:         8997        807       8190

Doesn't this say 807 MB of swap being used?  Certainly that cannot be
good.


> 
> > 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?
> 
> yes, there is high probability that changing to 
> xfs/jfs/reiserfs would help you.
> 
> > Any suggestions for things I can do to determine why my 
> cache is slow 
> > or how to make improvements in performance?
> 
> try to see how disks are loaded using 'iostat -d 1'

I don't have that command, but I will load that package (sar I believe)
this afternoon.

> 

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.

Reply via email to