Reasons for postgres processes beeing killed by SIGNAL 9?
Hi,
Recently single postgres processes are killed by SIGNAL 9 on our
virtual vvmware managed server without any manual interaction -
causing lost transactions.
Any ideas what could be the reason? Could postmaster the source of the signal?
We are running postgreql 8.4.7 on Linux 64-bit.
Thank you in advance, Clemens
2012-05-17 19:13:16 BST LOG: Serverprozess (PID 4849) wurde von
Signal 9 beendet: Killed
2012-05-17 19:13:16 BST LOG: aktive Serverprozesse werden abgebrochen
2012-05-17 19:13:16 BST khbldb_prod khbl WARNUNG: breche Verbindung
ab wegen Absturz eines anderen Serverprozesses
2012-05-17 19:13:16 BST khbldb_prod khbl DETAIL: Der Postmaster hat
diesen Serverprozess angewiesen, die aktuelle Transaktion
zurückzurollen und die Sitzung zu beenden, weil ein anderer
Serverprozess abnormal beendet wurde und möglicherweise das Shared
Memory verfälscht hat.
2012-05-17 19:13:16 BST LOG: alle Serverprozesse beendet; initialisiere neu
2012-05-17 19:13:16 BST LOG: Datenbanksystem wurde unterbrochen;
letzte bekannte Aktion am 2012-05-17 18:59:09 BST
2012-05-17 19:13:16 BST LOG: Datenbanksystem wurde nicht richtig
heruntergefahren; automatische Wiederherstellung läuft
2012-05-17 19:13:16 BST LOG: Redo beginnt bei 1/343D5010
2012-05-17 19:13:16 BST LOG: Datensatz mit Länge null bei 1/3445EAA8
2012-05-17 19:13:16 BST LOG: Redo fertig bei 1/3445EA78
2012-05-17 19:13:16 BST LOG: letzte vollständige Transaktion war
bei Logzeit 2012-05-17 19:13:13.575598+01
On 05/17/2012 03:44 PM, Clemens Eisserer wrote:
Hi,
Recently single postgres processes are killed by SIGNAL 9 on our
virtual vvmware managed server without any manual interaction -
causing lost transactions.
Any ideas what could be the reason? Could postmaster the source of the signal?We are running postgreql 8.4.7 on Linux 64-bit.
...
Out of memory or OOM killer?? Any such messages in system logs?
Cheers,
Steve
Hi Steve,
Out of memory or OOM killer?? Any such messages in system logs?
That was my first thought too - but I could't find anything indicating
an OOM event in the logs.
Usually the server only uses ~110mb out of the available 2GB assigned to it.
So if this isn't a known postgres behaviour, I guess I have to dig a
bit in vmware related issues.
Thanks, Clemens
Hi again,
We are still constantly getting postgresql processes killed by signal
9 from time to time, without any idea why or how.
Syslog seems completly clean.
In case a postgresql process would exceed some restricted resources
like file descriptors, would the kernel choose to terminate it using
SIGKILL? Are there any other common examples / occurences where
processes are terminated this way automatically?
Thank you in advance, Clemens
On Saturday, May 19, 2012 04:42:16 PM Clemens Eisserer wrote:
Hi again,
We are still constantly getting postgresql processes killed by signal
9 from time to time, without any idea why or how.
Syslog seems completly clean.In case a postgresql process would exceed some restricted resources
like file descriptors, would the kernel choose to terminate it using
SIGKILL? Are there any other common examples / occurences where
processes are terminated this way automatically?
Check dmesg or the kernel log. I'd guess it's the OOM-killer. Assuming this is
on Linux, that is.