Gelöst: performance probleme beim inserten

Ichhabe doch jetzt mehrere Test gemacht die doch Beweisen das die DB ausbremst und nicht meine Funktionen.

Ich weis nicht was ich noch weglassen soll zum beweisen.
Deine Testtabelle stimmt aber auch nicht mit meiner überein.
Hier nochmal das Szenario meines letzten Test

CREATE TABLE test(
  tan character varying(9) NOT NULL,
  CONSTRAINT tan_pkey PRIMARY KEY (tan)
)

Baue ein SQL mit 1.000.000 VALUES mit 9 Steligen TANs. Der Bau des SQL dauert mit der Generierung codes in Ruby ca 6 Sekunden. Haba danach nur einen einfachen String.

Erstes Lauf:
0 Zeilen in der DB
Sende das SQL an die DB. Dauer 122 Sekunden

Zweiter Lauf
1.000.000 Zeilen in der DB.
Sende erneut ein SQL mit 1Mio VALUES (wieder 6 Sekunden für die Generierung des STRING). Dauer 811 Sekunden.

Wie gesagt ich habe hier keine eigene Funktion mehr die das ganze ausbremst. Der String liegt ja immer nach 6 Sekunden vor.


Der andere Test welcher 100.000er Häpchen per PL erstellt habe ich ja auch die eigenen Funktionen mal raus genommen. Sobald ich nur Zahlen habe für die TAN geht’s viel schneller, habe aber dafür halt keine TAN mit gespeichert. Aber auch das wird immer langsamer wie mehr sich die DB füllt, da ja mehr Verglichen werden muss.


Nächster Test wird sein,

Tabelle: PK serial, varchar 9 ohne UniqueConstraint
Tabelle: PK serial, varchar 9 mit UniqueConstraint

Wenns beim 2 langsam wird hoffe ich hab ich einen Beweis das des diese UNIQUE abfrage der DB ist die hier bremst. Langsam gehen mir die Ideen aus um das zu Beweisen.

ein wenig aufwand ist der PK schon - aber nicht so extrem wie du es vermutest …

bei mir dauern die inserts + trigger + pk nun ca 10 sek. fuer 100k …

auf einem nicht so sehr performenden 2 kern system

seltsam was da bei dir laeuft - außerdem wird ein kern bei der aktion zu 100% ausgelastet. bei mir idlet nix rum …

koennte es sein, dass du mit deinem betriebssystem ein problem hast? mit dem IO? dass da irgendwelche fremden plattenzugriffe dazwischen fuchteln? oder irgendwas defekt … hier kann man nur rätselraten - es ist unwahrscheinlich, dass sich das auf deine trigger oder ddl zurueckfuehren laesst.

außerdem finde ich verdaechtig, dass dein ruby 6 sek ?!?!? zum erzeugen eines SQL statement braucht?

ahh ja …

dynamisches sql … irgendwas war da …

weil PREPARE und EXECUTE in der shell ja nicht auch so in plpqsql existieren …

bringt dieses dynamische prepare vorteile gegenueber den statischen statements in funkionen? also performance …

Also ich habe jetzt auf dem Server nun das o.g. Szenario getestet. Sobald der UniqueConstain auf dem varchar 9 liegt wird es saulahm. Nehme ich den runter, brauche ich immer nur 3,5 Sek. BEi 10Mio braucht er 36 Sekunden.

Jetzt stellt sich die Frage wie bekomme ich die DB dahingehend optimiert das diese varchar Felder unique bleiben und dennoch performant.

Ich glaube nicht das es identisch ist it meines. Ich meine Vermutung nun auf 4 verschiedenen Server und auf meinem MacBook probiert und über das gleiche verhalten. Ich vermute eher das die default Konfig zu wenig Speicher für den Index bereit stellt.

Alles Server laufen immer in default. Anpassungen kann ich aber vornehmen lassen. Versuche nun shared_buffers und effective_cache_size anzuheben.

Welche Option ist den verantwortlich das der KEY im RAM gehalten wird?

habe die 2 werte hochgesetzt und siehe da. SCHNELL!!!

Jede Zeile stellt ein 1Mio Inserts in Sekunden dar!

4.28561091423035
4.75989699363708
5.24605703353882
5.0985369682312
5.67897295951843
6.19736194610596

Das sind doch Traumwerte !!!
Danke für eure Bemühung!
Werde jetzt überlegen meine Zeilen doch nicht mit plsql zu machen sondern als BundleInserts da dies ja schnell genug ist :smiley:

Welche zwei Werte genau?
Und müssen das so viele ! sein?

Wie gesagt, nur wenn das wirklich teure und mehrfach wiederholte Anfragen sind.

Da pl/pgSQL sowohl für das PREPARE wie für das EXECUTE jeweils ein SQL Statement ausführt, muss man mindestens so viel gewinnen, dass sich hier ein Unterschied bemerkbar macht. Bei einfachen INSERTs ist das allerdings wohl nicht der Fall.

shared_buffers 2GB
effective_cache_size 4GB

Und SHM* Werte im Kernel entsprechend angepasst.

Ich dachte, das war schon angepasst? Stand imho zumindest in deinem Eingangsposting.

Hab ich ja auch aber immer noch viel zu wenig. Habe mir deine Präsentation angeschaut und nochwas doku gelesen und habe das dann entsprechend nochmal angepasst.

Bin halt noch nicht so fit mit PGSQL. Habe früher nur mit MySQL gearbeitet. Aber die DB kostzt mich immer mehr an :smiley: Ist halt ne DB für ein Gästebuch oder so :smiley: Aber ich lerne schnell…

Dennoch bedanke ich mich bei euch für die viele Mühe.
Aber jeder fängt mal klein an ^^

Nun, bin schon froh, dass die Datenbank selbst nicht Schuld ist :wink:
Das hätte ich aber auch nicht erwartet.

Dann viel Spaß mit der Datenbank - und wirf mal einen Blick in meine Signatur :wink:

Also das es so extrem am Buffer hängt ich auch nicht. Aber scheinbar schafft er es nicht den Index im RAM zu halten. Ich bin auch froh ich hab schon sonst was gedacht. Ich hatte das Problem schonmal mit eMailadressen die Unique sein sollten. Allerdings hatte ich da keine Zugriff auf die DB.

Naja und wieder ewtwas schlauer…

Kann man Threads nicht als gelößt markieren ?? naja dann eben nicht :smiley:

Ich habe den Titel des Threads mal umbenannt.