Re: Signal 11

From: Martin Spott <Martin(dot)Spott(at)mgras(dot)net>
To: pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: Signal 11
Date: 2010-12-20 21:01:41
Message-ID: ieog7l$s86u$1@osprey.mgras.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

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.
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.
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.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

In response to

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Peter Eisentraut 2010-12-20 22:47:41 Re: Funktionsargument für eine "field IN ($1)" Bedingung
Previous Message Andreas Kretschmer 2010-12-20 19:25:25 Re: Signal 11