Performance - Optimierung für SELECT und DELETE - Abfragen

Hallo,
auf einem Windows- Server hab ich Postgres ( Version 8.2.4 ) installiert. Nun sind vor allem die DELETE und große SELECT- Abfragen sehr langsam.

Server :
Windows 2003 Server ( Standard Edition ) SP 1
Intel® Xeon ™ CPU 2,80 GHz
1 GB Ram

Einige Parameter habe ich schon geändert, sodass die Performance schon ein wenig besser wurde, aber was kann ich noch tun um die Abfragezeiten zu verkürzen?

postgresql.conf :

listen_addresses = ‘*’
max_connections = 100
shared_buffers = 250MB
work_mem =5MB
max_fsm_pages = 28000
fsync = on
wal_buffers = 32
checkpoint_segments = 16
effective_cache_size = 512MB

Alle anderen Einstellungen sind unverändert.

Danke im vorraus für eure Hilfe

Hm, blöde Frage aber sinnvolle Indexe hast du auf die entsprechenden Tabellen gelegt?

cu tb.

ja sind sinnvoll angelegt, sie dürften die Performance nicht beeinträchtigen

Weniger Prosa, mehr Fakten. EXPLAIN ANALYSE.

Andreas

die abfragen waren nur als Beispiele zu verstehen, das heißt auch UPDATE und INSERT waren sehr langsam, ich denke deshalb das es nicht an den Indexen liegt. jedoch hier ein Beispiel:
explain analyze select * from tstrasse order by strasse

Sort (cost=365527.62…368533.54 rows=1202369 width=150) (actual time=29051.756…33477.808 rows=1202369 loops=1)
Sort Key: strasse
-> Seq Scan on tstrasse (cost=0.00…55054.69 rows=1202369 width=150) (actual time=0.386…7721.124 rows=1202369 loops=1)
Total runtime: 40865.734 ms

nach Indexerstellung:
Index Scan using strasse_i on tstrasse (cost=0.00…235656.37 rows=1204309 width=150) (actual time=659.082…20190.038 rows=1202369 loops=1)
Total runtime: 34612.155 ms

vielleicht hilft das weiter

Hier kann er den Index zum Sortieren nutzen. Mehr nicht. Du willst alle Zeilen, Du bekommst alle Zeilen. Die Zeit von 34 Sekunden für faktisch ein select * ohne WHERE, welches dann 1,2 Millionen Zeilen liefert, liegt im Bereich dessen, was man da erwarten kann. Immerhin hat er bei width=150 mehr als 150 MByte von der Platte zu lesen, zu sortieren und anzuzeigen. Und das auch noch unter Wintendows, vermutlich in einer GUI.


Andreas

kann ich deshalb vermuten , das die Performance nicht an den Einstellungen in der postgresql.conf liegt ?

Ja. Gibt einfach physikalische Grenzen bei Hardware… Wie akretschmar schon gesagt hat dauert es sinfach, bis 1,2 Millionenen Zeilen sortiert sind…

cu tb.

Nicht nur sortiert sind, sie müssen vor allen Dingen auch erst einmal übertragen werden. Die Daten müssen von der Platte gelesen, in den Ram übertragen, dann übers Netzwerk (wenn vielleicht auch nur localhost) zum Client geschickt und dort noch mal verarbeitet werden.

Der Flaschenhals hier ist die I/O Leistung der beteiligten Rechner, nicht die Datenbank.

Hallo Kerstin,

defragmentiere mal die Harddisk auf dem die PostgreSQL Dateien sind. Vorher sollte ein manuelles VACUUM FULL durchgeführt werden. Es gab hier mal einen Fall, wo diese Maßnahmen unter Windows eine extreme Performenssteigerung erbracht haben.



mfg

fristo

Dankeschön für eine Hinweise.
Das Problem bei meiner Datenbank scheint wohl du sein das die “block change rate” sehr hoch ist. Was bedeutet das genau und was kann ich dagegen tun.

Ich hoffe ihr könnt mir weiterhelfen.

Kerstin

Wie kommst Du auf diesen Begriff?

Andreas

Ich hatte Ouest Spotlight on Oracle ausprobiert und als “Alarm” kam :
Flow of database block change rate
lock waits are 45, 3 % of non-idle wait time

Grüße Kerstin

Dir ist aber schon klar, daß sich ORACLE anders schreibt als PostgreSQL und daß auch die in den jeweiligen Produkten einkompilierten Fehlermeldungen nix miteinander zu tun haben?

Andreas, frag ja nur…

oh, sorry , du hast recht. War nen Fehler von meiner Seite, man sollte halt erstmal schaun zu welcher DB man die erste Frage gestellt hat *g. Ist nur so das ich mit beiden arbeite und da bin ich wohl in den falschen Beitrag gekomm. Nix für ungut :wink:

Trotzdem danke