Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15

Thema: Performance - Optimierung für SELECT und DELETE - Abfragen

  1. #1
    kerstin ist offline Neuer Benutzer
    Registriert seit
    11.06.2007
    Beiträge
    7

    Standard 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 (TM) 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

  2. #2
    Avatar von Xandrian
    Xandrian ist offline Administrator
    Registriert seit
    23.11.2005
    Ort
    Bayreuth, Bayern, Germany, 106332342737801, Bayreuth, Germany
    Beiträge
    1.495

    Standard

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

    cu tb.
    pg-forum.de unterstützen? Meine Wunschliste


  3. #3
    kerstin ist offline Neuer Benutzer
    Registriert seit
    11.06.2007
    Beiträge
    7

    Standard

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

  4. #4
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von kerstin Beitrag anzeigen
    ja sind sinnvoll angelegt, sie dürften die Performance nicht beeinträchtigen
    Weniger Prosa, mehr Fakten. EXPLAIN ANALYSE.

    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  5. #5
    kerstin ist offline Neuer Benutzer
    Registriert seit
    11.06.2007
    Beiträge
    7

    Standard

    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

  6. #6
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von kerstin Beitrag anzeigen
    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

    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  7. #7
    kerstin ist offline Neuer Benutzer
    Registriert seit
    11.06.2007
    Beiträge
    7

    Standard

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

  8. #8
    Avatar von Xandrian
    Xandrian ist offline Administrator
    Registriert seit
    23.11.2005
    Ort
    Bayreuth, Bayern, Germany, 106332342737801, Bayreuth, Germany
    Beiträge
    1.495

    Standard

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

    cu tb.
    pg-forum.de unterstützen? Meine Wunschliste


  9. #9
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.055

    Standard

    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.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  10. #10
    fristo ist offline Super-Moderator
    Registriert seit
    08.12.2005
    Ort
    Raum Frankfurt/Main
    Beiträge
    668

    Standard

    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

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Unregelmäßigkeit bei Select-Abfragen
    Von Lara im Forum Konfiguration
    Antworten: 16
    Letzter Beitrag: 16.02.2011, 11:41
  2. SELECT eine Variable doppelt abfragen
    Von renzge im Forum SQL
    Antworten: 4
    Letzter Beitrag: 23.07.2009, 13:30
  3. Antworten: 6
    Letzter Beitrag: 15.06.2009, 10:59
  4. Performance bei varchar-Abfragen
    Von dantro32 im Forum Allgemeines
    Antworten: 1
    Letzter Beitrag: 21.07.2007, 10:35
  5. Performance-Optimierung nach Update 8.1.8 -> 8.2.4
    Von hplaschk im Forum Konfiguration
    Antworten: 1
    Letzter Beitrag: 07.05.2007, 15:15

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum