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

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

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

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?

Was steht denn bei “shared_buffers” in der “postgresql.conf” zum Thema Neustart? :wink:

shared_buffers habe ich nicht geändert seit dem Neustart. Der ist auf 256MB (siehst du auch im Printscreen).

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

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

Hallo,

Ich habe nicht soviel Ahnung(speziell unter Windows) was von dieser Log-Meldung zu halten ist.
Du hast ein paar Optionen:

  • schreib mal auf der general-ML (oder bugs-ML?) was, am Besten genauso ausführlich, wie in deiner 1. Mail, und guckst mal was dabei rauskommt.
    Die Entwickler lesen dort mit und haben eher eine Idee welcher Codepfad zu solch einem Fehler führt.
  • du solltest auf jeden Fall vorher auf 8.4.7 aktualisieren und prüfen, ob der Fehler dann verschwindet. Man sollte nicht Bugs jagen, die schon behoben sind.
  • Am besten du gehst direkt auf 9.0.3 und zwar die x64-Variante. Dann hast du erst Mal Ruhe vor den Begrenzungen eines 32-Bit Prozesses :slight_smile:

Was ich immer noch nicht verstehe ist, in welchem Zusammenhang diese Logmeldung auftaucht.
Du solltest z.B. das Logging beim autovacuum erhöhen.

Auf deinem Screenshot ist ein pgsql-Prozess zu sehen, der über 600 MB an privatem Speicher benutzt, was macht der ?

soviel in kürze
Freundliche Grüße

hkocam

Danke für die Inputs, ich werde mal die an die Mailinglist schreiben. Update auf Version 9x64 steht in Planung. Aber dafür brauche ich noch mehr Zeit. Der Prozess welcher 600MB braucht ist ein SELECT, weiteres weiss ich evtl. morgen.

Nur zur Information: Ich habe den DB-Server diese Nacht neu gestartet, wobei ich das shared_buffers noch auf 128MB gesetzt habe (vorher 256MB). Seit dem Zeitpunkt bekommen ich keinen Fehler-Eintrag mehr im Log. Was ich jetzt nicht sagen kann, ist, ob es der Neustart war, oder das heruntersetzen von shared_buffers oder beides. Ich werde beim nächsten Neustart den Wert wieder zurücksetzen, um dies herauszufinden. Das wird jedoch nicht so bald geschehen. Zudem werden ich in den nächsten 4 Wochen auf Version 9 umstellen. Bin ja gespannt, was dies für die Performance bedeutet.

Fazit: Im zweifelsfall DB-Server erste mal neu starten und ab Version 8.4 auf Windows, shared_buffers klein halten.

Falls ich noch was zusätzliches herausfinde, werde ich dies gerne hier posten. Danke für eure Mithilfe!

Hier noch einen Hinweis von Tom Lane erhalten über die mailinglist:

Right offhand this looks like a corrupt-data problem, ie, trashed length word in some variable-length value. Autovacuum isn’t particularly at fault, it just happens to be trying to examine a value that you haven’t read lately in regular use of the database. I’d suggest seeing whether pg_dump doesn’t find the problem too; if so you’ll need to start doing data recovery.

Da ich kein Problem mit pg_dump und pg_restore habe, werde ich es mal so belassen und keine Zeit mehr dafür investieren.