Mysterious data.fs increase
Hi folks, I have a production zope database with a size of 225Mb (after pack) and a local database (identical environment) which is a copy of production that is a few days old with a size of 45Mb. In a desperate attempt to find out where all these hundreds of Mb came from in only a few days while not much was added in the production database I did some tests: When I delete all the content from my Plone site, production db decreased to 7Mb, so I concluded that nearly all the size sits in the content. When I export all the content in import it into my local version (after removing the local content first), the size of my local db increased with only a few Mb. So local was about 50Mb after import and after packing. The export files where roughly 30Mb. So, my question is: where are those 190Mb (roughly)!??? Packing doesn't solve it. Besides, the catalog in my plone site takes about 45minutes to reindex the content and locally about 69seconds. Again, with the same content, same products installed, same python/zope versions etc etc. Please give me some insight. Cheers, Danny
Danny Bloemendaal wrote at 2004-5-11 17:08 +0200:
I have a production zope database with a size of 225Mb (after pack) and a local database (identical environment) which is a copy of production that is a few days old with a size of 45Mb. In a desperate attempt to find out where all these hundreds of Mb came from in only a few days while not much was added in the production database I did some tests:
Recently, someone had a problem similar to yours. He posted results he had derived with an "analyse.py" script. I do not know what "analyse.py" is and who is his author. But, the information derived by it was *very* useful to get clues towards the problem cause. Maybe, you use a search engine to locate the relevant thread and contact the poster for information about "analyse.py". -- Dieter
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 "Dieter Maurer" <dieter@handshake.de> wrote in message news:16546.35043.313060.656109@gargle.gargle.HOWL...
Danny Bloemendaal wrote at 2004-5-11 17:08 +0200:
I have a production zope database with a size of 225Mb (after pack) and a local database (identical environment) which is a copy of production that is a few days old with a size of 45Mb. In a desperate attempt to find out where all these hundreds of Mb came from in only a few days while not much was added in the production database I did some tests:
Recently, someone had a problem similar to yours. He posted results he had derived with an "analyse.py" script.
I do not know what "analyse.py" is and who is his author. But, the information derived by it was *very* useful to get clues towards the problem cause.
Maybe, you use a search engine to locate the relevant thread and contact the poster for information about "analyse.py".
-- Dieter
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
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
That's an interesting idea but hard to search for. I'll remember it for when it happens again. Point is that I exported all my content to an older version of the database with the same products and skins installed. After the import, indexing goes as expected without the bloat.... "Michael Haubenwallner" <michael@d2m.at> wrote in message news:c7u6k1$ips$1@sea.gmane.org...
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
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Wed, May 12, 2004 at 11:38:59PM +0200, Danny Bloemendaal wrote:
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.
Are you using ZWiki? IIRC, someone recently reported a problem where ZWiki adds a 'links' index/metadatum to the catalog. For content types without a links attribute, acquisition grabs the standard links page/object and stuffs its expanded content into the catalog. I suggest that you sample some catalog entries in the Catalog tab of portal_catalog. Try some catalog records of Document objects and look for a *huge* links field value. -- Fred Yankowski fred@ontosys.com tel: +1.630.879.1312 OntoSys, Inc PGP keyID: 7B449345 fax: +1.630.879.1370 www.ontosys.com 38W242 Deerpath Rd, Batavia, IL 60510-9461, USA
I use to have zwiki but I removed it a few months ago. And indeed back then I noticed strange behaviour with link objects. I just deleted both the links index and meta field. Thanks for the tip. "Fred Yankowski" <fred@ontosys.com> wrote in message news:20040512224523.GA9589@ontosoft.com...
On Wed, May 12, 2004 at 11:38:59PM +0200, Danny Bloemendaal wrote:
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.
Are you using ZWiki? IIRC, someone recently reported a problem where ZWiki adds a 'links' index/metadatum to the catalog. For content types without a links attribute, acquisition grabs the standard links page/object and stuffs its expanded content into the catalog. I suggest that you sample some catalog entries in the Catalog tab of portal_catalog. Try some catalog records of Document objects and look for a *huge* links field value.
-- Fred Yankowski fred@ontosys.com tel: +1.630.879.1312 OntoSys, Inc PGP keyID: 7B449345 fax: +1.630.879.1370 www.ontosys.com 38W242 Deerpath Rd, Batavia, IL 60510-9461, USA
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
I tested it and indeed these indexes were the problem. After removing the indexes and reindexing the catalog, things where back to normal. "Danny Bloemendaal" <Danny.Bloemendaal@companion.nl> wrote in message news:c7v856$ckl$1@sea.gmane.org...
I use to have zwiki but I removed it a few months ago. And indeed back then I noticed strange behaviour with link objects. I just deleted both the links index and meta field. Thanks for the tip.
"Fred Yankowski" <fred@ontosys.com> wrote in message news:20040512224523.GA9589@ontosoft.com...
On Wed, May 12, 2004 at 11:38:59PM +0200, Danny Bloemendaal wrote:
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.
Are you using ZWiki? IIRC, someone recently reported a problem where ZWiki adds a 'links' index/metadatum to the catalog. For content types without a links attribute, acquisition grabs the standard links page/object and stuffs its expanded content into the catalog. I suggest that you sample some catalog entries in the Catalog tab of portal_catalog. Try some catalog records of Document objects and look for a *huge* links field value.
-- Fred Yankowski fred@ontosys.com tel: +1.630.879.1312 OntoSys, Inc PGP keyID: 7B449345 fax: +1.630.879.1370 www.ontosys.com 38W242 Deerpath Rd, Batavia, IL 60510-9461, USA
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Some more details at http://zwiki.org/IssueNo0784 . Fixed in Zwiki 0.30, though the links index & metadata must still be removed manually as you did.
On Wednesday 12 May 2004 9:28 pm, Dieter Maurer wrote:
I do not know what "analyse.py" is and who is his author. But, the information derived by it was *very* useful to get clues towards the problem cause.
"analyze.py" (with the American spelling) is one of the tools that come with ZODB. It's in utilities/ZODBTools if you download the Zope source, and it's in the Tools directory of the standalone ZODB package. It says it is "based on a transaction analyzer by Matt Kromer." -- James Henderson, Logical Progression Ltd. http://www.logicalprogression.net/ http://sourceforge.net/projects/mailmanager/
participants (6)
-
Danny Bloemendaal -
Dieter Maurer -
Fred Yankowski -
James Henderson -
Michael Haubenwallner -
Simon Michael