Question about Shared memory and PG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

 

Bit of background:

 

PGPOOL (V8 with PG 803) talking to 2 x Red Hat ES4, HP DL 380s with 2Gb RAM and twin CPUs running PG 807

 

Last night PGPOOL alerted our OOH on call guy saying that it could communicate with the second DB server

 

In the PG log file the errors were:

 

2006-08-03 21:49:18 BST FATAL:  invalid frontend message type 50

2006-08-03 21:49:18 BST LOG:  unexpected EOF on client connection

2006-08-03 21:49:18 BST LOG:  unexpected EOF on client connection

2006-08-03 21:49:18 BST LOG:  unexpected EOF on client connection

2006-08-03 21:49:18 BST LOG:  unexpected EOF on client connection

2006-08-03 21:49:18 BST LOG:  unexpected EOF on client connection

2006-08-03 21:49:18 BST LOG:  unexpected EOF on client connection

2006-08-03 21:49:18 BST LOG:  unexpected EOF on client connection

2006-08-03 21:49:18 BST LOG:  unexpected EOF on client connection

 

The DB was up and so it was shutdown and a restart was attempted but failed with:

 

could not create shared memory segment: Invalid argument  - (pg.conf shared_buffers set to 750Mb)

 

Anyway it was decided to leave it until the morning.

 

What we realised this morning was that the SHMMAX param was set to 512M and hence that’s why the DB wouldn’t start.

 

What we think has happened is that SHMMAX has been reset (when and by whom we don’t yet know) from 1024Mb to 512Mb.

 

Basically my question(s) is/are what happens to PG when this memory param is modified on the fly, could it explain the above PG log errors?

 

Initial experiments certainly allow the param to be modified while PG is running without any obvious side effects though possibly over time it could cause a problem – DB & box have been running since April

 

The network logs at the time being checked also.

 

 

Any input on this would be much appreciated

 

Regards

Nigel

 

 

 



Communications on or through ioko's computer systems may be monitored or recorded to secure effective system operation and for other lawful purposes.

Unless otherwise agreed expressly in writing, this communication is to be treated as confidential and the information in it may not be used or disclosed except for the purpose for which it has been sent. If you have reason to believe that you are not the intended recipient of this communication, please contact the sender immediately. No employee is authorised to conclude any binding agreement on behalf of ioko with another party by e-mail without prior express written confirmation.

ioko365 Ltd. VAT reg 656 2443 31. Reg no 3048367. All rights reserved.

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux