Plone memory needs?

3 views
Skip to first unread message

Jon Hadley

unread,
Jul 3, 2008, 11:52:59 AM7/3/08
to plone-use...@googlegroups.com
Hi all,

We all know that Plone is fairly memory hungry, but in practise, how
much do you find your live production sites use?

I have a site live at the moment that regularly peaks over the shared
hosts 300MB limit ...

Cheers,

Jon Hadley
http://jon-hadley.com

Dan Fairs

unread,
Jul 3, 2008, 6:49:55 PM7/3/08
to plone-use...@googlegroups.com
> We all know that Plone is fairly memory hungry, but in practise, how
> much do you find your live production sites use?
>
> I have a site live at the moment that regularly peaks over the shared
> hosts 300MB limit ...


Zope and Plone luuurve memory. No, really, they do.

The big site I was involved with (circa 20,000 regular users and a
30GB Data.fs) had each ZEO client (of which there were six) use
approximately 0.9 - 1.2GB RAM - this is Plone 2.5-ish (*heavily*
customised) and Zope 2.9-ish. To be honest, from a raw performance
perspective, it's probably a good idea to get your ZEO clients to use
as much RAM as possible without the machine starting to swap.

RAM is good, ZEO client cache (ie. local disk) is bad, ZEO server is
worst. Chuck as much RAM as you can (afford) at the box, and whack up
your caches as much as you can before the machine starts swapping.
Finger in the wind, leave 20-30% of your memory free for an unexpected
massive object load and avoid cache thrash. CPython don't let go of
its memory.

Honestly - if you've got a Plone site in production, put as much RAM
in the machine as it and the OS supports, and tweak the config to use
it. And avoid using the machine for anything else.

It's worth noting that your memory usage is very dependent on the
third-party products you use, and your own audience's usage pattern.
The pathological case is actually something like Google, which
carefully hits every page (and probably therefore object) in your
site, loading them into the ZEO client caches, evicting objects from
'real' reads, and therefore slowing everything else down. We ended up
having a machine dedicated to serving the (internal) Google box, to
avoid cache thrash on the other app servers.

Cheers,
Dam

--
Dan Fairs <dan....@gmail.com> | http://www.stereoplex.com/

Reply all
Reply to author
Forward
0 new messages