Re: Help me urgently : How can I speed up our squid?

From: 이종경 <jongklee@dont-contact.us>
Date: Mon Feb 2 22:16:33 1998

   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