So if the amount of memory used by squid is calculated as squid needs it
why is my swap and ram growing with my current spec's?
I know that its squid because when I restart it the swap memory drops to
zero then after about 24 hours its back up to 260 meg out of the 1024meg
available.
Is this normal?
Can I crank it up another 20 gig or is this swap usage telling me to
leave the size as is ?
Does anyone else have there swap creep up to about 1/4 of size over 24
hours?
With my current spec's and a 10mb/1Gig ram/storage ratio I can have 50
gig storage.
You can see it here on my extensive mrtg graphs
http://mrtg.spacelink.com.au/cache_server.html
Username: squidusers
Password: cache
> > Machine Specifications
> >
> > Celeron 1.2 GHZ
> > 512 RAM
> > 1 x scsi 4 GIG (ext3)
> > 1 x ATA100 70 GIG (ext3)
> > Redhat 7.3
> > squid-2.4.STABLE6-6.7.3.rpm
> > bind-9.2.1-1.7x.2
> > vmlinuz-2.4.18-26.7.x
> > Swap space 1 gig
> > Total size of cache storage 28gig
> >
>
> > My squid box is running about 55 gig of traffic per month
> >
> > The CPU runs at 2% or less
> >
> > [root@proxy root]# cat /etc/squid/squid.conf | grep -v ^# | grep -v
> > ^$
> >
> > http_port 3128
> > hierarchy_stoplist cgi-bin ?
> > acl QUERY urlpath_regex cgi-bin ?
> > no_cache deny QUERY
> > cache_mem 32 MB
> > cache_swap_low 35
> > cache_swap_high 40
> > maximum_object_size 10000 KB
> > maximum_object_size_in_memory 8 KB
> > cache_dir ufs /cache 4800 16 256
> > cache_dir ufs /cache3 73000 16 256
> > cache_access_log /var/log/squid/access.log
> > acl PURGE method PURGE
> > acl snmppublic snmp_community public
> > acl taz src XXX.XXX.XXX.XXX/255.255.255.255
> > acl spacelink src XXX.XXX.XXX.XXX/255.255.255.0
> > acl all src 0.0.0.0/0.0.0.0
> > acl manager proto cache_object
> > acl localhost src 127.0.0.1/255.255.255.255
> > acl SSL_ports port 443 563
> > acl Safe_ports port 80 # http
> > acl Safe_ports port 21 # ftp
> > acl Safe_ports port 443 563 # https, snews
> > acl Safe_ports port 70 # gopher
> > acl Safe_ports port 210 # wais
> > acl Safe_ports port 1025-65535 # unregistered ports
> > acl Safe_ports port 280 # http-mgmt
> > acl Safe_ports port 488 # gss-http
> > acl Safe_ports port 591 # filemaker
> > acl Safe_ports port 777 # multiling http
> > acl CONNECT method CONNECT
> > http_access allow spacelink
> > http_access allow PURGE localhost
> > http_access allow manager localhost
> > http_access deny manager
> > http_access deny !Safe_ports
> > http_access deny CONNECT !SSL_ports
> > http_access allow localhost
> > http_access deny PURGE
> > http_access deny all
> > icp_access allow all
> > httpd_accel_host virtual
> > httpd_accel_port 80
> > httpd_accel_with_proxy on
> > httpd_accel_uses_host_header on
> > snmp_port 3401
> > snmp_access allow snmppublic taz
> > snmp_incoming_address 0.0.0.0
> > snmp_outgoing_address 255.255.255.255
-----Original Message-----
From: Henrik Nordstrom [mailto:hno@squid-cache.org]
Sent: Thursday, 17 April 2003 12:47 AM
To: Marc Elsen
Cc: Stuart Clark; squid-users@squid-cache.org
Subject: Re: [squid-users] cache/mem ratio ok but swap grows
ons 2003-04-16 klockan 09.59 skrev Marc Elsen:
> Yes, because I think that squid reserves data structures which
> are sized according to the size of the cache.
Not really. Squid allocates data structures as it needs to when filling
the cache.
How much memory Squid is using for various purposes is displayed clearly
in cachemgr. Start by the General Runtime Information page (shows both
total, and amount of cache_mem used), and if that is not sufficient,
look into the "Memory Utilization" page for a detailed view of how your
Squid uses memory.
The main parameters which affects the memory usage by Squid is:
1. The number of objects in the cache.
2. The size of cache_mem
3. Some amount of additional overhead
Regards
Henrik
-- Free Squid-users support provided by Henrik Nordström <hno@squid-cache.org> Donations welcome if you consider my Free Squid support helpful. https://www.paypal.com/xclick/business=hno%40squid-cache.org If you need commercial Squid support or cost effective Squid and firewall appliances please refer to MARA Systems AB, Sweden http://www.marasystems.com/, info@marasystems.comReceived on Thu Apr 17 2003 - 08:02:50 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:15:01 MST