[Zope] Re: Mysterious data.fs increase

[Michael Haubenwallner]

Danny Bloemendaal wrote:

> Well, I noticed what was the culprit. It turned out that portal_catalog
> turned into a 'tumor'. When I export the catalog it results in a 195Mb file
> while a few days earlier it was only a few Mbs. For some reason it suddenly
> grew many times larger than all my content together while hardly any new
> content was added. Reindexing took ages. About 1000+x longer than normal (=
> 70seconds). Now it took almost an hour to reindex my content. So then I
> decided to tried I cleared all indexes. I then tried to let it recreate the
> indexes (Find tab) but that took ages too. In fact it never finished (I
> stopped it eventually). So that didn't work.
> 
> Then I got a backup from a few days old. I exported all my content from the
> tumorous database and imported it into the backup version (after first
> removing the existing content). Then I let it reindex the portal_catalog in
> the backup version and then things were back to normal again. It took about
> 70seconds to reindex and the database was about 45Mb.
> 
> I have no idea why the catalog suddenly got into this state and why it took
> about 2 minutes to save plone content (reindexing the object) and why it
> took one hour for a full reindex. Right now my database is ok again but this
> really freaks me out!!!
> At that point I realized again how much of a black box the zope database
> actually is and I really keep my fingers crossed that nothing more serious
> will happen.
> 
> Danny
> 
> 

do you have a folder outside portal_skins that has the same id as a 
folder under portal_skins?

i once experienced a similar problem. when i inspected some of the 
objects i finally found the reason  -  for every object in this folder a 
complete folder_contents listing was indexed (and within it again every 
single object) and stored into the objects index. this took ages to 
index and blowed up to a 100 times the size of my ususal portal_catalog.

renaming the folder solved the problems immediately.

afaik this has been reported only another time to the ml before.

-- 
michael