Thank you very much for your concerns!
Now, we have the 2GB physical memory per Squid server and the 64GB
Physical Disk(Hitachi Disk Array-DF300), so I allocated cache_mem 
as 896MB and was using the 15 cache_dirs on Disk array.
But, All Squid Servers(EP3000*3) are very slow although doing well
load balancing of the squid servers(DNS Round Robin) and Disk IO per
squid server. Some guys recommended to reduce the cache_mem, but I don't
know how much allocate for squid cache_mem.
The other day, I tuned the kernel parameters like below information.
But, if the established tcp sessions arrive 1,100 ~ 1,200, the squid
response is very slow. And I checked the 'netstat -n | wc' and a 
'netstat -n | grep ESTABLISHED |, but the second is always over 1/2
of the first(1,054 | 1,404).
I need your recommendation to solve this problem.
Please check our information detaily and give your good response.
Thank you for your help in advance!
------------------------------------
Kernel Parameters
 - Maxusers = 1,600
 - TCP Parameters
   . tcp_conn_req_max = 1,024     . tcp_close_wait_interval(secs) = 10
   . tcp_xmit_hiwat = 8192        . tcp_recv_hiwat = 8192
   . tcp_rexmit_interval_min(msec) = 200
   . tcp_smallest_anon_port = 32768
   . tcp_keepalive_interval(secs) = 30
   . tcp_ip_abort_interval(secs) = 10
   . tcp_i[_abort_cinterval(secs) = 10
   . tcp_conn_grace_period = 500
1.Squid Parameter: 165.243.19.12:80
===================================
dated Tue Feb 3 14:03:28 1998 
 Parameter         Value    Description 
 VM-Max              896    Maximum hot-vm cache (MB) 
 VM-High              90    High water mark hot-vm cache (%) 
 VM-Low               75    Low water mark hot-vm cache (%) 
 Swap-Max           5000    Maximum disk cache (MB) 
 Swap-High            90    High water mark disk cache (%) 
 Swap-Low             85    Low water mark disk cache (%) 
 Neg-TTL             300    TTL for negative cache (s) 
 ReadTimeout         300    Maximum idle connection (s) 
 ClientLifetime     6000    Lifetime for incoming HTTP requests 
 CleanRate      31536000    Rate for periodic object expiring 
 HttpAccelMode         0    Is operating as an HTTP accelerator 
2. info: 165.243.19.12:80
=========================
dated Tue Feb 3 14:02:16 1998 
Squid Object Cache: Version 1.1.17
Start Time:     Mon, 02 Feb 1998 21:02:32 GMT
Current Time:   Tue, 03 Feb 1998 05:00:46 GMT
Connection information for squid:
        Number of TCP connections:      1187529
        Number of UDP connections:      0
        Connections per hour:   148989.5 <-- is over 250,000 in peak
        Select loop called: 2480973 times, 11.566 ms avg
Cache information for squid:
        Storage Swap size:      4486 MB
        Storage Mem size:       573624 KB
        Storage LRU Expiration Age:       0.00 days
        Requests given to unlinkd:      17979
        Unused fileno stack count:      76
Resource usage for squid:
        CPU Time: 10101 seconds (5127 user 4974 sys)
        CPU Usage: 35%
        Maximum Resident Size: 0 KB
        Page faults with physical i/o: 458944
File descriptor usage for squid:
        Maximum number of file descriptors:   1024
        Largest file desc currently in use:    878
        Number of file desc currently in use:  506
        Available number of file descriptors:  518
        Reserved number of file descriptors:   100
Internal Data Structures:
        360322 StoreEntries
         49757 StoreEntries with MemObjects
         49757 StoreEntries with MemObject Data
         49568 Hot Object Cache Items
Accounted Memory Usage:
        StoreEntry                 360322 x   52 bytes =  18297 KB
        URL strings                                    =  18999 KB
        IPCacheEntry                  928 x   36 bytes =     32 KB
        FQDNCacheEntry                  0 x   56 bytes =      0 KB
        Hash link                   49568 x   12 bytes =    580 KB
        Pool MemObject structures   49757 x  100 bytes =   4859 KB (     0 free)
        Pool for Request structur    6431 x 4536 bytes =  28487 KB (     0 free)
        Pool for in-memory object  184220 x 4096 bytes = 736880 KB ( 38384 free)
        Pool for disk I/O             200 x 8192 bytes =   1600 KB (   720 free)
        NetDB Address Entries           0 x   80 bytes =      0 KB
        NetDB Host Entries              0 x    8 bytes =      0 KB
        NetDB Peer Entries              0 x   32 bytes =      0 KB
        ClientDB Entries             8033 x  292 bytes =   2290 KB
        Miscellaneous                                  =  34873 KB
        Total Accounted                                = 846900 KB
3. DNSServer Usage
==================
   DNSServer Statistics:
   dnsserver requests: 18563
   dnsserver replies: 18560
   number of dnsservers: 32
   dnsservers use histogram:
    dnsserver #1: 10288    dnsserver #2: 4523    dnsserver #3: 1879
    dnsserver #4: 845      dnsserver #5: 491     dnsserver #6: 258
    dnsserver #7: 165      dnsserver #8: 73      dnsserver #9: 30
    dnsserver #10: 10      dnsserver #11: 1      dnsserver #12: 0
    dnsserver #13: 0       dnsserver #14: 0      dnsserver #15: 0
    dnsserver #16: 0       dnsserver #17: 0      dnsserver #18: 0
    dnsserver #19: 0       dnsserver #20: 0      dnsserver #21: 0
    dnsserver #22: 0       dnsserver #23: 0      dnsserver #24: 0
    dnsserver #25: 0       dnsserver #26: 0      dnsserver #27: 0
    dnsserver #28: 0       dnsserver #29: 0      dnsserver #30: 0
    dnsserver #31: 0       dnsserver #32: 0
> From jlauro@umich.edu  Mon Feb  2 11:47:24 1998
> Return-Path: <jlauro@umich.edu>
> Received: from relay.lg.co.kr (relay.lg.co.kr [165.243.17.16]) by lgeds.lg.co.kr (8.8.4_hhk9703/8.6.9) with SMTP id LAA14382 for <jongklee@lgeds.lg.co.kr>; Mon, 2 Feb 1998 11:47:24 +0900 (KST)
> Received: from willow.flint.umich.edu by relay.lg.co.kr (SMI-8.6/SMI-SVR4)
> 	id LAA01092; Mon, 2 Feb 1998 11:44:01 +0900
> Received: from flint.umich.edu by willow.flint.umich.edu (SMI-8.6/SMI-SVR4)
> 	id VAA13892; Sun, 1 Feb 1998 21:44:51 -0500
> Received: from UMF-EMDAT/SpoolDir by flint.umich.edu (Mercury 1.32);
>     1 Feb 98 21:52:20 -0400
> Received: from SpoolDir by UMF-EMDAT (Mercury 1.32); 1 Feb 98 21:52:09 -0400
> Received: from localhost (205.218.77.15) by flint.umich.edu (Mercury 1.32);
>     1 Feb 98 21:52:07 -0400
> From: "John Lauro" <jlauro@umich.edu>
> To: "=?us-ascii?q?=C0=CC=C1=BE=B0=E6?=" <jongklee@lgeds.lg.co.kr>
> Date: Sun, 01 Feb 98 22:37:05 -0500
> Reply-To: "John Lauro" <jlauro@umich.edu>
> Priority: Normal
> X-Mailer: PMMail 1.51 For OS/2 UNREGISTERED SHAREWARE
> MIME-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> Subject: Re: Help me urgently : How can I speed up our squid?
> Message-ID: <31E39473195@flint.umich.edu>
> 
> On Mon, 2 Feb 1998 10:28:10 KST, ÀÌÁ¾°æ wrote:
> 
> >Hello!
> >I am Mr. Lee in charge of the operating the Squid cache server.
> >I have a big problem in our squid performance.
> >So, I  need some solutions and recomendation to solve the probelm.
> >Please help me!
> >These followings are our squid information.
> >
> >================= Information ==================
> >1. Platform & Squid Version
> >   o. Platform : SUN Enterprise 3000 (Total 2 ea)
> >   o. OS : Solaris 2.5.1
> >   o. Squid Version : Squid v1.1.17
> >2. Squid Server File System Info(per EP3000)
> >   o. Internal Disk (4 Gbytes) : Boot System & Squid Libray
> >   o. External Disk Array(Hitachi DF300-64GB) : Cache Directories
> >       8 LUNs - 16 File Partitions (Total 16 Cache Dirs)
> 
> How much RAM do you have?  RAM is *very* critical for squid
> performance. 
> For 64GB of storage, I am guessing you should have a minimum of 1GB of
> RAM.  No, wait...  I was assuming cache_mem was something reasonable
> like 16, better make that 1.5GB for your setting of 896 (mb). 
> Remember, that setting takes memory away for disk cache and other
> things which can use it more effectively for anything that isn't
> repeatedly accessed every couple of minutes...
> 
> If you don't, I suggest you don't use all your drive space until you
> can get it.   You can watch the load of iostat, and make sure all your
> drives are being balanced.  Pay close attention to wherever your swap
> space and logs are.  Use 'iostat -cD -l 99 1' and make sure your drives
> are balanced. 
> 
> Also do a 'netstat -n | wc' and a 'netstat -n | grep ESTABLISHED | wc'
> and compare.  If the 2nd is under 1/3 of the second, you probably need
> to do some 'ndd /dev/tcp' tuning.
> 
> Are you running out of DNS processes?  (Check your stats with cachemgr
> how often/recently the last was called)  If so, there is a option that
> helps for solaris.  
> 
> 
Received on Mon Feb 02 1998 - 22:16:33 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:38:40 MST