"breche Verbindung ab wegen Absturz eines anderen Serverprozesses"

Hallo,

seit kurzem habe ich auf einem Server erhebliche Probleme. Gewisse SELECT-Abfragen lassen regelmäßig - aber nur bei bestimmten Daten - die Datenbank crashen. Diese SELECT-Abfragen beinhalten JOINS über 5 Tabellen wobei teilweisen auch Sub-SELECT-Abfragen enthalten sind. Bei den meisten Datensätzen funktionieren diese, doch ich habe schon 5 Datensatzkombinationen gefunden, bei denen die Datenbank danach neu gestertet werden muss. Insgesamt sind vielleicht 500 Datensätze vorhanden. Wenn ich diese 5 betroffenen Datensätze jedoch jeweils einzeln aufrufe, werden mir diese tadellos angezeigt.
Einze zusätzliche Eingenart kommt noch hinzu: Wenn ich SELECT … WHERE … IN (SELECT…) in Join umwandle, funktioniert wieder eine Abrage mehr??

Folgendes spuckt mir die Log-Datei aus:
2010-06-06 06:10:26 CEST LOG: Datenbanksystem wurde am 2010-06-06 06:00:31 CEST heruntergefahren
2010-06-06 06:10:26 CEST FATAL: das Datenbanksystem startet
2010-06-06 06:10:27 CEST FATAL: das Datenbanksystem startet
2010-06-06 06:10:29 CEST FATAL: das Datenbanksystem startet
2010-06-06 06:10:29 CEST LOG: Datenbanksystem ist bereit um Verbindungen anzunehmen
2010-06-06 06:10:29 CEST LOG: Autovacuum-Launcher startet
2010-06-06 10:18:25 CEST LOG: Serverprozess (PID 408) beendete mit Status 128
2010-06-06 10:18:25 CEST LOG: aktive Serverprozesse werden abgebrochen
2010-06-06 10:18:25 CEST WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses
2010-06-06 10:18:25 CEST 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.
2010-06-06 10:18:25 CEST TIPP: In einem Moment sollten Sie wieder mit der Datenbank verbinden und Ihren Befehl wiederholen können.
2010-06-06 10:18:25 CEST LOG: alle Serverprozesse beendet; initialisiere neu
2010-06-06 10:18:35 CEST FATAL: bereits bestehender Shared-Memory-Block wird noch benutzt
2010-06-06 10:18:35 CEST TIPP: Prüfen Sie, ob irgendwelche alten Serverprozesse noch laufen und beenden Sie diese.


Ich benutze die Version 8.4

Vielen dank schonmal im Voraus

Was wurde seitdem verändert (Hardware, Software, Antivirus, Firewall,…)? Grundsätzlich wäre auch wichtig zu wissen, welches OS auf dem Server läuft.


Kannst du ermitteln,
a) welcher Prozess den Crash verursacht (da ich sowieso vermute, dass es Windows ist, schau im Ereignisprotokoll nach)
b) ob die Tabelle, um die es geht, ggf. von einer AV-Software kaputt gemacht wurde

Hier sind noch zwei Links aus der Mailingliste, die sich auch damit beschäftigen:

PostgreSQL crashes
DB terminating

Entscheidene Frage sollte für dich aber sein, was sich verändert hat, seidem des Problem auftritt…

Vielen Dank für die schnelle Antwort.

Plattform: Windows Server 2003 (32Bit, 3GB Ram)

Die AV-Software (Panda) hat keinerlei Aktivitäten in dem Data-Verzeichnis verzeichnet.
Egal, ob ich nun den von uns geschriebenen Prozess oder die SQL-Konsole des pgAdmin benutze, die DB terminiert regelmäßig, wenn ich bestimmte Daten aufrufe.
Ein Versuch, einen Dump (Plain in SQL) und eine Wiederherstellung in eine neue DB aufgrund der SQL-Datei war erfolgreich, doch das Problem tritt weiterhin auf. Portiere ich die Db auf einen anderen Server, so tritt dieses Problem nicht auf. Eine komplette Postgres-Neuinstallation brachte auch nichts.

So ähnlich hätte ich es auch vermutet.
Bislang scheint es niemanden zu geben, der die Ursache sicher eingrenzen kann. In fast allen (mir bekannten) Fällen ist AV-Software oder Firewall Ursache dafür, manchmal sogar nur Fragmente dieser (ggf. auch schon deinstallierten) Software. Soll heißen, ich würde dir empfehlen, dass Serversystem neu aufzusetzen, da du sonst die “Nadel im Heuhaufen” suchst. Das PostgreSQL selbst läuft ja mit deinen Daten auf einem anderen System, sodass in der restlichen Umgebung des Servers die Ursache zu suchen wäre…

