On 18/11/10 08:14, Michał Prokopiuk wrote:
Dnia Poniedziałek, 01.11.2010 o 2:17 Amos Jeffries napisał:
On Sun, 31 Oct 2010 20:45:33 +0100, Michał Prokopiuk
<mic...@linuxstuff.pl>
wrote:
Hi.
For the last few days I have had troubles with my squid (3.0.24) - it
gets
a lot of cpu, and
response time is very long, about 4000 ms. I didn't see any information
in cache.log, so I tried to upgrade to latest stable release - it
doesn't change anything. I have read a lot about high cpu usage when
squid
rebuild disc cache, so I try change cache_dir type from ufs to aufs or
coss (./configure said about remove coss from squid 3.x), but the
problem
still exists.

What am I doing wrong? My squid has been working perfectly for two years
:(. Here's my config.log and squid.conf:

./configure --prefix=/usr/local/squid-3.1.8 --enable-useragent-log
--enable-referer-log --enable-default-err-language=Polish
--enable-err-languages=Polish --enable-linux-netfilter --enable-ssl
--with-large-files --with-filedescriptors=16384 -enable-snmp
--with-maxfd=16384 --with-pthreads --enable-async-io --disable-dlmalloc
--with-aio --enable-epoll

http_port 192.168.1.1:8080 transparent
pid_filename /var/run/squid/squid.pid
acl sloneczko src 192.168.0.0/23
http_access allow sloneczko
error_default_language pl-pl

redirect_program /usr/local/bin/redirector.pl
redirect_children 80

Replace those with:
   url_write_program /usr/local/bin/redirector.pl
   url_rewrite_children 80


store_avg_object_size 8 kB
minimum_object_size 1 KB
maximum_object_size 100 MB
maximum_object_size_in_memory  1 MB
cache_mem 1000 MB

cache_swap_low 80%
cache_swap_high 100%

cache_swap_high should be something less than 100% (99% may be better).
Squid will ONLY begin the aggressive space clearing when cache_swap_high
threshold is passed. So with 100% this may cause active connections to be
stopped while 20% of the cache is discarded.

# previous cache
#cache_dir ufs /var/spool/squid-cache/cache 30000 12 256
cache_dir aufs /var/spool/squid-cache/cache 30000 60 100

dns_nameservers 192.168.1.100 192.168.1.200
ipcache_size 8192
fqdncache_size 1024
positive_dns_ttl 2 hours
negative_dns_ttl 1 minutes
ipcache_low 90
ipcache_high 95

emulate_httpd_log on
access_log /var/log/squid/access.log

Remove emulate... and change access_log to:
   access_log /var/log/squid/access.log common

cache_log /var/log/squid/cache.log
cache_store_log /dev/null

Set this to "cache_store_log none".



Rest of squid.conf are acls. I have about 30 - 40 mbps of traffic. On

You have "http_access allow sloneczko" at the top of this config.  so its
possible your other ACL are not working.

board
are core2duo 1.8 ghz 4 gb ram on intel chipset, 2x SATA on soft raid
(for
cache - md0).

by "soft raid" you mean *software* raid? That is a disk IO killer for
Squid.


Any ideas? When I run -k debug I can't do anything - load has increased,


I set all canges, unfortunately, squid work great for fiew days, and today 
problem back again.  Any other ideas? I didn't see any other solution except 
remove squid :(


Okay. The obvious config reasons for slowness are gone. So the next thing is to find out exactly what Squid is doing.

* you can check with strace to see whats the thing taking out the CPU.

Has the box started using swap memory space now? That can drastically slow downs Squids index lookups or buffering of information relayed.

 Is RAID still running trying to duplicate the random cache IO actions?

Have you noticed if the problem appears and lasts for around 2 hours, then goes away? that would indicate your DNS TTL overrides forcing squid to try the wrong IPs for some site. CDN hosted sites (eg akamai and youtube) can change their IPs with no notice when there are routing problems to work around.

Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.9
  Beta testers wanted for 3.2.0.3

Reply via email to