[Zope] Archetypes leak problem? Acquisition.ImplicitAcquirerWrapper
references killing eventually Zope
Heimo Laukkanen
huima at iki.fi
Tue May 11 19:15:06 EDT 2004
First of all my apologies for long email, but this is an interesting
problem to anyone. I appreciate any help and confirmations / views if
anyone else can see the same.
Setup:
Python 2.3.3, Zope 2.7, Plone 2.0, Archetypes1.3b2
Problem that I am seeing now is on a service that yet does not have even a
high load, but Zope keeps hogging steadily more and more memory, becoming
slower and eventually coming to almost full stop - or in dire need of
restart anyoway. Under small load this comes in few hours.
What I have seen and debugged so far is that
Acquisition.ImplicitAcquirerWrapper are running wild in Zope. Every time
my Archetypes-object is accessed - atleast one new reference count is
created. Even if that object is accessed again and again.
By applying some force with ab or other tools numbers grow fast in just
few thousand requests, below data from Zope Debug:
Acquisition.ImplicitAcquirerWrapper 127 16986 +16859
Products.PageTemplates.Expressions.SubPathExpr 79 1503 +1424
ZPublisher.HTTPRequest.HTTPRequest 31 1249 +1218
ZServer.HTTPResponse.ZServerHTTPResponse 8 1226 +1218
ZPublisher.BaseRequest.RequestContainer 5 1223 +1218
And few thousand requests later.
Acquisition.ImplicitAcquirerWrapper 127 36000 +35873
ZPublisher.HTTPRequest.HTTPRequest 31 4280 +4249
ZServer.HTTPResponse.ZServerHTTPResponse 8 4257 +4249
ZPublisher.BaseRequest.RequestContainer 5 4252 +4247
Products.PageTemplates.Expressions.SubPathExpr 79 2623 +2544
Products.PageTemplates.Expressions.PathExpr 45 1197 +1152
At this stage Zope processes have got approx. 20 percent of the full
memory.
Now to the setup that produces following behaviour. First of all there is
a site:
Plonesite
SiteTree ( Archetypes object, folderish )
intranet ( Archetypes object, folderish )
And a PythonScript called sitetreetest, which accepts obj as parameter:
---------------------------------------------
from Products.CMFCore.utils import getToolByName
if obj is None:
obj=context
url_tool = getToolByName(context, 'portal_url')
relative_ids = url_tool.getRelativeContentPath(obj)
o = url_tool.getPortalObject()
path_seq = []
for id in relative_ids:
# this is much faster than restrictedTraverse and makes some sense,
# if the user can't access the contents information, getattr() will
fail
# and hiding the breadcrumb because they dont have access? urk
o = getattr(o, id)
# o = o.restrictedTraverse(id)
path_seq.append( o )
return path_seq
-------------------------------------------------
Script will be called from a template:
<table border="0" cellpadding="0" cellspacing="0" >
<tr tal:repeat="itemi python: here.sitetreetest(here)">
<td tal:content="python: str(itemi)">
foo
</tD>
</tr>
</table>
And that is called in the context of intranet:
/plonesite/SiteTree/intranet/template
You can actually use event SimpleFolder or other folderish archetypes
objects, since they provide similar results.
It does not happen with Plone Folder. Code itself is similar to how Plone
for example does breadcrumbs - so it should not itself be evil.
What also makes this interesting is that reference count for Acquisition
wrappers starts to run wild only IF the object does not have Access
contents information permission for anonymous user set in workflow or
otherwise.
I've now debugged this for many, many hours and come to this point after
excluding different other options away. Any help is appreciated as allways.
--
-huima
More information about the Zope
mailing list