Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 11

Thema: Shared Buffer im Voraus laden ?

  1. #1
    batzee ist offline Neuer Benutzer
    Registriert seit
    27.08.2007
    Beiträge
    26

    Idee 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?

  2. #2
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    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.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  3. #3
    batzee ist offline Neuer Benutzer
    Registriert seit
    27.08.2007
    Beiträge
    26

    Standard

    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 ;-)
    Viele Webanwendungen sind ja auch in der Weiterentwicklung sehr dynamisch, so dass auch die Datenmodelle häufiger mal angepasst werden.
    Geändert von batzee (14.02.2011 um 13:49 Uhr)

  4. #4
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    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? ;-)


    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.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  5. #5
    batzee ist offline Neuer Benutzer
    Registriert seit
    27.08.2007
    Beiträge
    26

    Standard

    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?

  6. #6
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.468

    Standard

    Zitat Zitat von batzee Beitrag anzeigen
    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  7. #7
    batzee ist offline Neuer Benutzer
    Registriert seit
    27.08.2007
    Beiträge
    26

    Standard

    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

  8. #8
    castorp ist offline Erfahrener Benutzer
    Registriert seit
    27.06.2009
    Beiträge
    525

    Standard

    Zitat Zitat von batzee Beitrag anzeigen
    BAber 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.
    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 ).

    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.
    A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'

  9. #9
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    Zitat Zitat von batzee Beitrag anzeigen
    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.
    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.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  10. #10
    batzee ist offline Neuer Benutzer
    Registriert seit
    27.08.2007
    Beiträge
    26

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    Was hat ein Entwicklungsprozess mit einem Deployment oder gar dem 24/7-Betrieb einer Datenbank zu tun?
    Ziemlich viel. Schonmal in einem solchen Projekt gearbeitet?

    Zitat Zitat von ads Beitrag anzeigen
    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.
    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.

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Shared Memory aufgebraucht
    Von ulischerrer im Forum Allgemeines
    Antworten: 9
    Letzter Beitrag: 18.03.2012, 16:25
  2. Textdateien mit Postgres laden
    Von hanspeter im Forum SQL
    Antworten: 14
    Letzter Beitrag: 20.04.2010, 21:26
  3. could not reattach to shared memory
    Von aguldner im Forum Konfiguration
    Antworten: 19
    Letzter Beitrag: 03.04.2009, 13:56
  4. postgis / buffer / mapfile
    Von Lukas im Forum PostGIS
    Antworten: 2
    Letzter Beitrag: 25.03.2007, 14:35
  5. phppgadmin Seite laden
    Von nixdorf im Forum phpPGAdmin
    Antworten: 6
    Letzter Beitrag: 22.12.2006, 19:20

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum