auf unserem DB-Server läuft jede Nacht der vacuum analyze Prozess ( online, per cron job ). Seit Wochen ohne Probleme. Seit einigen Tagen führt dieser Prozess allerdings zu langsamen Queries, so dass der Server lahm gelegt wird.
Wir konnnten das Problem dadurch beheben, indem wir den vacuum analyze Prozess manuell noch eimal gestartet haben, dieses Mal offline. Im Anschluss liefen alle Abfragen wieder ohne Probleme. Mit dem folgenden nächtlichen vacuum analyze traten die Probleme dann allerdings erneut auf.
Da der cronjob wochenlang ohne Probleme lief, vermuten wir, dass es einen Zusammenhang mit der Größe der DB gibt. Wir haben nur eine kritische Tabelle, die inzwischen eine Größe von ca 4 GB hat ( 80 Mio. rows ). Für diese Tabelle existieren 3 Indexe, die je eine Größe von knapp 2 GB haben. Der Server hat 8 GB Arbeitsspeicher und wir verwenden psql 8.1.11.
Wir stochern im Moment im Nebel, und haben das Problem erstmal “verschoben”, indem wir den cronjob abgestellt haben.
Da der cronjob wochenlang ohne Probleme lief, vermuten wir, dass es einen Zusammenhang mit der Größe der DB gibt. Wir haben nur eine kritische Tabelle, die inzwischen eine Größe von ca 4 GB hat ( 80 Mio. rows ). Für diese Tabelle existieren 3 Indexe, die je eine Größe von knapp 2 GB haben.
Bei 4 GByte table-Größe erscheinen mit 2 GByte große indexe kapott. Wie groß ist eine Table-Row (welche Felder) und worauf liegt der Index? Vielleicht mal die Indexe neu anlegen.
Theoretisch meinen die PG Hersteller, dass man mit “unendlich” grossen DB umgehen kann, das ist aber durch das OS begrenzt. Nehmen wir mal an dass du auf Win32 Plattform arbeitest, da ist in der einfachen Variante bei 32 Bit (sprich 4GB) schluss. WinNT kann auch mit 64bit-Dateien was anfangen, vorrausgesetzt, dass man die API entsprechend benutzt. Ob Postgres diese 64 Bit - Datei-API benutzt und entsprechend (low und high dword) die Dateien adressiert weiss ich nicht.
Fraglich ist auch, wie PG reagiert wenn “das Ende” erreicht wurde. Ich erinnere mich noch an uralte Interbase-Zeiten (und acuh an den MSSQL-Server) da hat man gaenzlich drauf verzichtet bei solchen überlaufenden Operationen entsprechende Fehler zu liefern (aus performancegründen wahrscheinlich)
Wenn Du Pech hast, ist dabei auch noch die DB kaputt. Wenn du nur ein wenig Pech hast, die Indices, wenn du Glück hast, trifft das alles nicht zu.
Gruß
— Nachtrag —
Interbase reagierte beispielsweise sehr sehr träge - und Schreiboperationen liefen einfach ins Leere. Ebenso verhielt sich MsSQL einst - da konntest du INSERTen wie du wolltest ohne Fehlermeldung - Datensaetze waren auch da - nur andere eben defekt. Ob das heute immernoch so ist müsste man recherchieren.
Das können wir mal probieren. Der ist zwar bereits auf 160 MB erhöht worden, kann aber durchaus auch noch zu wenig sein.
Muss ich nur auf später verschieben, da am Wochenende viel traffic ansteht, und wir das lieber erstmal so überstehen wollen.
Die Größe der Indexe ist schon durch reindex von 2,4 auf 1,8GB reduziert worden.
Die Tabelle enthält 3 Integer ( Primary und zwei Foreign key, auf die auch die Indexe liegen ), sowie zwei smallint-Werte. Die Größen sollten also tatsächlich korrekt sein.
Man kann auch einstellen, wieviel Performance autovaccum “fressen” darf, dafür gibt es drei Parameter in der postgresql.conf (und eine Tabelle pg_autovacuum, in der man dies noch einmal für jede Tabelle einzeln eintragen kann).
Allerdings erfordern die drei Parameter etwas Feintuning und Beobachtung, wenn man sie verändern möchte - sonst geht der Effekt hinten los.
Mit der DB ist aber alles OK. Es macht nur den Anschein, als wenn während des vakuum analyze Prozesses ein “falscher” query plan benutzt wird, der dann auch beibehalten wird.
Komischerweise ja auch nur, wenn nebenbei noch requests bearbeitet werden. Das “offline vacuum analyze” hat ja erstmal alles wieder ins Lot gebracht.
Wenn man was nicht weiss, dann entweder nachschauen oder einfach mal ruhig sein.
Wenn Du Pech hast, ist dabei auch noch die DB kaputt.
Wie gesagt, einfach mal nachschauen - oder schweigen, statt bloss Vermutungen zu schreiben. Abgesehen davon, befindet sich PG bei 4 GB noch nicht mal in der Nähe der Grenzwerte. Das ist vielleicht noch aus den alten Interbase Zeiten so, das man alles in eine Datei schreibt. Mittlerweile ist man von diesem Konzept aber schon mehrere Jahre abgerückt.
Wenn du nur ein wenig Pech hast, die Indices, wenn du Glück hast, trifft das alles nicht zu.
Er hat kein Glück.
Er hat eine Datenbank, die sich um die Sicherheit seiner Daten sorgt.
Also, ehe du hier weiter wilde Gerüchte in den Raum streust, wie wäre es, wenn du einfach mal hingehst und probierst, wie sich PG im Falle von z.B. “Festplatte voll” verhält?
Interbase reagierte beispielsweise sehr sehr träge - und Schreiboperationen liefen einfach ins Leere. Ebenso verhielt sich MsSQL einst - da konntest du INSERTen wie du wolltest ohne Fehlermeldung - Datensaetze waren auch da - nur andere eben defekt. Ob das heute immernoch so ist müsste man recherchieren.
Falls du das noch nicht mitbekommen hast, das hier ist ein PostgreSQL Forum - das ist nicht das gleiche wie Interbase und das ist auch kein MSSQL. Und du spekulierst jetzt bereits das uhm vierte Mal innerhalb eines Postings wild herum, ohne auch nur einmal nachgeprüft zu haben, was von deinen Vermutungen überhaupt stimmt.
Das Du nichts weißt, wissen wir. Aber warum tust Du das immer wieder kund? Du hast ganz schlicht keine Ahnung und davon jede Menge. Bevor Du dummes Zeugs erzählst, warum guggst Du nicht einmal in die FAQ?
Ich zititere mal:
The maximum table size of 32 TB does not require large file support from the operating system.
Large tables are stored as multiple 1 GB files so file system size limits are not important.
lies doch mal was ich schrieb … da stand explizit erwähnt, dass sich meine hinweise auf “nicht-wirklich-wissen” beziehen …
ohje …
und wieso sollte ich diese eventualitaet nicht erwaehnen ? immerhin hat uns diese inclusiver deiner kindischen eitelkeit klarheit darueber verschafft, dass es daran mit an sicherheit grenzender wahrscheinlichkein nicht liegt
Ihn zu ignorieren habe ich beschlossen und halte das auch. Das wird mich aber nicht davon abhalten, wenn er anderen komplett falsche Hinweise gibt, das klarzustellen. Okay?
