Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

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

  1. #1
    murphy ist offline Erfahrener Benutzer
    Registriert seit
    19.08.2009
    Beiträge
    165

    Standard 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

  2. #2
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Nähe Dresden
    Beiträge
    5.337

    Standard

    Zitat Zitat von murphy Beitrag anzeigen
    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  3. #3
    symbiont ist offline Erfahrener Benutzer
    Registriert seit
    17.03.2008
    Ort
    NULL
    Beiträge
    1.320

    Standard

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

  4. #4
    murphy ist offline Erfahrener Benutzer
    Registriert seit
    19.08.2009
    Beiträge
    165

    Standard

    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*

  5. #5
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Nähe Dresden
    Beiträge
    5.337

    Standard

    Zitat Zitat von murphy Beitrag anzeigen
    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.
    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  6. #6
    murphy ist offline Erfahrener Benutzer
    Registriert seit
    19.08.2009
    Beiträge
    165

    Standard

    Zitat Zitat von akretschmer Beitrag anzeigen
    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
    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...

    murphy

    PS: postgresql-8.4 kann ich noch nicht einsetzen, da das psql-Interface noch nicht verifiziert wurde (von mir).
    Geändert von murphy (19.08.2009 um 19:21 Uhr)

  7. #7
    murphy ist offline Erfahrener Benutzer
    Registriert seit
    19.08.2009
    Beiträge
    165

    Standard

    ...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...).

  8. #8
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.020

    Standard

    Das kann dir PostgreSQL sogar genau sagen. Nutze EXPLAIN und EXPLAIN ANALYZE.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  9. #9
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Nähe Dresden
    Beiträge
    5.337

    Standard

    Zitat Zitat von murphy Beitrag anzeigen
    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...

    murphy

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

    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  10. #10
    murphy ist offline Erfahrener Benutzer
    Registriert seit
    19.08.2009
    Beiträge
    165

    Standard

    Zitat Zitat von akretschmer Beitrag anzeigen
    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...).

Seite 1 von 2 12 LetzteLetzte

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum