Hi Super Users,
Many Thanks to:
Peter D. Gray" <pdg@uow.edu.au>
Karl_Sprules@acml.com
Zulkarnain Dahalan - CSSG <dzulk@csam.com.my>
and
Hendrik Visage <hvisage@is.co.za>
and special thanks to:
Toens Bueker <toens.bueker@e-trend.de>
and
Chris Miles
(Forgive me if I have missed someone ;-)
First of all sorry for submitting this summary so late....actually I was not
feeling confident enough to write this summary until now.
Briefly, I have taken following steps to handle the heavy load on my proxy
server.
1) I have increased cache disks to 8 by using cache_dir directive. This helps
as now squid can write to more drives in parallel, this solves the slow disk
I/o problem to some extent. Use of more disks spreads the load.
2) I have formatted each drive and have installed fresh filesystem using
"newfs -i 2048 /dev/rdsk/cxtxdxsx" command. There is a bug in solaris 2.6 due
to which it does not use the default parameters of newfs as mentioned in man
page. So I have forced the default bytes per inode in the command. Otherwise
squid will not write to cache directories due to fragmentation once the drive
reaches to say 80% of utilization.
3) I am using fastfs program to improve disk I/O. fastfs is a little c-program
which disables synchronous metadata updates for ufs ->
http://www.squirrel.com/squirrel/sun-stuff.html
4) I am using a separate disk (other than cache disks) for logging squid
logs.
5) If possible - use a FreeBSD- or Linux-Box for your cache.
Their filesystems are much better suited for this kind of
operation.
6) I would suggest reducing cache_mem, especially if the machine is touching
swap at all. We have ours set to only 32MB. Also more memory will always help,
we have 1.0GB in the U450.
7) Squid can put a heavy load on DNS servers. If your squid server has
resources free, run a caching name server on the squid itself, otherwise point
that server at a caching name server close by that has plenty of resources
available.
8) With more users one proxy box is not enough, one should move to multiple
proxy boxes as the users increase.
8) No. Squid will not necessarily perform better with more cpus.
9) I am using LFUDA replacement policy for max. bandwidth savings.
Further reading:
http://squid.nlanr.net/ -> Squid Users Guide -> Performance Tuning
http://statistics.www-cache.dfn.de/Projects/blast/
Adrian Cockroft's "Performance Tuning" book.
My Original Question:
I am running squid proxy server (version 2.3) on Sun Ultra Enterprise 450
with
1GB total system memory. My OS is solaris 2.6.
I have around 600 concurrent users and our IPL is 2.0Mb/s. I am running squid
in transparent-cache mode. My squid has following configuration:
REPLACEMENT POLICY= GDSF.
Connection information for squid:
Number of clients accessing cache: 360
Number of HTTP requests received: 111315
Number of ICP messages received: 0
Number of ICP messages sent: 0
Number of queued ICP replies: 0
Request failure ratio: 0.00%
HTTP requests per minute: 1133.1
ICP messages per minute: 0.0
Select loop called: 621722 times, 9.481 ms avg
Cache information for squid:
Request Hit Ratios: 5min: 46.3%, 60min: 48.3%
Byte Hit Ratios: 5min: 34.9%, 60min: 34.9%
Storage Swap size: 4146292 KB
Storage Mem size: 69124 KB
Storage Replacement Threshold: -1.000000
Mean Object Size: 7.34 KB
Requests given to unlinkd: 3418
Median Service Times (seconds) 5 min 60 min:
HTTP Requests (All): 1.62803 1.62803
Cache Misses: 2.50793 2.79397
Cache Hits: 0.01847 0.01648
Near Hits: 1.71839 1.71839
Not-Modified Replies: 0.00767 0.00767
DNS Lookups: 0.84544 0.84544
ICP Queries: 0.00000 0.00000
Resource usage for squid:
UP Time: 5894.547 seconds
CPU Time: 2391.330 seconds
CPU Usage: 40.57%
CPU Usage, 5 minute avg: 44.46%
CPU Usage, 60 minute avg: 44.14%
Maximum Resident Size: 0 KB
Page faults with physical i/o: 17977
Memory accounted for:
Total accounted: 117895 KB
File descriptor usage for squid:
Maximum number of file descriptors: 4096 (I have increaded file
descriptors from 1024 to 4096)
Largest file desc currently in use: 748
Number of file desc currently in use: 672
Files queued for open: 0
Available number of file descriptors: 3424
Reserved number of file descriptors: 100
Store Disk files open: 40
Internal Data Structures:
565806 StoreEntries
14447 StoreEntries with MemObjects
14285 Hot Object Cache Items
565225 Filemap bits set
565194 on-disk objects
Store Directory Statistics:
Store Entries : 565605
Maximum Swap Size : 14336000 KB
Current Store Swap Size: 4144469 KB
Current Capacity : 29% used, 71% free
Store Directory #0: /cache
First level subdirectories: 16
Second level subdirectories: 256
Maximum Size: 7168000 KB
Current Size: 2072236 KB
Percent Used: 28.91%
Filemap bits in use: 292642 of 524288 (56%)
Filesystem Space in use: 2107843/8705501 KB (24%)
Filesystem Inodes in use: 296758/1044736 (28%)
Flags: SELECTED
Store Directory #1: /cache1
First level subdirectories: 16
Second level subdirectories: 256
Maximum Size: 7168000 KB
Current Size: 2072233 KB
Percent Used: 28.91%
Filemap bits in use: 272381 of 524288 (52%)
Filesystem Space in use: 2107587/8705501 KB (24%)
Filesystem Inodes in use: 276497/1044736 (26%)
Flags
At the moment, proxy is serving only 150 concurrent users but soon it will
have to serve 600 concurrent users.
Now as soon as I put more load on proxy, its performance is degraded
severely.
So much so that it gets almost stuck and data, if received by any client, is
received in bursts with long pauses.
I fear that when I will make proxy to server 600 concurrent users then Http
requests per minute will jump to 4000.
Could any body please advise me how should I configure squid as well as the
OS
to handle this much load.
1)Should I add more processors. The load average at the moment varies from
0.6
- 0.9 with 150 concurrent users)
2) Should I increase/decrease the cache_mem for squid. The current value is
256 MB?
3)Do you think that a single sun box can not handle this much load?
I will appreciate if some one facing a similar scenario sends me an optimally
tuned squid configuration file.
John Black
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
S
U BEFORE POSTING please READ the FAQ located at
N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq
. and the list POLICY statement located at
M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy
A To submit questions/summaries to this list send your email message to:
N sun-managers@ececs.uc.edu
A To unsubscribe from this list please send an email message to:
G majordomo@sunmanagers.ececs.uc.edu
E and in the BODY type:
R unsubscribe sun-managers
S Or
. unsubscribe sun-managers original@subscription.address
L To view an archive of this list please visit:
I http://www.latech.edu/sunman.html
S
T
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:16 CDT