RE: [squid-users] calling Henrick , Joe ,Adrian ...SOS pls help out

System problem could be an issue here as well. I had gone mad finding out
why was the CPU taking up 100% in a few hours of squid uptime and found out
that most other people with intel STL2 motherboard were using 2.2.19 kernel
and I was trying out the 2.4.x series with ipchains.

Please make sure that somebody else with similary hardware config has used
squid and with what configuration. Replicate that situation and you will be
in business.

HTH

-----Original Message-----
From: Joe Cooper [mailto:joe@swelltech.com]
Sent: 20 August 2001 18:12
To: khiz code
Cc: squid-users@squid-cache.org
Subject: Re: [squid-users] calling Henrick , Joe ,Adrian ...SOS pls help
out

khiz code wrote:

> Hi all
> i would like to emphasize that i am getting
> 2001/08/15 14:23:53| clientReadRequest: FD 21: no data to process ((11)
> Resource temporarily unavailable) after almost every get request (
> with and without load)
> the cpu and memory are hardly utilsed at load
>
> under load of less than 10 req /sec it takes me abt 2 mins to telnet to
> the squid port even from the same
> machine as squid

Have you tried a 2.4 daily snapshot, as suggested by Adrian?

What are your compile time options for Squid?

> i am repaeting all the details here
> 1> compaq prolinea 5500 dual pii xeon 550 Mhz/512 mb
> ram/6 scsi disk of 9 GB each
> RAID 0 done on 4 of the drives and partitioned as
> /cache using reiserfs for effective 34 GB

Would probably be more effective as 4 independent drives, so Squid could
decide which disk to use, and when.

> RAID 1 done on the remaining drives where linux is
> installed
> 2> redhat 6.2 with kernel 2.2.19 and reiserfs 3.53
> scsi driver sym 53cxx compiled in . along with tlan
> driver
> 3> cache box set up as transparent proxy with ipchains
> target prot opt source
> destination ports
> ACCEPT all ------ localhost localhost
> n/a
> REDIRECT tcp ------ anywhere anywhere
> any -> www
> => 3128
> ACCEPT all ------ anywhere anywhere
> n/a

Did you try it without transparent proxying, as Robert suggested?

> Chain forward (policy ACCEPT):
> Chain output (policy ACCEPT):
> 4> squid.conf
> cache_mem 128 MB
> maximum_object_size 40960 KB
> cache_dir /cache 10000 30 25
> dns_children 15

This tells me you're either using an older Squid, or have chosen to
compile external DNS processes. This is OK, and shouldn't cause your
problem, but hints that maybe you haven't tried Adrian's advice.

> httpd_accel_host virtual
> httpd_accel_port 80
> httpd_accel_with_proxy on
> httpd_accel_uses_host_header on
> memory_pools_limit 70 MB

No need to set memory pools limit.

> 5> glibc-2.1.3-22

This is fine.

> 8> /var/log/dmesg has an entry saying that
> mtrr: your CPUs had inconsistent fixed MTRR settings
> mtrr: probably your BIOS does not setup all CPUs
> is this okay ???

Probably OK.

> 9> startup scripts
> echo 1 >/proc/sys/net/ipv4/ip_forward
> ulimit -HSn 16384
> echo 10000 > /proc/sys/fs/file-max
> echo 32768 >/proc/sys/fs/inode-max
> echo 1024 65000 /proc/sys/net/ipv4/ip_local_port_range
> echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
> echo 100 > /proc/sys/net/ipv4/tcp_fin_timeout
> echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time
> echo 0 > /proc/sys/net/ipv4/tcp_sack
> echo 0 > /proc/sys/net/ipv4/tcp_timestamp

Excessive, but shouldn't cause problems. Try running the defaults (i.e.
reboot your box, and don't run these startup scripts, except for
ip_forward).

This doesn't look like a Squid-specific problem, because your Squid
appears to be doing what it should and not eating terribly large amounts
of CPU. It looks like you have a system problem that is triggered by
network activity. I've seen this same result recently from a network
where duplex was forced on a Intel EEPro ethernet port. Changing to the
Intel provided e100 driver fixed the problem.

Try some other server software on the same box with an artificial load
and see what happens. I could actually reproduce my problem recently by
fetching a large file from a fast FTP server. It drove CPU to 0% idle
and limited the throughput of the network adaptor to 35Kb/sec...once the
problem was solved it went to 650Kb/sec and CPU usage was down to 2%.

If there is nothing in the logs and nothing out of the ordinary in your
Squid compile options, then it looks like a system problem, not a Squid
problem.

We're not trying to withhold any 'Squid secrets' from you, Khiz. It's
just that we don't see anything wrong with your running Squid...the
cachemgr output looks fine. Your configuration is OK (not ideal in a
few places, but not bad and shouldn't cause the problems you're seeing).
                                   --
                      Joe Cooper <joe@swelltech.com>
                  Affordable Web Caching Proxy Appliances
                         http://www.swelltech.com
Received on Mon Aug 20 2001 - 09:47:18 MDT