[Setup] best practices for creating mounting points on Plone 4.2
runyaga at gmail.com
Mon Aug 20 18:03:39 UTC 2012
On Sun, Aug 19, 2012 at 8:54 AM, Héctor Velarde
<hector.velarde at gmail.com> wrote:
> hi there!
> we need to create many mounting points inside a Plone 4.2 instance to make
> backups and clean up the database more easily; our customer will create many
> content and we want to separate it on a monthly basis.
I would not recommend doing this. I do not know any large Plone installations
where multiple Mount points are used inside of a Plone instance.
I had a talk with Hector and here is the outcome:
1. If your database size is increasing; you need to know where/how it
The solution to this is installing collective.stats on production
environments and running the analyzer -> CSV file and reviewing which
operations are causing STOREs. Most importantly looking at how many
objects ARE being stored when a STORE occurs.
2. zlibstorage is very useful and appears to keep database's fairly
compressed (better than 40%) - this works well due to the fact many
attributes are text based; especially HTML.
3. if your using mysql replication be mindful to replicate only the
tables; you do not need to replication the entire database. just the
4. iirc mysql will not "reclaim" the database size. when you do a
gc-based pack (which will take a long time). There are 3 types of
1. pre-pack (usually takes 10 minutes)
2. pack w/o gc (acts on the pre-packed info; takes 3-4 minutes)
3. pack w/ gc (this usually takes many many hours)
5. you must lock the database when you dump. that means any read's
will block until dump is complete.
I will email the ploneconf2012 guys; if I can do a talk on all of the
OPS side of running these sorts of configurations - I would be more
> we know there's an old product called MountFolder made for Plone 2.0.5, but
> I don't think it's a good idea to try to used it with our brand new version:
dont use it.
I would update that and say "DO NOT USE THIS UNLESS YOUR A PROVEN ZODB GURU"
> what are you currently doing to solve problems like this one?
there is no "quick & easy" answer to database size. Like any "NoSQL"
system - this is all based on application usage and configuration.
Office:: 713.942.2377 ext 111
http://ploud.com/ Plone site in less than 10 seconds
More information about the Setup