RE: [Zope] Urgent - Database has consumed all possible space
Because every change to an object creates a new copy of that object. This is how the undo feature works. By packing the database you choose to throw away those old copies. If you had a webcam application that pushed a 10k file into your Zope database every 60 seconds, your database would grow by 14 Mb a day even if no other changes happened. If you have 200 Mb of data and 10% changes every day, that adds up exponentially. day 1 200 mb day 2 220 mb day 3 242 mb day 4 266 mb day 5 293 mb day 6 322 mb day 7 355 mb 70% overall growth in just 7 days! Either pack the database frequently or use temp folders for frequently-changing objects(and forego undo). Perhaps you need to pack the database in chunks. If the time the server was created is x, you could drop transactions older than x + 1 month, then x + 2 months, etc. It should slowly shrink. This is similar to what happens to a severely fragmented drive that is completely full- you have to make an initial pass to free space so the defragmentewr can work better on the next pass. If you have another machine available, you could move the data.fs onto it, pack and move it back. -----Original Message----- From: Michael Havard [mailto:nhavar@hotmail.com] Sent: Tuesday, July 01, 2003 4:24 PM To: zope@zope.org Cc: plattem@inetnebr.com Subject: Re: [Zope] Urgent - Database has consumed all possible space If it were only so easy. This is a shared box with many other applications and databases on it. Our database was only supposed to take up 200-300mb NOT 1.8gb big difference. The DBA's have scrounged for extra space and given me all they could. Hard drive space for these machines is expensive and not something I can just ask for. Plus I still need to explain why 200-300mb worth of text files exploded in ZOPE to 1.8gb of information.
On Tue, Jul 01, 2003 at 04:57:49PM -0400, jwsacksteder@ramprecision.com wrote:
Because every change to an object creates a new copy of that object. This is how the undo feature works. By packing the database you choose to throw away those old copies.
another option might be to use a non-undoable storage. BSDDB Minimal might be worth investigating. Disclaimer: I've never done this :) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's MAKO ! (random hero from isometric.spaceninja.com)
participants (2)
-
jwsacksteder@ramprecision.com -
Paul Winkler