Shared Buffer im Voraus laden ?

Hi alle,

mehr mal so eine konzeptuelle Frage bzw Spinnerei.

Bei großen Webanwendungen mit hohem Traffic habe ich schon oft das Problem gesehen, dass die nach einen Restart der PostgreSQL sehr sehr holprig wieder anlaufen.

Übliches Phänomen: Die Datenbank antwortet anfangs ziemlich langsam, weshalb die Threads lange hängen, irgendwann läuft dann der Apache vorne mit Verbindungen voll und die Seite ist überhaupt nicht mehr erreichbar.

Je nach Größe der Datenbank und der Webanwendung schwingt sich das System innerhalb der ersten paar Minuten dann wieder ein bis es irgendwann wieder mit der gewohnten Geschwindigkeit antwortet.

Ich hab jetzt einfach mal ins blaue rein vermutet dass das u.a. daran liegt wenn der shared buffer anfangs noch keine Daten enthält, da dieser ja eine starke Beschleunigungswirkung auf häufig genutzte Queries haben sollte.

Wäre es also möglich bzw sinnvoll, den shared buffer beim Restart der Postgres einmal mit den zuletzt verwendeten Pages vollzuladen, damit die Datenbank gleich von anfang an “rattenschnell” ist?? Könnte man ein solches Feature in die Software einbauen?

Du könntest ein solches “Feature” in dein Initscript einbauen.

In der Datenbanksoftware selbst hat das nichts verloren: woher soll die Datenbank wissen, welche Teilbestände deiner beliebig großen Datenmenge sie vorab laden soll?

Was du machen kannst, ist die gewünschten Daten per Skript einmal kurz nach dem Starten der DB abzurufen. Danach ist die Wahrscheinlichkeit hoch, das die Daten dann für weitere Anfragen im Speicher liegen.
Nennt man “Warmlaufen” des Cache.

ads,
zu deiner Frage woher die Datenbank das wissen soll:

Zum Beispiel, indem sie den Inhalt des shared buffer beim Shutdown in eine Datei schreibt.
Oder einfach nur die Info, welche Pages im Shared Buffer waren.
Man kann ja meistens davon ausgehen, dass die Workload beim nächsten Hochfahren ähnlich sein wird wie vorher.

Die Idee mit dem Initskript ist an sich gut, aber dafür müsste ich ja selber wissen welche Daten das genau sind die ich preloaden muss. Da beißt sich die Katze in den Schwanz :wink:
Viele Webanwendungen sind ja auch in der Weiterentwicklung sehr dynamisch, so dass auch die Datenmodelle häufiger mal angepasst werden.

So, damit ich das richtig verstehe: die Inhalte in deinem Shared Buffers sind hochdynamisch und ändern sich, aber trotzdem soll es Sinn machen, diese sich ständig ändernden Inhalte für den nächsten Restart der Datenbank vorzuhalten? Obwohl du nicht davon ausgehen kannst, dass aufgrund der sich verändernden Anfragesituation das überhaupt Sinn macht?

Merkst du etwas? :wink:


Entweder du kannst die häufig gelesenen Tabellen benennen (über ein kleines Skript und einen Blick in pg_stat_user_tables kannst du dir da sicher etwas bauen) oder das ganze macht wenig Sinn und du überlässt der Datenbank die Arbeit.

Du verstehst mich nicht ganz richtig.

Die Anfragesituation ändert sich immerhin so häufig, dass es nervig wäre ein Preload Skript ständig pflegen zu müssen.

Aber sie ändert sich jetzt auch nicht alle 5 Sekunden so stark, dass die Daten im Cache völlig sinnlos und nicht zu gebrauchen sind.

Die häufig gelesenen Tabellen kann ich benennen, aber die relevanten Zeilen in der Tabelle oder die besonders häufig genutzten Teile der Indizies oder was auch immer sind halt schon schwerer zu benennen.

Gibt es hier sonst niemanden außer mir, der dieses Problem schonmal hatte?
Ist es wirklich völlig sinnlos, dafür eine allgemeine Lösung zu implementieren?

Im allgemeinen hat man Uptimes in einer Höhe, wo man sich um dieses Problem eher wenig gedanken macht …

Andreas

Bei SCRUM-Prozessen ist es ja oft so dass man alle 2-3 Wochen ein Deployment zu machen hat, was nunmal eine kurze Downtime bedeutet. Dann wäre es natürlich schon schön die Downtime möglichst kurz und das Wiederanlaufen möglichst reibungsfrei zu haben. Gleiches gilt für Updates der Postgres, die ja auch alle paar Wochen bis Monate mal anstehen.

Aber ich glaube ich geb es mal auf, zumindest in diesem Forum. Ich verstehe zwar nicht warum, aber ihr scheint aus irgendwelchen Gründen meine Idee so doof zu finden dass ihr lauter nicht-Argumente finden müsst die dagegen sprechen. Jedenfalls habe ich noch kein einziges Argument gehört dass mich überzeugt.

Also vielleicht versuche ich es woanders nochmal, mal sehen.

Viele Grüße
Bastian

Weil so eine Funktion so spezialisiert ist, dass sie im Kern von PostgreSQL nicht viel Sinn macht. Ausserdem kann jeder mit wenig Aufwand so etwas in einem Startup-Script selber unterbringen, so dass der notwendige Entwicklungsaufwand auf Seiten des PostgreSQL Teams besser für etwas anderes verwendet wird (z.B. index only scans :rolleyes: ).

Wir machen sowas z.B. dadurch, dass wir bestimmte URLs in unserer WebAnwendung nach dem Starten des Tomcat aufrufen um die diversen Caches zu füllen (damit wird dann auch gleich die DB “warmgelaufen”).
Ein Warmup ausschliesslich für die DB bringt in unserem Umfeld z.B. nichts (bzw. sehr wenig).

Ein kleines Script was einfach ein SELECT auf die wichtigsten Tabellen macht und beim Hochfahren der DB ausgeführt wird, ist sicherlich sehr schnell realisiert. Dieses Script hat dann auch den Vorteil, dass es speziell auf Deine Umgebung optimiert ist - etwas was eine allgemeien Lösung in PostgreSQL nur bieten könnte, wenn diese sehr stark konfigurierbar wäre.

Und ich vermute fast, dass die Konfiguration dieses Features auch nicht schneller wäre, als ein SQL Skript mit 10 SELECT Statements zu erstellen.

Was hat ein Entwicklungsprozess mit einem Deployment oder gar dem 24/7-Betrieb einer Datenbank zu tun?
Du vergleichst hier Äpfel mit Bananen.


Aber ich glaube ich geb es mal auf, zumindest in diesem Forum. Ich verstehe zwar nicht warum, aber ihr scheint aus irgendwelchen Gründen meine Idee so doof zu finden dass ihr lauter nicht-Argumente finden müsst die dagegen sprechen. Jedenfalls habe ich noch kein einziges Argument gehört dass mich überzeugt.

Das dich die Argumente, die hier reichlich gebracht wurden, nicht überzeugen können, liegt nun eher an dir als an uns.
Argumente selbst gab es reichlich, aber ich habe mir keine Lust, die Finger deswegen wund zu schreiben.
Die von dir genannten “Nicht”-Argumente sind eigentlich genau die Grundlage, mit der du weiter arbeiten solltest.

Du hättest im Endeffekt die Möglichkeit, entsprechende Patches zu erstellen und beim PostgreSQL Projekt einzureichen. Dann siehst du, ob das Sinn macht - du bist ja schließlich von deiner Idee überzeugt und wir haben alle nicht Recht.

Ziemlich viel. Schonmal in einem solchen Projekt gearbeitet?

Klar, das hat man immer. Ich dachte nur ich diskutiere das hier mal an bevor ich loscode. Hätte mir gewünscht nicht gegen eine solche Wand zu rennen.

Sicher, häufig sogar. Auf beiden “Seiten”.


Klar, das hat man immer. Ich dachte nur ich diskutiere das hier mal an bevor ich loscode. Hätte mir gewünscht nicht gegen eine solche Wand zu rennen.

Dann sollte dir spätestens jetzt klar sein, das deine hier zur Diskussion gestellte Idee nicht so ganz das wahre ist - oder?