Wenn ich ein VACUUM auf eine bestimmte Tabelle machen möchte, erhalten ich immer folgende Fehlermeldung:
********** Error **********
ERROR: out of memory
SQL state: 53200
Detail: Failed on request of size 236317608.
Die Tabelle enthält 7 Millionen reltuples bei 135329 relpages
Muss ich etwas an der Konfiguration ändern oder ist diese Tabelle oder eine System-Tabelle korrupt?
Ich mache jetzt eine db_dump und restore… nur zum testen…
Hat jemand einen sonstigen Tip?
Versuch mal den Parameter “maintenance_work_mem” zu erhöhen.
Ansonsten: wie sehen denn deine Konfigurationsparameter zur Speichernutzung aus?
maintenance_work_mem ist auf 1024MB eingestellt.
Nach dem Restore auf einem anderen Server mit nur 256MB maintenance_work_mem, kann ich problemlos ein VACUUM auf die Tabelle ausführen…
Das beantwortet immer noch nicht meine Frage.
ich habe die maintenance_work_mem auf 1960MB geändert und es kommt immer noch die gleiche Fehlermeldung. Wenn ich auf 2048MB gehe, erhalte ich die folgende Fehlermeldung:
ERROR: 2097152 is outside the valid range for parameter “maintenance_work_mem” (1024 … 2097151)
Die weiteren Parameter sind:
max_connections = 500
shared_buffers = 1024MB
temp_buffers = 128MB
effective_cache_size = 6656MB
work_mem = 256MB
maintenance_work_mem = 1960MB
max_fsm_pages = 2000000
max_fsm_relations = 2000
wal_buffers = 128kB
Der Server hat 8GB Ram und läuft auf einem Windows 2003 R2 X64.
Postgres Version 8.3
Sieht nach einem Bug aus:
2097151 = 0x1FFFFF
wohl ein Überlauf
ERROR: 2097152 is outside the valid range for parameter “maintenance_work_mem” (1024 … 2097151)
2097151 = 22 bit
1024 = 10 bit
macht in Summe 32 bit
nimm doch ein 64Bit Betrübssyschdem - und natürlich auch die 64bit version von PG 
Wohl eher nicht. PG ist auf Fenster 32bit, 2 GByte-Grenze. Da sind 8 GByte, salopp gesprochen, die Perlen, die man vor Säue wirft.
Andreas
du hast die untere grenze vergessen - schau die fehlermeldung nochmal an …
der begint bereits bei 10 bit - dazu nochmal 22 … macht wieviel?
ok … man muss es (Dir zuliebe) ja nicht gleich “bug” nennen … aber die Fehlermeldung ist scheisse - dass musst zugeben … ein bug wäre es, wenn bereits vorher eine prüfung vorgesehen waere die aber nicht greif - um gescheite fehlermeldungen zu liefern.
obwohl - bug ist schon korrekt - immerhin hat er die daten ja auch da reingekriegt - und es wird ein innerer zustand erzeugt, mit dem PG umgehen koennen sollte (vacuum). tut es aber nicht …
wieso … 32 bit heisst 2 GB per process … das heisst 2 GB pro Connection … oder nicht?
Das ist aber auch garnicht das aktuelle Problem - nur eine Randbemerkung
Oder nicht.
Hint: Shared Memory
Ahared memory ist doch keine allgemeine Grenze! Das ist halt für IPC notwendig. Es gibt ja immernoch genug Notwendigkeiten für den Heap jedes Prozesses.
Die Aussage, dass 8 GB für die Katz seien stimmt so einfach nicht.
PostgreSQL kann auf einem 32-Bit System aber nur maximal 4 GB davon nutzen. Das wirst auch du nicht in Abrede stellen können.
Die Aussage, dass 8 GB für die Katz seien stimmt so einfach nicht.
Denk was du willst, wenn die Datenbank nur max. 4 GB nutzen kann, bringen weitere 4 auch nichts. Selbst das OS kann da nur mittelmäßig Gebrauch von machen …
Pass auf - das ist unter Windows Sache des Speichermanagements … Windows XP/2003 kann auch in der 32 Bit Version mehr als 4 GB für Prozesse nutzbar machen. Das ist so ein oller Trick aus DOS-zeiten wie mit XMS 
Die Prozesse nutzen sowieso virtuellen Speicher - der bei 32 Bit windows immer irgendwas mit 2 3 oder 4 GB zu tun hat. Wo der Speicher dann speziell liegt ist dem Prozess ja egal.
Daher machen die 8GB durchaus Sinn.
Richtig ist, dass EIN Prozess trotzdem nicht mehr als 32 Bit addressieren kann.
Wir reden hier aber mehrere Prozesse …
Das ist z.B. sogar so ein Anwendungsfall wo das Konzept PG-Prozesse je Connection zu forken ein Vorteil ist. Im Gegensatz zu DBMS die in einem Prozess nur Threads erzeugen. Die haben dann pech
Lief der Dump durch?
Der Fehler könnte durchaus auf eine korrupte Tabelle deuten.
Andreas
spannend zu erwähnen ist auch, dass ich bei shared_buffers auch nicht mehr als die 2GB eintragen kann… wenn ich das mache startet der DB-Server nicht mehr.
Wusste gar nicht, dass es für Windows eine 64Bit Version gibt…? Soll das jetzt heissen, dass die Grenze hier bei 2GB liegt?
Komisch, dass es beim Restore geht. By the Way, das ist ein Windows 2003 R2 32Bit System mit 3GB Ram und wie gesagt “nur” 256MB maintenace_work_mem. Ebenfalls mit PG 8.3
Wir reden immer noch über einen Speicherbereich, auf den alle Prozesse zusammen zugreifen müssen.
Aber langsam reicht mit deine Verbohrtheit.
nein - wir reden über die Aussage, dass 8 GB für die Katz wären.
Aber langsam reicht mir deine Begriffsstutzigkeit
bitte nicht streiten… schlussendlich bin ich froh über neue Erkenntnisse und konstruktive Voschläge. Wie gesagt, lief der Dump und Restore Problemlos durch und alles scheint bestens mit dieser Tabelle wohl bemerkt auf dem anderen Server (Windows 2003 32Bit). Was ich mal testen kann ist ein Restore auf dem 64Bit System. Vielleicht hat es ja damit zu tun.
Ich auch nicht. Hat aber nix zu bedeuten, es gibt schlicht keine.
Soll das jetzt heissen, dass die Grenze hier bei 2GB liegt?
Ja. Windows und viele Daten macht ja auch nicht wirklich ernsthaft Sinn, oder?
Komisch, dass es beim Restore geht. By the Way, das ist ein Windows 2003 R2 32Bit System mit 3GB Ram und wie gesagt “nur” 256MB maintenace_work_mem. Ebenfalls mit PG 8.3
Ich vermute eine korrupte Tabelle, vielleicht durch einen Plattenfehler oder sonstwas. Du solltest prüfen, ob das Backup brauchbar & vollständig ist.
Andreas