Zitat von Marcus Obst marcus.obst@etit.tu-chemnitz.de:
On 09.05.2011 09:21, andreas@a-kretschmer.de wrote:
Die Datenbank läuft auf einem Windows-Server in der 32-Bit Version.
*GNA*. Wäre ein Wechsel zu einem OS denkbar?
Erstmal nicht :)
Wie sieht die postgresql.conf aus? Habt Ihr die so belassen, oder aber verändert?
Ist Standard, so wie sie bei Postgres 9.0 ausgeliefert wird.
Aua. Diese Config ist so spartanisch, daß man dann mit Deinen Anforderungen nicht zurecht kommen KANN.
IIRC ist z.B. als Default shared_buffers auf 24 MB gesetzt, das ist arg wenig. Je nach Hardware des Servers und anderen Bedingungen (dedizierter Server?) ist da einiges anzupassen.
- Ganz blauäugig dachte ich mir, dass man um das INSERT der 500.000
Datensätze, die ja alle logisch zu einem Messdatensatz gehören, mit einer Transaktion klammern kann. Wenn ich das mache, bekomme ich nach ca. 5GB importierten Daten eine Exception, die mir mitteilt, dass auf Serverseite irgendwelcher Speicher alle wäre?
Wie lautet die Meldung *genau*? An und für sich ist Deine Idee richtig. Aber wenn Du das in der PG-Default-Congfig machst, würde mich dies als Resultat nicht wirklich wundern.
Ich hab hier mal rauskopiert was ich in der Exception finden konnte:
{Error: 53200: Speicher aufgebraucht} ".\src\backend\utils\mmgr\aset.c" "Fehler bei Anfrage mit Grö�e 8388608." Line Number: 589 ProcedureName "AllocSetAlloc"
Wenn ich weniger Daten importiere gibt es keine Exception. Dafür bekomme ich beim finalen Commit der Transaktion ein Timeout.
- Das löschen von Messdaten (wider 500.000 Zeilen) mit einer Query ala
DELTE FROM measurements WHERE session_id = 34
dauert ewig und kommt meist Client-seitig mit einem Timeout zurück.
Was sagt ein "EXPLAIN ANALYSE SELECT * FROM measurements WHER ID = 34;" ?
explain analyse select * from measurements where session_id = 77; QUERY PLAN
Seq Scan on measurements (cost=0.00..17308.40 rows=153072 width=762) (actual time=0.043..174.420 rows=158699 loops=1) Filter: (session_id = 77) Total runtime: 179.649 ms (3 rows)
Wieviel Zeilen hat die Tabelle insgesamt? Möglicherweise fehlt ein Index, aber dazu müßte wissen, wieviel Zeilen in der Tabelle sind.
Ein anschließendes
delete from measurements where session_id = 77;
dauert wie schon beschrieben ewig.
Hier sind weitere Parameter zu prüfen/anzupassen. Z.B. Anzahl der WAL-Files.
Anpassen solltest Du:
- shared_buffers auf etwa 25% des vorhandenen RAM (bei dediziertem Server) - effective_cache_size korrekt setzen - work_mem von aktuell 1MB auf vielleicht erst mal 4, aber das hängt von vielen Dingen ab - wal_buffers erhöhen - checkpoint_segments (aktuell IIRC 3 auf vielleicht 30)
Das mal als Anfang.
Ich kann Dir auch das Hosting hier bei uns anbieten ;-)
Andreas