[Zope] Unexpected Squid problems

Wankyu Choi wankyu@neoqst.com
Mon, 5 May 2003 04:25:38 +0900

Hi everyone,

I recently set up a Squid frontend before ZEO server + a single ZEO =


ZEO: 2.0.1
Zope: 2.6.1
Storage: DirectoryStorage 1.0.1
Platform: Redhat Linux 8 with all erratas applied up to this date
Kernel: 2.4.20 + aa1 patch
Squid: 2.4.STABLE7-4

I successfully set up a cache peer  thanks to Toby Dickenson's excellent
howto: http://www.zope.org/Members/htrd/howto/squid

After running Squid for about a week, I found something really annoying
about this setup: Squid gives up on the ZEO client for dead when Zope is
packing the ZODB. And the Squid manual says it'll query even a dead peer
from time to time to see if it came alive, but that never happens.

I'm running z2.py with --icp 3130. And the problem occurs only when =
is in progress. It seems when packing is in progress, Zope's taking too =
to respond to queries sent from Squid. I tried adjusting timeout values =
high as 20 seconds to no avail. Going for higher values looks really =

I have to restart Squid again and again. I even came up with a little =
script to grep Squid's cache.log every 10 minutes and restart the daemon =
it finds a string containing 'Detected Dead Parent'  ( and, of course, =
the log ). But it's so kludgy a solution :-(

It gets worse.

Last night, I added two more ZEO clients to this setup, and now I have =
clients in total. Whenever the packing script runs, all three ZEO =
are pronounced dead by Squid and during this time no service is =
The 10-minute cron job restarted Squid as many as 5 times. The packing
script is started by a single ZEO client.

Anyone experienced a simliar problem?

Here goes another. I haven't been able to track down the cause of this
problem but having three ZEO clients takes much longer to serve ZODB =
having a single ZEO client.=20

For example, it used to take an average 1 second rendering a CMF =
when I ran a single ZEO client, but it now takes an average 2.5 seconds =
three clients. Plus, it generates conflicts too often. The slow =
however, is not directly related to read conflicts since even with no
conflict, the overall performance is way too bad.

All three ZEO clients are 2-way/4-way Xeon servers with RAM to burn: 2G.
Nothing is hogging any of their resources. All three of them are hooked =
with ZEO server/Squid frontend in 100M bandwidth.

Any ideas?

Thanks in advance.

Wankyu Choi
  Wankyu Choi
  NeoQuest Communications, Inc.
---------------------------------------------------------------  =20