Zitat von Marcus Obst <[email protected]>:
On 09.05.2011 12:22, [email protected] 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 ...
_______________________________________________
Lug-dd maillist - [email protected]
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
