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.
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.Code:LOG: checkpoints are occurring too frequently (19 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments".
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:
Für Tipps wäre ich dankbarCode:shared_buffers = 1024MB temp_buffers = 512MB work_mem = 256MB maintenance_work_mem = 256MB checkpoint_segments = 6
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.
Das bekomm ich auch noch wobei ich den Import schieben kann oder?Code:ERROR: canceling autovacuum task CONTEXT: automatic vacuum of table "qmonitor_development.public.basic_datas"
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
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
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
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
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.Wenn dieser Insert einmalig ist, würde ich die Warnungen schlicht ignorieren.
Mit den neuen Einstellungen brauchen die ersten 10.000 Datensätze superlange. Mist...
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
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)
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 +.
Ich habe es wohl gefunden das Problem. Ab 430.000 sind die Zeilen alle Updates. Updates werden in der selbstgebauten Funktion wie folge gebaut:
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.Code:UPDATE table SET neuewerte WHERE spaltenaus demuniqueconstrain AND updated_at < x
Da ich aber in Zukunft mehr Updates als Insert haben werde, wollte ich sowieso die Funktion umbauen das zuerst ein select/update gemacht wird:
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.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;
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen