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

Thema: Speicher aufgebraucht - Windows 2008 R2 - Postgres 8.4.6

  1. #1
    kbsolutions ist offline Neuer Benutzer
    Registriert seit
    15.08.2007
    Beiträge
    26

    Standard Speicher aufgebraucht - Windows 2008 R2 - Postgres 8.4.6

    Hallo Zusammen

    Folgendes Problem ist in unserem Postgres-Log zu finden:
    ************************************************** ***********
    TopMemoryContext: 95584 total in 8 blocks; 4824 free (11 chunks); 90760 used
    Operator class cache: 8192 total in 1 blocks; 3848 free (0 chunks); 4344 used
    TopTransactionContext: 24576 total in 2 blocks; 23960 free (15 chunks); 616 used
    TOAST to main relid map: 24576 total in 2 blocks; 9960 free (5 chunks); 14616 used
    AV worker: 24576 total in 2 blocks; 19984 free (9 chunks); 4592 used
    Autovacuum Portal: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
    Vacuum: 8192 total in 1 blocks; 8136 free (0 chunks); 56 used
    smgr relation table: 8192 total in 1 blocks; 2816 free (0 chunks); 5376 used
    TransactionAbortContext: 32768 total in 1 blocks; 32752 free (0 chunks); 16 used
    Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used
    PortalMemory: 0 total in 0 blocks; 0 free (0 chunks); 0 used
    Relcache by OID: 8192 total in 1 blocks; 3376 free (0 chunks); 4816 used
    CacheMemoryContext: 405552 total in 19 blocks; 34864 free (1 chunks); 370688 used
    pg_toast_75308101_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_index_indrelid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_opclass_am_name_nsp_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used
    pg_foreign_data_wrapper_name_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_enum_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_class_relname_nsp_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_foreign_server_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_statistic_relid_att_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_cast_source_target_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_language_name_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_authid_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_amop_fam_strat_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used
    pg_index_indexrelid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_ts_template_tmplname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_config_map_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used
    pg_opclass_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_foreign_data_wrapper_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_auth_members_member_role_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_dict_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_conversion_default_index: 1024 total in 1 blocks; 128 free (0 chunks); 896 used
    pg_operator_oprname_l_r_n_index: 1024 total in 1 blocks; 128 free (0 chunks); 896 used
    pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used
    pg_enum_typid_label_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_config_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_user_mapping_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_opfamily_am_name_nsp_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used
    pg_type_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_aggregate_fnoid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_constraint_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_parser_prsname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_config_cfgname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_parser_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_operator_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_namespace_nspname_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_ts_template_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_amop_opr_fam_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_dict_dictname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_auth_members_role_member_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_type_typname_nsp_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_opfamily_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_class_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_proc_proname_args_nsp_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used
    pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used
    pg_proc_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_language_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_namespace_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_database_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_amproc_fam_proc_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used
    pg_authid_rolname_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_foreign_server_name_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_attribute_relid_attnam_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_conversion_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_user_mapping_user_server_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_conversion_name_nsp_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    MdSmgr: 8192 total in 1 blocks; 7648 free (0 chunks); 544 used
    LOCALLOCK hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used
    Timezones: 79320 total in 2 blocks; 5968 free (0 chunks); 73352 used
    ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
    2011-02-18 16:33:46.262 CET [2068:1] @ FEHLER: Speicher aufgebraucht
    2011-02-18 16:33:46.262 CET [2068:2] @ DETAIL: Fehler bei Anfrage mit Größe 893716290.
    ************************************************** ***********

    Die DB läuft auf einem Windows 2008 R2 mit 24Gb Ram. Der Fehler scheint beim Autovacuum aufzutretten. Die DB Version ist 8.4.6.

    Die wichtigesten Parameter in der Config:

    #------------------------------------------------------------------------------
    # CONNECTIONS AND AUTHENTICATION
    #------------------------------------------------------------------------------
    max_connections = 500

    #------------------------------------------------------------------------------
    # RESOURCE USAGE (except WAL)
    #------------------------------------------------------------------------------
    shared_buffers = 256MB
    temp_buffers = 128MB
    work_mem = 256MB
    maintenance_work_mem = 1024MB
    vacuum_cost_delay = 100ms
    vacuum_cost_page_hit = 4
    vacuum_cost_limit = 150

    #------------------------------------------------------------------------------
    # WRITE AHEAD LOG
    #------------------------------------------------------------------------------
    wal_buffers = 128kB
    checkpoint_segments = 100
    checkpoint_timeout = 15min

    #------------------------------------------------------------------------------
    # AUTOVACUUM PARAMETERS
    #------------------------------------------------------------------------------
    autovacuum = on
    log_autovacuum_min_duration = -1
    autovacuum_max_workers = 3
    autovacuum_naptime = 5min
    autovacuum_vacuum_threshold = 600
    autovacuum_analyze_threshold = 300
    autovacuum_vacuum_scale_factor = 0.3
    autovacuum_analyze_scale_factor = 0.15
    autovacuum_vacuum_cost_delay = -1

    Keine Ahnung, was ich machen soll, damit dieser Fehler wieder verschwindet! Da es eine produktive DB ist, kann ich nicht gross "ausprobieren". Zu erwähnen ist auch noch, dass die DB trotzt dieser Meldung stabil und schnell läuft.

    Danke euch für nützlich Tips

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

    Standard

    Zitat Zitat von kbsolutions Beitrag anzeigen
    Hallo Zusammen

    Folgendes Problem ist in unserem Postgres-Log zu finden:
    ************************************************** ***********
    TopMemoryContext: 95584 total in 8 blocks; 4824 free (11 chunks); 90760 used
    Operator class cache: 8192 total in 1 blocks; 3848 free (0 chunks); 4344 used
    TopTransactionContext: 24576 total in 2 blocks; 23960 free (15 chunks); 616 used
    TOAST to main relid map: 24576 total in 2 blocks; 9960 free (5 chunks); 14616 used
    AV worker: 24576 total in 2 blocks; 19984 free (9 chunks); 4592 used
    Autovacuum Portal: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
    Vacuum: 8192 total in 1 blocks; 8136 free (0 chunks); 56 used
    smgr relation table: 8192 total in 1 blocks; 2816 free (0 chunks); 5376 used
    TransactionAbortContext: 32768 total in 1 blocks; 32752 free (0 chunks); 16 used
    Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used
    PortalMemory: 0 total in 0 blocks; 0 free (0 chunks); 0 used
    Relcache by OID: 8192 total in 1 blocks; 3376 free (0 chunks); 4816 used
    CacheMemoryContext: 405552 total in 19 blocks; 34864 free (1 chunks); 370688 used
    pg_toast_75308101_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_index_indrelid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_opclass_am_name_nsp_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used
    pg_foreign_data_wrapper_name_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_enum_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_class_relname_nsp_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_foreign_server_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_statistic_relid_att_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_cast_source_target_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_language_name_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_authid_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_amop_fam_strat_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used
    pg_index_indexrelid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_ts_template_tmplname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_config_map_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used
    pg_opclass_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_foreign_data_wrapper_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_auth_members_member_role_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_dict_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_conversion_default_index: 1024 total in 1 blocks; 128 free (0 chunks); 896 used
    pg_operator_oprname_l_r_n_index: 1024 total in 1 blocks; 128 free (0 chunks); 896 used
    pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used
    pg_enum_typid_label_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_config_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_user_mapping_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_opfamily_am_name_nsp_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used
    pg_type_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_aggregate_fnoid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_constraint_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_parser_prsname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_config_cfgname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_parser_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_operator_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_namespace_nspname_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_ts_template_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_amop_opr_fam_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_ts_dict_dictname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_auth_members_role_member_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_type_typname_nsp_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_opfamily_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_class_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_proc_proname_args_nsp_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used
    pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used
    pg_proc_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_language_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_namespace_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_database_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used
    pg_amproc_fam_proc_index: 1024 total in 1 blocks; 88 free (0 chunks); 936 used
    pg_authid_rolname_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_foreign_server_name_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_attribute_relid_attnam_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_conversion_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
    pg_user_mapping_user_server_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    pg_conversion_name_nsp_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used
    MdSmgr: 8192 total in 1 blocks; 7648 free (0 chunks); 544 used
    LOCALLOCK hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used
    Timezones: 79320 total in 2 blocks; 5968 free (0 chunks); 73352 used
    ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
    2011-02-18 16:33:46.262 CET [2068:1] @ FEHLER: Speicher aufgebraucht
    2011-02-18 16:33:46.262 CET [2068:2] @ DETAIL: Fehler bei Anfrage mit Größe 893716290.
    ************************************************** ***********

    Die DB läuft auf einem Windows 2008 R2 mit 24Gb Ram. Der Fehler scheint beim Autovacuum aufzutretten. Die DB Version ist 8.4.6.

    Die wichtigesten Parameter in der Config:

    #------------------------------------------------------------------------------
    # CONNECTIONS AND AUTHENTICATION
    #------------------------------------------------------------------------------
    max_connections = 500

    #------------------------------------------------------------------------------
    # RESOURCE USAGE (except WAL)
    #------------------------------------------------------------------------------
    shared_buffers = 256MB
    temp_buffers = 128MB
    work_mem = 256MB
    maintenance_work_mem = 1024MB
    vacuum_cost_delay = 100ms
    vacuum_cost_page_hit = 4
    vacuum_cost_limit = 150

    #------------------------------------------------------------------------------
    # WRITE AHEAD LOG
    #------------------------------------------------------------------------------
    wal_buffers = 128kB
    checkpoint_segments = 100
    checkpoint_timeout = 15min

    #------------------------------------------------------------------------------
    # AUTOVACUUM PARAMETERS
    #------------------------------------------------------------------------------
    autovacuum = on
    log_autovacuum_min_duration = -1
    autovacuum_max_workers = 3
    autovacuum_naptime = 5min
    autovacuum_vacuum_threshold = 600
    autovacuum_analyze_threshold = 300
    autovacuum_vacuum_scale_factor = 0.3
    autovacuum_analyze_scale_factor = 0.15
    autovacuum_vacuum_cost_delay = -1

    Keine Ahnung, was ich machen soll, damit dieser Fehler wieder verschwindet! Da es eine produktive DB ist, kann ich nicht gross "ausprobieren". Zu erwähnen ist auch noch, dass die DB trotzt dieser Meldung stabil und schnell läuft.

    Danke euch für nützlich Tips
    Also, work_mem gleich shared_buffers zu setzen ist IMHO nicht wirklich zielführend.

    Ist das ein dedizierter PG-Server? Wenn ja: setze shared_dingens auf ca. 25% dem RAM, also bei 24 GB auf etwa 6 GByte. Maintance-dingens kannst evtl. runtersetzen.

    Wieviel gleichzeitige aktive Connects hast Du so maximal? Wie komplex sind die Abfragen dann? Es können dann bis zu Clients * Tiefer der Abfragen * work_mem Speicher allokiert werden. bei z.B. 10 gleichzeitigen Abfragen, die jeweil 4 mal sortieren, kommen dann also schon mal 10 GByte RAM, die allokiert werden. Man sollte bei work_mem also vorsichtig sein. je nach workload.


    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
    hkocam ist offline Benutzer
    Registriert seit
    31.05.2007
    Beiträge
    69

    Standard

    Hallo,

    Zitat Zitat von akretschmer Beitrag anzeigen
    ...
    Ist das ein dedizierter PG-Server? Wenn ja: setze shared_dingens auf ca. 25% dem RAM, also bei 24 GB auf etwa 6 GByte. Maintance-dingens kannst evtl. runtersetzen.
    ..
    Andreas
    unter Windows wird doch eher empfohlen shared_buffers klein zu halten, oder ?
    Dem Rest kann ich nur zustimmen.

    Die Frage ist, wie es insgesamt mit der Speicherauslastung des Systems aussieht.

    FG
    hkocam

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

    Standard

    Wenn das PG 8.4.x ist, dann ist das sowieso ein 32-Bit Prozess. Also shared_buffers maximal auf 1 GB als Anfang.
    Und work_mem viel kleiner setzen, sehr viel kleiner.
    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

  5. #5
    kbsolutions ist offline Neuer Benutzer
    Registriert seit
    15.08.2007
    Beiträge
    26

    Standard

    Zitat Zitat von hkocam Beitrag anzeigen
    Hallo,



    unter Windows wird doch eher empfohlen shared_buffers klein zu halten, oder ?
    Dem Rest kann ich nur zustimmen.

    Die Frage ist, wie es insgesamt mit der Speicherauslastung des Systems aussieht.

    FG
    hkocam
    Zitat Zitat von ads Beitrag anzeigen
    Wenn das PG 8.4.x ist, dann ist das sowieso ein 32-Bit Prozess. Also shared_buffers maximal auf 1 GB als Anfang.
    Und work_mem viel kleiner setzen, sehr viel kleiner.
    Hallo Zusammen

    Danke für die Inputs. Es handelt sich hier um einen dedizierten DB-Server. Es läuft also nur die DB drauf.

    shared_buffers sollte man meines Erachtens auf einem Windows mit dieser Postgres Version auch nicht viel höher einstellen (max 512). work_mem habe ich mal auf 64Mb heruntergesetzt. Jedoch ohne Erfolg. Dazu muss ich aber sagen, dass es sich jetzt etwas schneller anfühlt, vermutlich, da er jetzt weniger RAM allozieren muss :-). Anbei sende ich euch eine Printscreen von Ressourcenmonitor. Kann es evtl. sein, dass ich die DB neu starten muss, damit er "alte" Ressourcen frei gibt. Oder sollte ich maintenance_work_mem erhöhen?
    Angehängte Grafiken Angehängte Grafiken

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

    Standard

    Was steht denn bei "shared_buffers" in der "postgresql.conf" zum Thema Neustart? ;-)
    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

  7. #7
    kbsolutions ist offline Neuer Benutzer
    Registriert seit
    15.08.2007
    Beiträge
    26

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    Was steht denn bei "shared_buffers" in der "postgresql.conf" zum Thema Neustart? ;-)
    shared_buffers habe ich nicht geändert seit dem Neustart. Der ist auf 256MB (siehst du auch im Printscreen).

  8. #8
    kbsolutions ist offline Neuer Benutzer
    Registriert seit
    15.08.2007
    Beiträge
    26

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    Was steht denn bei "shared_buffers" in der "postgresql.conf" zum Thema Neustart? ;-)
    Aber vielleicht sollte ich shared_buffers auf 128MB setzen...? Wie gesagt, gross ausprobieren geht hier nicht wirklich. Dass müsste ich ansonsten jeweils in der Nacht machen :-).

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

    Standard

    Zitat Zitat von kbsolutions Beitrag anzeigen
    Aber vielleicht sollte ich shared_buffers auf 128MB setzen...? Wie gesagt, gross ausprobieren geht hier nicht wirklich. Dass müsste ich ansonsten jeweils in der Nacht machen :-).
    Warum fragst Du eigentlich, wenn Du die Antworten dann doch negierst?

    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

  10. #10
    kbsolutions ist offline Neuer Benutzer
    Registriert seit
    15.08.2007
    Beiträge
    26

    Standard

    Zitat Zitat von akretschmer Beitrag anzeigen
    Warum fragst Du eigentlich, wenn Du die Antworten dann doch negierst?

    Andreas
    Sorry, das war nicht so gemeint. Ich bin einfach ratlos.

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Problem "Speicher aufgebraucht"-Fehler beim XML-Export
    Von mariana im Forum SQL
    Antworten: 3
    Letzter Beitrag: 07.02.2012, 16:57
  2. Problem Fehler: Speicher aufgebraucht
    Von zweigelt im Forum SQL
    Antworten: 9
    Letzter Beitrag: 28.07.2010, 07:43
  3. Windows Server 2008 - 64-Bit
    Von marc9022 im Forum Sonstige Installationsprobleme
    Antworten: 4
    Letzter Beitrag: 09.10.2008, 13:25
  4. PG auf Windows nimmt zuwenig Speicher
    Von gnoerz im Forum Konfiguration
    Antworten: 0
    Letzter Beitrag: 17.01.2008, 00:12
  5. Migration Unix-Postgres to Windows-Postgres?
    Von Spiderman im Forum Migration
    Antworten: 1
    Letzter Beitrag: 12.10.2007, 07:05

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