Vacuum

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 :slight_smile:

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 :slight_smile:

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

Magnus Hagander: PostgreSQL vs 64-bit windows - SWiK


Andreas

  1. ja … es gibt 2003, Vista und nat. W7 64 bit versionen …
    1.1. achtung: es gibt keine unter windows laufende 64 bit version von PG - nur für unixoide systeme (z.B. linux)
  2. ja - hier kommt es zu einem Fehler weil ein index > 32 bit auf irgendeine range zugreifen will die schlichtweg nichtmehr adressierbar ist - oder der index selbst groesser als 32 bit würde.
    bug hin oder her … du bist an system-grenzen gestoßen. Interssant ist halt, dass du die daten zwar reinbekommen hast - aber vacuum rumzickt.

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 hab z.B. aus spass unter meinem Vista 64 ein Ubuntu64 in einer VM laufen - damit ich darin ein 64 bit version von PG laufen lassen kann. Wie ich schon schrieb - direkt unter windows gibt es keine binaries (selbercompilierer bin ich nicht - ob das ueberhaupt geht weiss ich auch nicht) - zum forschen optimal - und erstaunlich flott

Tatsache ist, dass jeder einzelne PG-Prozess maximal 2 GB adressieren kann. Das Nadelör zwischen den Prozessen ist das shared_memory - und ist auch nur 32 bit breit - auf 32 bit systemen.

D.h. auf deinem 8GB System würde zwar der RAM durch die vielen Connections - jeweils ein Prozess - auch gut genutzt, das ist aber im VGL zu einem richtigen 64 bit System nur suboptimal - da die Connections nur ueber 32 bit kommunizieren koennen (man muss sich ja z.B. über locks / transaktionen und so zeug queries caches etc. austauschen). Sinnlos ist es aber nicht.

Gibt es ein Tool um eine DB auf Fehler und inkonsistenz zu prüfen? Der Restore sieht soweit wirklich prima aus.

Ich denke, wir werden die DB offline schlalten, einen Dump erstellen und diesen wieder einlesen. Das scheint wenigstens das Problem zu lösen.

na bitte :
In a multi-threaded database server, all client connections share the memory space, and are again limited by the total addressable memory region. With PostgreSQL, you could easily have more than 1Gb per backend (if necessary) without running out of memory, which significantly pushes away the point when you need to go to 64-bit.

deshalb sind die 8GB nicht sinnlos

Bullshit.

Andreas

Was bist du - ne Diva? Zicke? oder nur peinlich?

Mir nix bekannt. Aber wenn Dump läuft, ist die DB auch okay.

Ich denke, wir werden die DB offline schlalten, einen Dump erstellen und diesen wieder einlesen. Das scheint wenigstens das Problem zu lösen.

Erstell den Cluster komplett neu, also initdb.

Andreas

Besten Dank für eure Mithilfe. Ich habe jetzt einen Restore auf dem Problemserver gemacht und kann problemlos ein Vacuum auf der Tabelle ausführen. So werde ich wohl jetzt warten und hoffen, dass bald eine 64Bit Version für Windows erscheint :-).

Nochmals Danke und beste Grüsse

PS: Seit etwas netter zu einander :slight_smile: