Hi<div><br></div><div>Thanks for your responses thus far.</div><div><br></div><div>For the most part the zeoserver is performing quite well. Very low memory and CPU usage.</div><div><br></div><div>I really think my problem lies in the fact that the Zope clients are reporting these sort of messages quite regularly when communicating to ZEO:</div>
<div><br></div><div><div>2012-10-19T10:15:02 INFO ZEO.ClientStorage storage_d06_zeostorage Testing connection <ManagedClientConnection ('10.221.0.247', 8101)></div><div>------</div><div>2012-10-19T10:15:12 ERROR ZEO.zrpc (8356) CW: error in testConnection (('10.221.0.247', 8101))</div>
<div>Traceback (most recent call last):</div><div> File "/opt/informa/buildout-cache/eggs/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZEO/zrpc/client.py", line 595, in test_connection</div><div> self.preferred = self.client.testConnection(self.conn)</div>
<div> File "/opt/informa/buildout-cache/eggs/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZEO/ClientStorage.py", line 565, in testConnection</div><div> stub = self.StorageServerStubClass(conn)</div><div> File "/opt/informa/buildout-cache/eggs/ZODB3-3.10.3-py2.6-linux-x86_64.egg/ZEO/ServerStub.py", line 386, in stub</div>
<div> raise ValueError("Timeout waiting for protocol handshake")</div><div>ValueError: Timeout waiting for protocol handshake</div></div><div><br></div><div>Each time that happens, more open file descriptors are used by zeo and as far as I'm aware are never released unless the Zope client shuts down.</div>
<div><br></div><div>I have upped zeo's invalidation-queue-size to 4000 (not sure what my upper limit is there) to see if that reduces the growth of open file handles. So far that seems to be the case. 16 Zope clients connected with only 413 file descriptors in use.</div>
<div><br></div><div>Not sure if any of these observations are related however?</div><div><br></div><div>Tim</div><div><br><div class="gmail_quote">On 19 October 2012 06:29, Jim Fulton <span dir="ltr"><<a href="mailto:jim@zope.com" target="_blank">jim@zope.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Oct 18, 2012 at 3:09 PM, Leonardo Rochael Almeida<br>
<<a href="mailto:leorochael@gmail.com">leorochael@gmail.com</a>> wrote:<br>
<br>
Thanks for pitching in with an answer!<br>
<div class="im"><br>
> Having a single ZEO server handling more than one or two storages is<br>
> not usually a good idea. ZEO does not handle each storage in a<br>
> separate thread, so you're underusing multiple CPUs if you have them.<br>
<br>
</div>Nit pick: ZEO handles each client connection and storage in a separate thread.<br>
(So 30 storages and 16 clients means 480 threads :)<br>
<br>
It is Python's GIL that prevents effective use of multiple processors.<br>
<br>
ZEO goes out if it's way to let I/O C code run concurrently (since I/O isn't<br>
subject to the GIL) and I've seen ZEO storage servers use up to 200% CPU<br>
on 4-core boxes (2 cores worth, IOW).<br>
<span class="HOEnZb"><font color="#888888"><br>
Jim<br>
<br>
--<br>
Jim Fulton<br>
<a href="http://www.linkedin.com/in/jimfulton" target="_blank">http://www.linkedin.com/in/jimfulton</a><br>
Jerky is better than bacon! <a href="http://zo.pe/Kqm" target="_blank">http://zo.pe/Kqm</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Tim Godfrey<br>Obsidian Consulting Group<br><br>P: +61 3 9355 7844<br>F: +61 3 9350 4097<br>E: <a href="mailto:tim@obsidian.com.au">tim@obsidian.com.au</a><br>
W: <a href="http://www.obsidian.com.au/">http://www.obsidian.com.au/</a><br>
</div>