Thread: 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.