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

Thema: Auto Vacuum funktioniert nicht richtig

  1. #1
    JSpatz ist offline Benutzer
    Registriert seit
    19.05.2006
    Beiträge
    58

    Standard Auto Vacuum funktioniert nicht richtig

    Hallo zusammen,

    seit längerem haben wir auf einem OpenSuse 10.2 eine PostgreSQL 8.2.4 im Testeinsatz und haben folgende Beobachtung gemacht:
    In dieser Datenbank gibt es eine Tabelle mit ca. 40.000 Einträgen (Größe, ca. 5MB) in der alle 15 Minuten über eine Programm ein Update mit den neuesten statistischen Werten gemacht wird. Es werden praktisch keine Inserts gemacht, sondern fast nur Updates.

    Wir haben Autovacuum eingestellt und folgende Parameter in der config-Datei:
    Code:
    #---------------------------------------------------------------------------
    # AUTOVACUUM PARAMETERS
    #---------------------------------------------------------------------------
    
    autovacuum = on                # enable autovacuum subprocess?
                        # 'on' requires stats_start_collector
                        # and stats_row_level to also be on
    #autovacuum_naptime = 1min        # time between autovacuum runs
    #autovacuum_vacuum_threshold = 500    # min # of tuple updates before
                        # vacuum
    #autovacuum_analyze_threshold = 250    # min # of tuple updates before 
                        # analyze
    #autovacuum_vacuum_scale_factor = 0.2    # fraction of rel size before 
                        # vacuum
    #autovacuum_analyze_scale_factor = 0.1    # fraction of rel size before 
                        # analyze
    #autovacuum_freeze_max_age = 200000000    # maximum XID age before forced vacuum
                        # (change requires restart)
    #autovacuum_vacuum_cost_delay = -1    # default vacuum cost delay for 
                        # autovacuum, -1 means use 
                        # vacuum_cost_delay
    #autovacuum_vacuum_cost_limit = -1    # default vacuum cost limit for 
                        # autovacuum, -1 means use
                        # vacuum_cost_limit
    Nach einigen Tagen haben wir aber festgestellt, dass die Datei der Tabelle 450 MB hatte und mit jedem Update 5 MB größer wurde.
    Um zu sehen ob Vacuum überhaupt geht haben wir dann ein Vacuum-Full gemacht und dann hatte die Tabelle nur noch 5 MB. Einige Updates später hatte sie wieder 25 MB. Was mich irritiert, da (wie aus den Paramtern zu ersehen ist) das Autovacuum jede Minute anspringen sollte und damit die Tabelle gar nicht so groß anwachsen sollte.

    Jetzt die Fragen:
    - Habe wir generell in der Konfig irgendetwas falsch eingestellt ?
    - Kann es sein, dass ein Prozess, das Autovacuum stört oder unterbricht ?
    - Kann ich irgendwo, außer in der Tabelle pg_stat_all_tables sehen, ob das Autovacuum angesprungen ist ?
    - ist die Zeit von einer Minute für das Autovacuum zu kurz ? Sollte man hier evtl mehr einstellen ? (Damit sich der Prozess nicht selbst blockiert, wenn er länger als 1 Minuten benötigen sollte ?)

    Kann uns jemand sonst noch irgendwelche Tipps zu autovacuum geben ?

    Vielen Dank im Vorraus für Antworten

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

    Standard

    Zitat Zitat von JSpatz Beitrag anzeigen
    Hallo zusammen,

    seit längerem haben wir auf einem OpenSuse 10.2 eine PostgreSQL 8.2.4 im Testeinsatz und haben folgende Beobachtung gemacht:

    Kann uns jemand sonst noch irgendwelche Tipps zu autovacuum geben ?

    Vielen Dank im Vorraus für Antworten
    Setze mal maintenance_work_mem höher, ich rate mal wild, daß der Wert zu gering ist.

    Ansonsten mal ein 'vacuum analyse verbose' auf diese spezielle Tabelle und schauen, was das sagt.

    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

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

    Standard

    Als erstes: das # vor dem Parameter sollte verschwinden, sonst ist der Parameter nicht gesetzt ;-)

    Eine 'naptime' von einer Minute bedeutet, das autovacuum eine Minute wartet, bevor die nächste Datenbank bearbeitet wird. Bei jedem Vacuum Lauf wird immer genau eine Datenbank berücksichtigt. Dieser Parameter ist dafür gedacht, das zwischen zwei VACUUM Läufen die Datenbank etwas "entspannen" zu lassen.

    Im Logfile sollte stehen, welche Tabellen bearbeitet wurden. Ist dort irgendetwas zu sehen?
    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

  4. #4
    JSpatz ist offline Benutzer
    Registriert seit
    19.05.2006
    Beiträge
    58

    Standard

    HI,

    im Logfile ist nichts zu finden, dass das Autovacuum lief.

    Hier die Einstellungen zum Thema Speicher usw:
    Code:
    #---------------------------------------------------------------------------
    # RESOURCE USAGE (except WAL)
    #---------------------------------------------------------------------------
    
    # - Memory -
    
    shared_buffers = 256MB            # min 128kB or max_connections*16kB
                        # (change requires restart)
    #temp_buffers = 8MB            # min 800kB
    #max_prepared_transactions = 5        # can be 0 or more
                        # (change requires restart)
    # Note: increasing max_prepared_transactions costs ~600 bytes of shared memory
    # per transaction slot, plus lock space (see max_locks_per_transaction).
    work_mem = 1MB                # min 64kB
    #maintenance_work_mem = 16MB        # min 1MB
    #max_stack_depth = 2MB            # min 100kB
    
    # - Free Space Map -
    
    max_fsm_pages = 204800        # min max_fsm_relations*16, 6 bytes each
                        # (change requires restart)
    #max_fsm_relations = 1000        # min 100, ~70 bytes each
                        # (change requires restart)
    
    # - Kernel Resource Usage -
    
    #max_files_per_process = 1000        # min 25
                        # (change requires restart)
    #shared_preload_libraries = ''        # (change requires restart)
    
    # - Cost-Based Vacuum Delay -
    
    #vacuum_cost_delay = 0            # 0-1000 milliseconds
    #vacuum_cost_page_hit = 1        # 0-10000 credits
    #vacuum_cost_page_miss = 10        # 0-10000 credits
    #vacuum_cost_page_dirty = 20        # 0-10000 credits
    #vacuum_cost_limit = 200        # 0-10000 credits
    
    # - Background writer -
    
    #bgwriter_delay = 200ms            # 10-10000ms between rounds
    #bgwriter_lru_percent = 1.0        # 0-100% of LRU buffers scanned/round
    #bgwriter_lru_maxpages = 5        # 0-1000 buffers max written/round
    #bgwriter_all_percent = 0.333        # 0-100% of all buffers scanned/round
    #bgwriter_all_maxpages = 5        # 0-1000 buffers max written/round
    Noch mal zum besseren Verständnis:
    Wenn ein Vacuum-Lauf immer nur eine Datenbank bearbeitet, wie ist dann die Reihenfolge, wie die Datenbank bearbeitet werden? Geht das immer Reihum (Round Robin) oder ist das noch von anderen Faktoren wie Last etc. abhängig.

    Vielen Dank

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

    Standard

    Zitat Zitat von JSpatz Beitrag anzeigen
    im Logfile ist nichts zu finden, dass das Autovacuum lief.
    Das müsste in etwa so aussehen:
    LOG: autovacuum: processing database "test"
    Noch mal zum besseren Verständnis:
    Wenn ein Vacuum-Lauf immer nur eine Datenbank bearbeitet, wie ist dann die Reihenfolge, wie die Datenbank bearbeitet werden? Geht das immer Reihum (Round Robin) oder ist das noch von anderen Faktoren wie Last etc. abhängig.
    Round Robin. Wenn in einer Datenbank nichts los ist, ist das Autovacuum halt schneller fertig. Dann wird $naptime gewartet, danach kommt die nächste Datenbank dran.
    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

  6. #6
    JSpatz ist offline Benutzer
    Registriert seit
    19.05.2006
    Beiträge
    58

    Standard

    Hallo,

    im Logfile ist leider nichts zu finden. Wir haben aber folgende Entdeckung gemacht:
    Das Programm, das die eine Tabelle ständig updated hat immer ein exclusive Lock auf der Datenbank. (Sieht man im Statusfenster im PG-Admin) Kann es sein, dass damit das Auto-Vacuum behindert wird, bzw. gar dieses nicht erst anläuft ?


    Danke noch mal für die Hilfe

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

    Standard

    Zitat Zitat von JSpatz Beitrag anzeigen
    Hallo,

    im Logfile ist leider nichts zu finden. Wir haben aber folgende Entdeckung gemacht:
    Das Programm, das die eine Tabelle ständig updated hat immer ein exclusive Lock auf der Datenbank. (Sieht man im Statusfenster im PG-Admin) Kann es sein, dass damit das Auto-Vacuum behindert wird, bzw. gar dieses nicht erst anläuft ?


    Danke noch mal für die Hilfe
    Ja, das dürfte die Ursache sein.

    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

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

    Standard

    Zitat Zitat von JSpatz Beitrag anzeigen
    Das Programm, das die eine Tabelle ständig updated hat immer ein exclusive Lock auf der Datenbank. (Sieht man im Statusfenster im PG-Admin) Kann es sein, dass damit das Auto-Vacuum behindert wird, bzw. gar dieses nicht erst anläuft ?
    Anlaufen wird das VACUUM schon ... nur kann es diese Tabelle nicht bearbeiten.

    Gegenfrage: was bringt mir eine Datenbank, wenn die Tabelle ständig gelockt ist? Irgendwie ist das Verhalten der Applikation nicht ganz logisch. Noch dazu schreibst du in deinem ersten Beitrag, das es alle 15 Minuten Einträge gibt. Dazwischen muss es doch keinen exklusiven Lock geben, oder?
    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

  9. #9
    JSpatz ist offline Benutzer
    Registriert seit
    19.05.2006
    Beiträge
    58

    Standard

    Hi zusammen,

    Sorry, ich habe mich vermutlich zu ungenau ausgedrückt:

    Die Tabelle wird nicht absichtlich exclusiv gelockt. (wir entwicklen hier mit Gupta Team Developer, falls den irgendjemand kennt.). Der Lock kam dadurch zustande, dass im Login-Dialog ein Testconnect gemacht und dieser beim Erfolg gleich wieder disconnected wurde, allerdings ohne ein Commit zu machen. (Habe ich inzwischen geändert, jetzt wird vor jedem Disconnect automatisch ein Commit gemacht)
    Es wurde wurde also keinerlei Aktion mit dieser Connection durchgeführt, noch viel weniger irgendetwas mit der angesprochenen Tabelle.
    Alle anderen Programme konnten problemlos arbeiten und auch auf diese Tabelle zugreifen und ändern, wie gesagt nur der Statusdialog im PG-Admin hat den Lock noch angzeigt. Alles andere lief normal.

    Gruss Jürgen

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

    Standard

    Tabelle exklusiv gelockt, aber andere Programme konnten damit arbeiten?

    I'm lost ...
    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

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. copy funktioniert nicht
    Von karl_ha im Forum SQL
    Antworten: 3
    Letzter Beitrag: 28.07.2010, 12:18
  2. Problem INSERT INTO funktioniert nicht.
    Von 881362 im Forum SQL
    Antworten: 6
    Letzter Beitrag: 19.12.2008, 11:28
  3. PostgreSQL startet nicht richtig unter XP
    Von sepp im Forum Sonstige Installationsprobleme
    Antworten: 3
    Letzter Beitrag: 21.04.2008, 19:04
  4. finde schon wieder was nicht...(Insert mit auto antwort?)
    Von MyLittleBunny im Forum Allgemeines
    Antworten: 14
    Letzter Beitrag: 23.10.2007, 15:18
  5. Automatisches Backup und Auto Vacuum
    Von Similius im Forum Konfiguration
    Antworten: 10
    Letzter Beitrag: 21.09.2006, 15:56

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