Konfigurationsparameter für OLTP Anfragen

Hallo,

an welchen Konfigurationsparametern kann ich für eine Optimierung hinsichtlich OLTP Anfragen drehen?

Danke und liebe Grüße
Marcus

Das hängt mal sehr stark von deiner Anwendung ab …

Es geht um normale INSERTS, soviel wie möglich in kürzester Zeit.

Die Parameter:

checkpoint_segments = 16MB
checkpoint_timeout = 5min
commit_delay = 100

habe ich so angepasst. Was geht noch?

mfg
Marcus

Viel, sehr viel. Faktor 100 oder so schneller geht noch.
Aber nicht mit INSERT.

Dafür muss man dann allerdings die Anwendung drauf vorbereiten.

Du könntest Tablespaces nutzen, um Tabellen, Indexe und Logfiles auf getrennte Spindeln zu legen. Das lohnt sich. (wenn es reale Platten an untersch. Controllern sind).

Du könntest auch, falls möglich, von INSERT auf COPY wechseln.

Und wenn es Inserts in Tabellen sind, die via RI zusammenhängen, und da dann auch die erzeugten IDs mit currval() abzufragen sind oder solche Dinge, dann writeable CTE nutzen (8.5devel) g

Andreas

Du meinst mit Copy, oder?

Ich glaube ich Spinne. Ich habe den Parameter checkpoint_segements verändert und noch startet der Server nicht mehr. Selbst wenn ich den wieder auf 16MB stelle oder 3MB oder was auch immer. Wenn ich den Parameter auskommentiere startet der Server. Was ist das denn? Bug? Fehlbedienung?

mfg
Marcus

Was steht im Logfile, warum der nicht starten will?
Wie genau steht die Zeile in der Konfigurationsdatei? Bitte hier pasten.

checkpoint_segments = 16MB

So schaut die Logfile aus:

2009-11-19 16:06:18 CETLOG:  Datenbanksystem wurde am 2009-11-19 16:01:07 CET heruntergefahren
2009-11-19 16:06:18 CETLOG:  Datenbanksystem ist bereit um Verbindungen anzunehmen
2009-11-19 16:06:18 CETLOG:  Autovacuum-Launcher startet
2009-11-19 16:06:18 CETLOG:  Verbindung empfangen: Host=bh5pmp1h.de.bosch.com port=1550
2009-11-19 16:08:28 CETLOG:  schnelles Herunterfahren verlangt
2009-11-19 16:08:28 CETLOG:  etwaige aktive Transaktionen werden abgebrochen
2009-11-19 16:08:28 CETLOG:  Autovacuum-Launcher fährt herunter
2009-11-19 16:08:28 CETLOG:  fahre herunter
2009-11-19 16:08:28 CETLOG:  checkpoint starting: shutdown immediate
2009-11-19 16:08:28 CETLOG:  checkpoint complete: wrote 620 buffers (0.6%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=0.016 s, sync=0.031 s, total=0.047 s
2009-11-19 16:08:28 CETLOG:  Datenbanksystem ist heruntergefahren

Und das ist die Fehlermeldung von Windows:

The PostgreSQL Server 8.4 service on Local Computer started and then stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts service.

Nun, da steht keine Fehlermeldung, warum PG nicht startet. Die Meldung von Windows ist irgendwie - nichtssagend.

Also, wenn du das auskommentierst, funktioniert es.
Schön, dann zeig doch mal, was genau du auskommentiert hast.

#checkpoint_segements = 16MB

Ich habe hier was gefunden:
Pgsql 8.4 on Vista starts and stops automatically. - PostgreSQL Database answers

Löst aber mein Problem auch nicht.

mfg
Marcus

16, nicht 16MB!

Ich muss jetzt leider los. Morgen ist Schließtag, so dass ich am Montag das Thema gerne wieder aufnehmen würde.

Schönes Weekend.

mfg
Marcus

Du willst die Anzahl 16 einstellen, nicht 16MB :wink:

Gott, wie blöd kann man denn sein…ich Depp.

Danke, jetzt kann ich wenigstens beruhigt meinen Arbeitsplatz verlassen.

mfg
Marcus

Hey, und wohin schicke ich jetzt die Rechnung? :wink:

  1. genau ueberlegen welche indexe du auf dieser table brauchst - weniger sind besser
  2. inserts zusammenfasst
    2.1 vielleicht sind mehrere zeilen zusammenfassbar - das reduziert den overhead das requests
    insert into …
    values
    (f1, f2, f3),
    (f1, f2, f3),

    (f1, f2, f3);
    2.2. möglichst autocommit ausschalten - explizite transaktionen verwenden …

Momentan befinden sich alle Daten auf einer Platte ohne Tablespaces. Nützt es denoch was welche zu erstellen?

Kannst du das näher beschreiben, was du damit genau meinst?


Das habe ich alles berücksichtigt und auch autocommit wollte ich ausschalten über explizite Transaktion. Ist allerdings eine PL/pqSQL Funktion, über die die Inserts in die DB kommen und da sind keine expliziten Transaktionen erlaubt, so wie ich das verstanden habe.

Danke!

mfg
Marcus

uarg noch langsamer geht es nicht … mit der Lösung werdet ihr keine gute Performance erreichen, sorry.

Im Ausgangssystem wird es aber ebenfalls so gemacht, so dass damit ja nur eine Chancengleichheit herrscht.

mfg
Marcus

das hat er doch bereits festgestellt …

deswegen fragt er Dich, warum er nun was tun soll …

@drooper
mehrere partitionen helfen um schreib/lese zugriffe zu parallelisieren … das einfachst ist, indexe und daten (evtl wal) auf verschiedene patitionen (verschiedene platten) zu legen. ein weiterer schritt wäre, selbst die daten zu stückeln/partitionieren und auf mehreren platten (tablespaces) zu verteilen - das erfordert dann aber etwas mehr planung

auch solltest du schauen, dass die clients evtl die db nicht zeile fuer zeile mit inserts fuettern … sondern bei einem insert gleich einen block schreiben … weil requests an die db i.d.R. eben mehrere millisekunden teuer sind.