Vielleicht noch ein Tipp am Rande: dreh mal das Debug-Level ordentlich hoch, evtl. gibt’s ja doch noch einen Hinweis.

Ich kann da murphy nur zustimmen - AV-Software macht da mehr kaputt als es hilft.

Ach so, noch eine Frage - das ist aber mehr ein Schuß ins Blaue: wie ist deine “shared_buffers” Einstellung?

ich denke, dass das die beste Möglichkeit sein wird

shared_buffers=32MB
temp_buffers=8MB

Müsste doch reichen. Wie kann ich das feststellen?

Mir ist ebenfalls aufgefallen, dass wenn ich ein SUB-SELECT folgender Art anwende
SELECT * FROM tabelle1 WHERE id IN (SELECT id FROM tabelle2 WHERE …)
und die tabelle2 mehr als zwei Zeilen ausgibt, dass der Fehler dann vermehrt auftritt. Bei nur einer Zeile in Ergebnis der tabelle1 ist alles in Ordnung.
Sobald ich das in Join umwandle geht es auch???
Kann damit eventuell jemand was anfangen? Oder benötigt in Sub-SELECT soviel mehr buffer?

Setz mal “shared_buffers” höher, auf 1/4 bis 1/6 vom Hauptspeicher. Und schau, ob dann die Datenbank noch abstürzt.

Leider schmiert die DB bei 1024MB shared_buffer immernoch ab. Kann ich irgendwie übergrüfen, ob die AV etwas beschädigt hat? Wenn ich die Tabellen einzeln aufrufe, dann funktioniert alles?!

Ich habe mal eine Analyse drüberlaufen lassen. Was sagen mir in folgedem bericht die toten Zeilen:
INFO: »tabelle…«: 16 von 16 Seiten gelesen, enthalten 643 lebende Zeilen und 7 tote Zeilen; 643 Zeilen in Stichprobe, schätzungsweise 643 Zeilen insgesamt

Analyze hilft da nicht weiter.

Meine Idee war nur, dass die DB ev. viel zu wenig Speicher für die anstehende Arbeit hat. Aber eigentlich dürfte sie deswegen nicht abstürzen - das habe ich nur einmal im Zusammenhang mit einem Monitoring-System erlebt. Der Cluster hat die DB umgeschaltet, weil aufgrund des Loads die DB nicht rechtzeitig genug antworten konnte.

Das sagt nur, daß aufgrund von UPDATE oder DELETE noch 7 nicht mehr benötigte Versionen alter Datensätze vorhanden sind, ein Preis, den PostgreSQL für MVCC zahlt und der VACUUM nötig macht.

Andreas

Nur der Vollständigkeit halber sei erwähnt, dafür gibt es das Programm VACUUM, das räumt die “toten Tupel” weg… :slight_smile:

Wenn ich nun die client_min_messages, log_min_messages und log_error_verbosity werte auf debug5 setze, bekomme ich folgenden LOG:

davor nur std.sql

2010-06-08 18:32:52 CEST ANWEISUNG: SELECT n.nspname,c.relname,a.attname,a.atttypid,a.attnotnull,a.atttypmod,a.attlen,a.attnum,pg_get_expr(def.adbin, def.adrelid) as adsrc,dsc.description FROM pg_catalog.pg_namespace n JOIN pg_catalog.pg_class c ON (c.relnamespace = n.oid) JOIN pg_catalog.pg_attribute a ON (a.attrelid=c.oid) LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND a.attnum = def.adnum) LEFT JOIN pg_catalog.pg_description dsc ON (c.oid=dsc.objoid AND a.attnum = dsc.objsubid) LEFT JOIN pg_catalog.pg_class dc ON (dc.oid=dsc.classoid AND dc.relname=‘pg_class’) LEFT JOIN pg_catalog.pg_namespace dn ON (dc.relnamespace=dn.oid AND dn.nspname=‘pg_catalog’) WHERE a.attnum > 0 AND NOT a.attisdropped AND c.relname LIKE E’lager_artikel’ AND a.attname LIKE E’%’ ORDER BY nspname,relname,attnum
2010-06-08 18:32:52 CEST DEBUG: StartTransactionCommand
2010-06-08 18:32:52 CEST ANWEISUNG: SELECT …<hier kommt der große Join inkl. SubSelect>

