On 03/28/2014 01:51 AM, Willy-Bas Loos wrote:
> Hi,
>
> I have a problem with postgres in combination with openvz.
> My hot standby crashes on me when i give it a normal value for
> shared_buffers (4GB, which 25% of the memory in the container).
> When i tune down the shared_buffers, it works again. But of course this
> is far from desireable.
What is the error that shows up in the logs when the 'machine' crashes?
25% is a suggested value, not an absolute value. Desirable would seem to
be a value that works for your situation and maintains performance. Is
there any indication that running with a lower value adversely affects
performance?
>
> Now, i've seen a couple more messages around the net about openVZ and
> postgres that weren't very encouraging:
>
> http://www.postgresql.org/message-id/CAHyXU0xa5EgvjeH=4vp-eZDJdS5kMQuiDivvTRLjY-uZ62Y44w@mail.gmail.com
> http://www.postgresql.org/message-id/23206.1254683408@sss.pgh.pa.us
>
http://postgresql.1045698.n5.nabble.com/BUG-9721-Fatal-error-on-startup-no-free-slots-in-PMChildFlags-array-td5797390.html
>
> But i am in a position where we already have a pretty strong binding
> with openVZ.
> I also have a colleague that has been using openVZ and postgres on
> production for quite a while now, without any problems. And already 1 of
> our servers is running a production database in openVZ that is well
> used, without any trouble of this kind.
>
> Now, what i would like to know is:
>
> * is there clarity about what the issues are at all
> * is it just 1 problem (in openVZ) that make openVZ and postgres so
> poorly compatible?
> * how can i stay out of trouble (when using postgres inside openVZ)
> * who else has trouble with openVZ in combination with postgres, and
> what constitutes the trouble?
A quick search found this:
http://forum.openvz.org/index.php?t=msg&goto=12061&&srch=postgresql+shared#msg_12061
and
http://openvz.org/FAQ#User_Beancounters_.28UBC.29
>
> regards,
>
> WBL
>
> --
> "Quality comes from focus and clarity of purpose" -- Mark Shuttleworth
--
Adrian Klaver
adrian.klaver@aklaver.com