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

Thema: Zu viele Updates/Insert macht Probleme mit WAL

  1. #1
    traxanos ist offline Benutzer
    Registriert seit
    27.05.2008
    Beiträge
    96

    Standard Zu viele Updates/Insert macht Probleme mit WAL

    Hi

    ich befülle eine Tabelle über mittels des hier beschriebenen Weges:
    http://www.pg-forum.de/trigger-und-f...t-trigger.html

    Bei Mengen bis 400.00 Zeilen in einer Transaktion läuft alles schnell und schön. Danach erhalte ich folgende Hinweise aus den Logs des Servers.

    Code:
    LOG:  checkpoints are occurring too frequently (19 seconds apart)
    HINT:  Consider increasing the configuration parameter "checkpoint_segments".
    Da ich dachte das ich zuwenig Segmente habe, um die Transaktion im WAL vorzuhalten, hab ich den Wert testweise auf 6 erhöht. Allerdings hat sich nichts geändert.

    Laut Betriebsystem hab ich ca. 250GB auf die Festplatte geschrieben (nicht belegt!). Die Datenbank (komplett) selbst ist mit allen Daten gerade mal 4 GB groß. Die Schreibrate steigt, sobald die Meldung im Log erscheint, auf 5-20M/s und die E/A Rate bis auf 1200 pro Sekunde (Betriebsystemweit). Auch komisch ist das die ersten 500.000 Datensätze problemlos über die gleiche Methode eingespielt wurden. Folgende Werte habe schrittweise nach oben angepasst auf:

    Code:
    shared_buffers = 1024MB
    temp_buffers = 512MB
    work_mem = 256MB
    maintenance_work_mem = 256MB
    checkpoint_segments = 6
    Für Tipps wäre ich dankbar

  2. #2
    traxanos ist offline Benutzer
    Registriert seit
    27.05.2008
    Beiträge
    96

    Standard

    Kleiner Nachtrag den Aritkel Old Nabble - PostgreSQL - general - Checkpoints are occurring too frequently... hab ich schon gelesen
    Die Daten sind fast alle neu -> also werden als Insert verarbeitet.

    Code:
    ERROR:  canceling autovacuum task
    CONTEXT:  automatic vacuum of table "qmonitor_development.public.basic_datas"
    Das bekomm ich auch noch wobei ich den Import schieben kann oder?

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

    Standard

    Zitat Zitat von traxanos Beitrag anzeigen
    Hi

    ich befülle eine Tabelle über mittels des hier beschriebenen Weges:
    http://www.pg-forum.de/trigger-und-f...t-trigger.html

    Bei Mengen bis 400.00 Zeilen in einer Transaktion läuft alles schnell und schön. Danach erhalte ich folgende Hinweise aus den Logs des Servers.

    Code:
    LOG:  checkpoints are occurring too frequently (19 seconds apart)
    HINT:  Consider increasing the configuration parameter "checkpoint_segments".
    Da ich dachte das ich zuwenig Segmente habe, um die Transaktion im WAL vorzuhalten, hab ich den Wert testweise auf 6 erhöht. Allerdings hat sich nichts geändert.

    Laut Betriebsystem hab ich ca. 250GB auf die Festplatte geschrieben (nicht belegt!). Die Datenbank (komplett) selbst ist mit allen Daten gerade mal 4 GB groß. Die Schreibrate steigt, sobald die Meldung im Log erscheint, auf 5-20M/s und die E/A Rate bis auf 1200 pro Sekunde (Betriebsystemweit). Auch komisch ist das die ersten 500.000 Datensätze problemlos über die gleiche Methode eingespielt wurden. Folgende Werte habe schrittweise nach oben angepasst auf:

    Code:
    shared_buffers = 1024MB
    temp_buffers = 512MB
    work_mem = 256MB
    maintenance_work_mem = 256MB
    checkpoint_segments = 6
    Für Tipps wäre ich dankbar
    Ja, du kannst checkpoint_segments auch noch weiter erhöhen, aber work_mem auf einen so hohen Wert zu setzen ist riskant: angenommen, Du hast ein Select mit 4 Notes, die alle für Hashing oder Sort work_mem in dieser Größenordnung verbrauchen. Dann belegt dieses SELECT schon mal bis zu einem GByte RAM. Hast Du nun noch 20 solcher Abfragen gleichzeitig und keine 20 GByte RAM frei, fängt die Kiste wild zu swappen an. Vorsicht also bei work_mem!

    Wenn dieser Insert einmalig ist, würde ich die Warnungen schlicht ignorieren.

    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

  4. #4
    traxanos ist offline Benutzer
    Registriert seit
    27.05.2008
    Beiträge
    96

    Standard

    Dachte auch mehr an Punkt zur Orientierung.

    Das mit dem wor_men hab ich scheinbar falsch verstanden, sprich werd mir das gleich nochmal die Doku genauer studieren.
    Ich hab das nun mal so angepasst und schau mal was passiert. Der Import läuft leider nur sehr lange. Werde aber berichtet ob es hilft.

    Code:
    shared_buffers = 1024MB
    temp_buffers = 256MB
    work_mem = 16MB
    maintenance_work_mem = 128MB
    max_stack_depth = 2MB
    checkpoint_segments = 40 # 1,2 GB müssten das dann sein

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

    Standard

    Zitat Zitat von traxanos Beitrag anzeigen
    Dachte auch mehr an Punkt zur Orientierung.

    Das mit dem wor_men hab ich scheinbar falsch verstanden, sprich werd mir das gleich nochmal die Doku genauer studieren.
    Ich hab das nun mal so angepasst und schau mal was passiert. Der Import läuft leider nur sehr lange. Werde aber berichtet ob es hilft.

    Code:
    shared_buffers = 1024MB
    temp_buffers = 256MB
    work_mem = 16MB
    maintenance_work_mem = 128MB
    max_stack_depth = 2MB
    checkpoint_segments = 40 # 1,2 GB müssten das dann sein
    Läuft der Import innerhalb einer einzigen TX? Falls nein: dies wäre u.U. sinnvoll ...


    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
    traxanos ist offline Benutzer
    Registriert seit
    27.05.2008
    Beiträge
    96

    Standard

    Wenn dieser Insert einmalig ist, würde ich die Warnungen schlicht ignorieren.
    Naja die Insert werden später weniger pro Lauf (Transaktion) aber ich sehe das auch nicht als Fehler, sondern als Hinweis. War mir aber nicht sicher ob das auch der Grund für das Performanceproblem ist.

    Mit den neuen Einstellungen brauchen die ersten 10.000 Datensätze superlange. Mist...

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

    Standard

    Zitat Zitat von traxanos Beitrag anzeigen

    Mit den neuen Einstellungen brauchen die ersten 10.000 Datensätze superlange. Mist...
    Ich schlage vor, wir warten mal auf ads ...

    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

  8. #8
    traxanos ist offline Benutzer
    Registriert seit
    27.05.2008
    Beiträge
    96

    Standard

    Jo, ich werde aber weiter testen um dann evtl auch mehr Infos zu liefern. Evtl hab ich sogar noch ne starke Maschine im RZ frei, die mehr als 4GB hat.

    Nachtrag: Sobald ich den work_mem auf 64M und den Shared auf 1,5G erhöhe ist die 10k keine Hürde mehr. Ich lass jetzt mal laufen und schau wies läuft.
    Nachtrag2: Ab ca. 250.000 stock er alle 10.000 bis 20.000 Rows und schreibt wild auf der Platte rum. Ab 300.000 wird das ganze immer langsamer im gesamten.
    Geändert von traxanos (19.05.2010 um 14:09 Uhr)

  9. #9
    traxanos ist offline Benutzer
    Registriert seit
    27.05.2008
    Beiträge
    96

    Standard

    Unglaublich schon wieder bei ca. 430.000 stop alles. Anhand der Sequenzen kann ich sehen das 1-3 Zeilen pro Minute geschrieben werden. Einzig der Speicherverbrauch hat sich gebessert er swap nicht mehr wegen der DB. Die DB Verbraucht nicht mal mehr 100 für den entsprechenden Prozess. Hin und wieder steigt die CPU Last und geht dann wieder runter. Die Schreiblast liegt weiter hin 5MB/s +.

  10. #10
    traxanos ist offline Benutzer
    Registriert seit
    27.05.2008
    Beiträge
    96

    Standard

    Ich habe es wohl gefunden das Problem. Ab 430.000 sind die Zeilen alle Updates. Updates werden in der selbstgebauten Funktion wie folge gebaut:

    Code:
    UPDATE table SET neuewerte WHERE spaltenaus demuniqueconstrain AND updated_at < x
    Führe ich dieses Update manuell aus, dauert es 12ms. Führe ich es in einer Funktion (Update als einziges im Body) aus, dauert der Funktionsaufruf 4sekunden. Dann habe ich noch 2 RAISE eingebaut um sicher zu sein das es das Update und nicht die Funktion selber ist. Erstes Meldung kam sofort die 2 nach den ca 4 sek. Dann habe ich das Update Analysiert was mir auch gezeigt hat das er den UniqIndex nutzt. Die Analyse des Funktionsaufruf selbst zeigt mir leider nur die Info über die Funktion selbst, aber nicht über die Abfragen in der Funktion.

    Da ich aber in Zukunft mehr Updates als Insert haben werde, wollte ich sowieso die Funktion umbauen das zuerst ein select/update gemacht wird:

    Code:
    CREATE OR REPLACE FUNCTION funcname(felder) RETURNS void AS
    $$
    DECLARE
     r RECORD;
    BEGIN
      LOOP
        FOR r IN SELECT id FROM tabelle WHERE uniquefelder LIMIT 1 FOR UPDATE LOOP
          RAISE NOTICE 'update';
          RAISE NOTICE 'row %', r.id;
          UPDATE tabelle SET neuewerte WHERE id = r.id AND "updated_at" < datum;
          --Diese Variante ist extrem langsam
          --UPDATE tabelle SET neuewerte WHERE uniquefelder AND "updated_at" < datum;
          RETURN;
          RAISE NOTICE 'update done';
        END LOOP;
        BEGIN
          INSERT INTO tabelle (felder) VALUES (values);
          RAISE NOTICE 'insert';
          RETURN;
        EXCEPTION WHEN unique_violation THEN
          RAISE NOTICE 'do it again';
        END;
      END LOOP;
    END;
    $$
    LANGUAGE plpgsql;
    aber aus interesse würde mich das schon interessieren, weshalb das update über die uniquefelde (sind 4 ints cols) innerhalb von einer funktion so sau lahm ist.

Seite 1 von 2 12 LetzteLetzte

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