The error that shows up is a Bus error.
That's on the replication slave.
Here's the log about it:2014-03-29 12:41:33 CET db: ip: us: FATAL: could not receive data from WAL stream: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
cp: cannot stat `/data/postgresql/9.1/main/wal_archive/00000001000000720000000A': No such file or directory
2014-03-29 12:41:33 CET db: ip: us: LOG: unexpected pageaddr 71/E9DA0000 in log file 114, segment 10, offset 14286848
cp: cannot stat `/data/postgresql/9.1/main/wal_archive/00000001000000720000000A': No such file or directory
2014-03-29 12:41:33 CET db: ip: us: LOG: streaming replication successfully connected to primary
2014-03-29 12:41:48 CET db: ip: us: LOG: startup process (PID 17452) was terminated by signal 7: Bus error
2014-03-29 12:41:48 CET db: ip: us: LOG: terminating any other active server processes
2014-03-29 12:41:48 CET db:wbloos ip:[local] us:wbloos WARNING: terminating connection because of crash of another server process
2014-03-29 12:41:48 CET db:wbloos ip:[local] us:wbloos DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2014-03-29 12:41:48 CET db:wbloos ip:[local] us:wbloos HINT: In a moment you should be able to reconnect to the database and repeat your command.
On Fri, Mar 28, 2014 at 2:52 PM, Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
No, not at the moment. I just want to make sure that i can rely on the server and database to be stable. Or at least that i know what i can and can't do.
Thanks, i'm looking into the bean counters more.
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?
No, not at the moment. I just want to make sure that i can rely on the server and database to be stable. Or at least that i know what i can and can't do.
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
Maybe there is something to won by guaranteeing the shared memory resources, instead of just refraining from constraining them.
On Fri, Mar 28, 2014 at 11:35 AM, <lst_hoe02@xxxxxxxxx> wrote:
Ok, that sounds reassuring, and i agree that the other posts are not really related. It's just that i found several posts that boiled down to memory related issues with openVZ, and experts complaining. That made me worry.
Have a look at the bean counters from OpenVZ. Some of them have dependencies to each other and can lead to unexpected out-of-memory condition inside the container. Check the logs for the reason PostgreSQL crashed, maybe it was the OOM killer.
I'll look into the bean counters.
>From my point of view your problem is not related to the URLs shown. You have to carefully check the Container settings and errors and avoid freezing/migrating the database container if possible.
In general there is no Problem with databases inside Containers but you have to carefully check the settings for the container in question and test the advanced features like hot migration if you really have to use them.
More here: http://www.postgresql.org/message-id/4EF2EDBE0200002500043FCE@xxxxxxxxxxxxxxx
Which links to: http://www.postgresql.org/message-id/CAK3UJREBcyVBtr8D7vMfU=uDdkjXkrPnGcuy8erYB0tMfKe1LA@xxxxxxxxxxxxxx
Which links to: http://www.postgresql.org/message-id/CAK3UJREBcyVBtr8D7vMfU=uDdkjXkrPnGcuy8erYB0tMfKe1LA@xxxxxxxxxxxxxx
On Fri, Mar 28, 2014 at 10:33 AM, Reynold PJ <reynoldp@xxxxxxxxx> wrote:
>Try increasing the share memory "shmpages" of container from host.
That value is "unlimited"
Thanks a lot,
WBL
--
"Quality comes from focus and clarity of purpose" -- Mark Shuttleworth
"Quality comes from focus and clarity of purpose" -- Mark Shuttleworth
