Zitat von Marcus Obst marcus.obst@etit.tu-chemnitz.de:
On 09.05.2011 12:22, andreas@a-kretschmer.de wrote:
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.
Hab ich geändert, hat etwas gebracht (schafft jetzt 10 MB/s). Aber ist jetzt auch nicht so der Knaller.
Wieviel Zeilen hat die Tabelle insgesamt? Möglicherweise fehlt ein Index, aber dazu müßte wissen, wieviel Zeilen in der Tabelle sind.
Im Moment ca. 300.000 (frisch eingefügt). Die will ich unmittelbar danach mittels
DELETE FROM measurements;
alle einfach wieder löschen -> dauert....
Wenn Du ALLES aus einer Tabelle löschen willst: TRUNCATE
- 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)
Danke. Größter Kritikpunkt ist eigentlich nach wie vor, dass es hier nicht möglich ist die 20GB zw. 300.000 INSERT Statements in einen Transaktionsblock zu stecken ohne das ich eine Out-Of-Memory Exception bekomme.
Mir ist nicht ganz klar, wo die her kommt. Stand diese Meldung im Log von PG An und für sich kann PG sowas.
Ach ja: wenn Du kannst, verwende COPY anstelle INSERT, wenn es Bulk-Inserts sind. Ist um Größenordnungen schneller.
Ich kann Dir auch das Hosting hier bei uns anbieten ;-)
Hm, mittelfristig soll der Datenbankserver im Messauto mitfahren, ich denke das wird schwierig :)
Das ist kein Ausschluß ;-)
Einner unserer Kunden hat z.B. $GANZ_VIELE GPS-Boxen im Einsatz, die ständig ihre Position melden. Da geht schon ganz schön die Post ab ...