2010-06-08 18:32:52 CEST DEBUG: StartTransaction
2010-06-08 18:32:52 CEST ANWEISUNG: SELECT …<hier kommt der große Join inkl. SubSelect nochmals>

2010-06-08 18:32:52 CEST DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2010-06-08 18:32:52 CEST ANWEISUNG: SELECT …<hier kommt der große Join inkl. SubSelect und nochmals>

2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 6 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST DEBUG: Serverprozess (PID 6480) beendete mit Status 128
2010-06-08 18:32:52 CEST LOG: Serverprozess (PID 6480) beendete mit Status 128
2010-06-08 18:32:52 CEST LOG: aktive Serverprozesse werden abgebrochen
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 3360
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 7992
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 5852
2010-06-08 18:32:52 CEST WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses
2010-06-08 18:32:52 CEST 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.
2010-06-08 18:32:52 CEST TIPP: In einem Moment sollten Sie wieder mit der Datenbank verbinden und Ihren Befehl wiederholen können.
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST WARNUNG: breche Verbindung ab wegen Absturz eines anderen Serverprozesses
2010-06-08 18:32:52 CEST 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.
2010-06-08 18:32:52 CEST TIPP: In einem Moment sollten Sie wieder mit der Datenbank verbinden und Ihren Befehl wiederholen können.
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 7608
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 3560
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: sending SIGQUIT to process 5664
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: Serverprozess (PID 7992) beendete mit Status 2
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST DEBUG: Serverprozess (PID 3360) beendete mit Status 2
2010-06-08 18:32:52 CEST DEBUG: reaping dead processes
2010-06-08 18:32:52 CEST LOG: alle Serverprozesse beendet; initialisiere neu
2010-06-08 18:32:52 CEST DEBUG: shmem_exit(1): 2 callbacks to make
2010-06-08 18:32:52 CEST DEBUG: invoking IpcMemoryCreate(size=1099546624)
2010-06-08 18:33:02 CEST FATAL: bereits bestehender Shared-Memory-Block wird noch benutzt
2010-06-08 18:33:02 CEST TIPP: Prüfen Sie, ob irgendwelche alten Serverprozesse noch laufen und beenden Sie diese.
2010-06-08 18:33:02 CEST DEBUG: shmem_exit(1): 0 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: proc_exit(1): 1 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: exit(1)
2010-06-08 18:33:02 CEST DEBUG: shmem_exit(-1): 0 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: proc_exit(-1): 0 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: Logger fährt herunter
2010-06-08 18:33:02 CEST DEBUG: shmem_exit(0): 0 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: proc_exit(0): 0 callbacks to make
2010-06-08 18:33:02 CEST DEBUG: exit(0)

Leider kann ich daraus nicht die Ursache erkennen. Könnte mir hierbei evtl jemand helfen?

  1. Was steht denn im Ereignisprotokoll des Betriebssystems?

  2. Gibt es vor diesem Error-Stack noch Einträge im PG-Log, die relevant sein könnten? In diesem Auszug steht die Ursache m. E. nicht!

“Die Beschreibung der Ereigniskennung ( 0 ) in (FormService.exe ) wurde nicht gefunden. Der lokale Computer verfügt nicht über die zum Anzeigen der Meldungen von einem Remotecomputer erforderlichen Registrierungsinformationen oder DLL-Meldungsdateien. Möglicherweise müssen Sie das Flag /AUXSOURCE= zum Ermitteln der Beschreibung verwenden. Weitere Informationen stehen in Hilfe und Support. Ereignisinformationen: Unsupported operation.”


s.o.

Hast du eine Idee, wozu diese FormService.exe gehört? Evtl. ist das der “andere Serverprozess”?

Also das Log der Datenbank sagt nichts zum Absturz aus.

grübel
Wenn der entsprechende Prozess vom Betriebssystem abgeschossen wurde (warum auch immer) hat der Prozess keine Gelegenheit mehr, irgendetwas ins Log zu schreiben.
Daher sieht man dort wohl auch nichts.

Richtig.
Ich denke, der einzige Hinweis ist nun nur noch diese FormService.exe. K. A. wozu die gehört, zu DB-Server jedenfalls nicht.
Wenn das auch keine Spur ist, bin ich für Plan B, Serversystem neu installieren.

Bitte entschuldigt. Der Formservice ist ein von uns entwickelter Service. Das spielt aber in dem Sinn keine Rolle, da die DB ausch dann crashed, wenn ich dieselbe Anfrage wie im FormService.exe im SQl-Query-Browser der pgAdmin ausführe. Die Fehlermeldung dort bringt nur Fehler
Mehr leider nicht.