Signal 11

Tach zusammen,

ich habe da eine PostgreSQL/PostGIS-Datenbank (9.0.1/1.5.2), die laeuft
unter Solaris10 auf Intel-Xeon's. Bei bestimmten Operationen faellt
der den fraglichen Client bedienende Prozess auf den Bauch und sagt
"server process (PID ) was terminated by signal 11".

Ich hab' mal testhalber versucht, der Ursache mit verschiedenen
Einstellungen fuer "log_min_messages" und "log_min_error_statement" auf
die Schliche zu kommen. Das fuehrte - erwartungsgemaess - zu tausenden
Zeilen an Log-Mitschrieb, trotzdem war es mir nicht vergoennt, einen
qualifizierten Zusammenhang zwischen Ursache und Wirkung herzustellen
..... woran auch immer das jetzt lag ;-)

Bevor ich jetzt die Log-Level alle bis zum Anschlag aufdrehe und dann
soviel Log bekomme, dass man es kaum mehr auswerten kann, dachte ich
mir, ich frage hier man freundlich nach ein paar Tips, wie man sowas
"ueblicherweise" angeht.

Fuer Hilfe zur Selbsthilfe dankbar,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
------------------------------------------------------------ --------------

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Signal 11

Martin Spott wrote:

> Tach zusammen,
>=20
> ich habe da eine PostgreSQL/PostGIS-Datenbank (9.0.1/1.5.2), die laeuft
> unter Solaris10 auf Intel-Xeon's. Bei bestimmten Operationen faellt
> der den fraglichen Client bedienende Prozess auf den Bauch und sagt
> "server process (PID ) was terminated by signal 11".

Signal 11 könnte durchaus ein Zeichen kapotter Hardware sein. Prüfe m=
al
den RAM. Oder kannst Du es (den Crash) gezielt provozieren?


Andreas
--=20
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889=
°

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Signal 11

N'Abend Andreas, Dank fuer Deine Rueckmeldung - dazu so schnell.

Andreas Kretschmer wrote:

> Signal 11 könnte durchaus ein Zeichen kapotter Hardware sein. Prüfe=
mal
> den RAM. Oder kannst Du es (den Crash) gezielt provozieren?

Ja, ich kenne den 'klassischen' Signal 11 unter Linux noch aus den
Zeiten, als die beruehmte FAQ dazu entstand :-)

Im vorliegenden Fall will ich aber nicht so ganz daran glauben, weil a)
das Betriebssystem garnix dazu sagt und b) weil die Hardware aus einer
Manufaktur stammt, die ich zumindest bisher als ueber solche Fehler
vergleichsweise erhaben betrachtet hatte. Anders gesagt: Wenn ich in
Vergangenheit auf einer Sun-Maschine wirklich mal Komplikationen mit
dem RAM hatte, was selten genug vorkam, dann fand sich ueblicherweise
eine Meldung ueber den Fehler im Syslog, die auch gleich die
Bezeichnung des Sockels enthielt, in dem der defekte Riegel steckte -
so, wie es auf dem Mainboard beschriftet war.

Jetzt bekomme ich rein ueberhaupt nichts in der Art und vermute daher
eher entweder einen Fehler in der Software oder halt, das ist bisher
meine Annahme, einen Konfigurationsfehler meinerseits.
Erst habe ich nachgeguckt, ob das Betriebssystem genuegend Shared
Memory bereitstellt. Eigentlich sollte PostgreSQL andernfalls ja schon
beim Start meckern, tat es aber nicht. Trotzdem habe ich im
Betriebssystem mal mehr als das Doppelte dessen konfiguriert, was der
Server meinen ueberschlaegigen Berechnungen nach beanspruchen duerfte.=20
Das macht aber keinen Unterschied, eigentlich sind die Ressourcen-
Einstellungen in PostgreSQL sogar eher konservativ.
Das RAM zu pruefen ist obendrein nicht ohne Huerden, denn die Kiste
steht in San Diego in irgendeinem Rechenzentrum und wird mir kostenfrei
zur Nutzung ueberlassen. Bevor ich da jemanden losschicke, will ich
gerne die Alternativen ausschoepfen ....

Kurios ist, dass das System in identischer Konfiguration schon
unzaehlige aehnliche Operationen ueberlebt und korrekt ausgefuehrt hat
- es geht um die Berechnung der Different zwischen zwei geographischen
Polygonen. Wenn ich das jetzt mit einer bestimmten Paarung von
Polygonen laufen lasse, faellt der Datenbankprozess reproduzierbar (!!)
auf die Nase.
Wenn ich mir waehrenddessen den Server mit einem 'top' oder 'iostat'
angucke, dann passiert da nichts weltbewegendes. Es wird halt relativ
viel auf die Platte geschrieben (einige Groessenordnungen mehr, als
gelesen wird), was ich als Hinweis dafuer werte, dass der Server
irgendwelche Zwischenergebnisse in eine temporaere Tabelle schreibt.

Moeglich auch, dass diejenige Bibliothek, von der die Geometrie-
Operation letztendlich ausgefuehrt wird - das PostGIS-Modul wird dazu
gegen die GEOS-Bibliothek gelinkt - mit der Aufgabe nicht klarkommt.=20
Bevor ich mich aber mit dem GDB da draufsetze und die Stecknadel im
Heuhaufen suche, haette ich ganz gerne von einer sachkundigen Person
bestaetigt, dass dem Problem mit PostgreSQL-Bordmitteln nicht
beizukommen ist :-)

