Server startet nicht bei shared_buffer > 900MB | Windows 2003-Server

Ich habe auf zwei verschiedenen Systemen das gleiche Problem:
Es besteht jeweils ein frisch installiertes Windows, 2003R2-Standard-Server, 32bit, auf dem ein PostgreSQL-Server 8.2.7.1 bzw. auf dem anderen ein PostgreSQL-Server 8.3.7.1 läuft. Die Maschinen haben jeweils 4GB Hauptspeicher. Es ist auch alles toll, die Datenbanken laufen, bis ich in der Konfiguration den shared_buffer auf über 900MB stelle. Beim anschließenden Neustart des Datenbankservers kommt der Dienst nicht mehr hoch, im Ereignisprotokoll steht bei der 8.2er Datenbank

Ereignistyp: Fehler Ereignisquelle: PostgreSQL Ereigniskategorie: Keine Ereigniskennung: 0 Datum: 14.08.2009 Zeit: 06:40:05 Benutzer: Nicht zutreffend Computer: MAPNE03 Beschreibung: 2009-08-14 06:40:05.913 [3780:1] @ FATAL: shmat(id=1884) failed: Not enough space

bzw. bei der 8.3er

Ereignistyp: Fehler
Ereignisquelle: PostgreSQL
Ereigniskategorie: Keine
Ereigniskennung: 0
Datum: 19.08.2009
Zeit: 10:05:03
Benutzer: Nicht zutreffend
Computer: S017
Beschreibung: 2009-08-19 10:05:03 CEST FATAL: konnte Shared-Memory-Segment nicht erzeugen: 5
2009-08-19 10:05:03 CEST DETAIL: Fehlgeschlagener Systemaufruf war MapViewOfFileEx

Was will mir der Autor damit sagen??? Wieso ist es nicht möglich, mehr Speicher zu allokieren?

Es ist nicht so, dass der Hauptspeicher aufgebraucht ist. Lt AIDA steht folgendes zur Verfügung:

Hauptspeicher:
Gesamt: 3839MB
Belegt: 1394MB
Frei: 2445MB
** macht 36% **

Swap/Auslagerungsdatei:
Gesamt: 7536MB
Belegt: 1402MB
Frei: 6134MB
** macht 19% **

Nun die abschließende Frage: Kennt das jemand? Was kann ich hier machen? Warum nimmt mir den hohen shared_beffer-Wert der DB-Server so übel??? In den Logs steht nichts, es scheint, als wenn der Server gar nicht so weit kommt.

thx, murphy

Warum meinst Du, soviel zu brauchen? Hast Du PostgreSQL: Documentation: Manuals: PostgreSQL 8.4: Managing Kernel Resources schon entdeckt? Must mal schauen, was da für Deine OS-Distribution zu finden ist. Ansonsten halte ich work_mem z.B. für wichtiger.

Andreas

der nutzbare virtuelle adressraum eines prozesses unter windows ist 2 GB gross (die unteren 2GB fuer normale prozesse) … die oberen anderen 2 GB (zu 32 bit) sind reserviert fuers system

nun willst du mehr als 900MB (wieviel mehr?) als shared reservieren … d.h. du hast dann nur noch ca. 1GB fuer andern kram work mem und heap und stack usw. moeglicherweise benutzte pg noch memory mapped files - die auch wieder virtuellen adressraum beanspruchen - das läppert sich … scheint mir also schon realistisch so … ich habe mal gehoert dass man das verhaeltnis auch 3 GB : 1 GB (system) aendern kann

wie gesagt - pro prozess … die vielen postgres-prozesse insgesamt koennen unter windows server 2003 in der summe natuerlich auch mehr als 4 GB effektiv nutzen …

Deine Aussage würde bedeuten, von den knapp 4GB stehen dem DB-Server ohnehin schon nur die Halfte, also 2GB zur Verfügung. Ich würde nun natürlich versuchen, diese so geschicktwie möglich aufzuteilen. Da auf dem Server nichts anderes läuft, brauche ich nun nur eine passende Aufteilung für den DB-Server zu finden.
Work_mem ist doch pro Operation (default meine ich 1 MB), ich habe ca. 100 Connections, also max. 100MB aus work_mem. Das ist nicht so viel. Für maintenance_work_mem habe ich 256MB eingestellt, da auto_vacuum eingeschaltet ist und ich nicht möchte, dass das System dadurch erheblich ausgebremst wird. Macht aber immernoch nicht mehr als 2GB.

Welche Parameter allokieren denn noch Speicher, deine Aussage, “das läppert sich”, macht ja Sinn. natürlich

Eben. Und work_mem hat erheblichen Einfluß auf z.B. Sortieroperationen.

Das, was PG nicht nutzt an Speicher, nutzt das OS als Cache. Sollte es zumindest.

Andreas

Work_mem ist doch insbesondere für Index-Scans und Sortieroperationen da, oder. Mir fehlt diesbezüglich ein Gefühl dafür, ob dieser Default mit 1MB okay ist, oder ob das jenseits von gut und böse ist. Gibt es dafür eine Faustregel???

Mein Ansatz war der, dass der DB-Server die oft benötigten Tabellen cachen kann, und dann hilft viel Speicher viel… :slight_smile:

murphy

PS: postgresql-8.4 kann ich noch nicht einsetzen, da das psql-Interface noch nicht verifiziert wurde (von mir).

…und ist ein work_mem mit 1MB ein brauchbarer Wert??? Ich habe derzeit keine Vorstellung, wieviel Speicher eine “durchschnittliche” Sortieroperation erfordert (wohl wissend, dass das von der zu sortierenden Menge abhängt…).

Das kann dir PostgreSQL sogar genau sagen. Nutze EXPLAIN und EXPLAIN ANALYZE.

Siehe auch Antwort von ads. Wenn work_mem nicht ausreicht, werden Sortieroperationen, aber auch bestimmte Joins (die darauf basieren) vom RAM auf Platte verlagert. Also, Zwischenresultat auf Platte schreiben, dort sortieren, wieder auslesen. Also, wie ads ganz richtig sagte, EXPLAIN ANALYSE ist Dein Freund.

Andreas

OK, die Querys werde ich mir ansehen, ggf. ist an der Stelle etwas an Performance rauszuholen (die Wahrscheinlichkeit, glaube ich, ist recht hoch), aber: deshalb startet der Server immer noch nicht bei shared_buffer > 900MB. Stellt PG noch weitere (relevante, sprich speicherfressende) Parameter bereit, die ich hier ggf. übersehe. Ich denke nämlich, der work_mem wird ja erst zur Laufzeit gezogen, der Server startet ja aber gar nicht. Ich glaube nicht, dass das mein Problem ist (wenn auch ein wichtiger Hinweis…).

Dein Problem ist, daß Dein OS das nicht zur Verfügung stzellen kann.

Noch einmal: schaue Dir an, was Explain Analyse Dir sagt.

Andreas

Okay, werde mit explain analyse mal auf die Suche nach meinem Speicher gehen :wink:

Zunächst herzlichen Dank an alle…

murphy