Schoene Gruesse,
Martin.
--=20
Unix _IS_ user friendly - it's just selective about who its friends are =
!
------------------------------------------------------------ -------------=
-

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Signal 11

On mån, 2010-12-20 at 19:06 +0000, Martin Spott wrote:
> ich habe da eine PostgreSQL/PostGIS-Datenbank (9.0.1/1.5.2), die laeuft
> unter Solaris10 auf Intel-Xeon's. Bei bestimmten Operationen faellt
> der den fraglichen Client bedienende Prozess auf den Bauch und sagt
> "server process (PID ) was terminated by signal 11".

> Bevor ich jetzt die Log-Level alle bis zum Anschlag aufdrehe und dann
> soviel Log bekomme, dass man es kaum mehr auswerten kann, dachte ich
> mir, ich frage hier man freundlich nach ein paar Tips, wie man sowas
> "ueblicherweise" angeht.

core-Datei finden, Debugger dranhängen und Backtrace ansehen. Wie da=
s
genau auf Solaris geht, kann ich jetzt nicht sagen, aber auf Linux wä=
re
es

gdb .../installation/bin/postgres $PGDATA/...irgendwo.../core

in gdb dann:

(gdb) backtrace

Wenn du keine core-Datei findest, mal schauen, ob ulimit -c gesetzt ist.


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Signal 11

Moins,

das hatte ich mal mit defektem Ram. Bei mir kam das immer recht
sporadisch an unterschiedlichen Stellen.

Gruss
Thomas

Am 20.12.2010 20:06, schrieb Martin Spott:
> Tach zusammen,
>
> ich habe da eine PostgreSQL/PostGIS-Datenbank (9.0.1/1.5.2), die laeuft
> unter Solaris10 auf Intel-Xeon's. Bei bestimmten Operationen faellt
> der den fraglichen Client bedienende Prozess auf den Bauch und sagt
> "server process (PID) was terminated by signal 11".
>
> Ich hab' mal testhalber versucht, der Ursache mit verschiedenen
> Einstellungen fuer "log_min_messages" und "log_min_error_statement" auf
> die Schliche zu kommen. Das fuehrte - erwartungsgemaess - zu tausenden
> Zeilen an Log-Mitschrieb, trotzdem war es mir nicht vergoennt, einen
> qualifizierten Zusammenhang zwischen Ursache und Wirkung herzustellen
> .... woran auch immer das jetzt lag ;-)
>
> Bevor ich jetzt die Log-Level alle bis zum Anschlag aufdrehe und dann
> soviel Log bekomme, dass man es kaum mehr auswerten kann, dachte ich
> mir, ich frage hier man freundlich nach ein paar Tips, wie man sowas
> "ueblicherweise" angeht.
>
> Fuer Hilfe zur Selbsthilfe dankbar,
> Martin.


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Signal 11

Tach zusammen,

Peter Eisentraut wrote:

> core-Datei finden, Debugger dranhängen und Backtrace ansehen. Wie das
> genau auf Solaris geht, kann ich jetzt nicht sagen, aber auf Linux wä=
re
> es
>=20
> gdb .../installation/bin/postgres $PGDATA/...irgendwo.../core

Jau, das ist unter Solaris nicht anders :-)
Ich bedanke mich fuer die Rueckmeldungen. Inzwischen habe ich
Anzeichen, dass tatsaechlich die GEOS-Bibliothek mit den zu
verschneidenden Geometrien nicht klarkommt und infolgedessen den ganzen
Server in Mitleidenschaft zieht.

> Wenn du keine core-Datei findest, mal schauen, ob ulimit -c gesetzt ist=
..

Der 'core' ist ueber 4 GByte gross - und wahrscheinlich der eigentliche
Grund fuer die ausgedehnten Schreib-Aktivitaeten auf der Festplatte :-)

Tschuess,
Martin.
--=20
Unix _IS_ user friendly - it's just selective about who its friends are =
!
------------------------------------------------------------ -------------=
-

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Signal 11

Moin zusammen, ich have versucht, Eure Rueckmeldungen zu beherzigen -
allerdings mit eher duerftigem Erfolg. Der GDB, den ich darauf
angesetzt habe, meint, er koenne die ELF-Binaries auf dem Solaris nicht
interpretieren - ich hab' extra eine Variante des GDB zur Untersuchung
von 64-bit-Binaries gebaut und die meint etwas im Sinne von "cannot
read Symbols". Der Solaris-eigene 'dbx', wie genial, schmiert selber
mit einem core-dump ab ....

Es gibt hingegen Berichte, die besagen, dass es bei mit aelteren
Versionen des GCC gebauten PosgtgreSQL/PostGIS nicht zuverlaessig
funktionierte, Exceptions aus der GEOS-Bibliothek aufzufangen. Das ist
offenbar der Grund dafuer, dass bei meiner Installation immer gleich
die ganze Datenbank angehalten wurde. Auf anderen Installationen, etwa
unter Linux, wird effektiv ein Fehler ausgegeben, der auf
Komplikationen in GEOS hinweist.

Besten Dank fuer Eure Beteiligung,

Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
------------------------------------------------------------ --------------

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein