Dokumentation / Dein Server
Datenbank-Performance
Lass calmo.cloud das PostgreSQL deines Servers auf seine Hardware abstimmen und sieh, wie Arbeitsspeicher und Verbindungen zwischen der Datenbank und deinen Odoo-Diensten aufgeteilt werden.
Alle Odoo-Dienste auf einem Server teilen sich ein PostgreSQL. Von Haus aus läuft diese Datenbank mit den Einstellungen ihres Images, und die sind für einen Laptop ausgelegt, nicht für deinen Server — eine Maschine mit 16 GB Arbeitsspeicher nutzt davon 128 MB für den Datenbank-Cache. calmo.cloud kann PostgreSQL auf die Hardware abstimmen, auf der es tatsächlich läuft, und stellt sicher, dass Datenbank und Odoo-Dienste nicht beide denselben Arbeitsspeicher versprochen bekommen.
Einschalten #
Navigiere zu Servers, wähle einen Server, öffne die Seite Configuration und wechsle zum Postgres-Tab. Unter den Zugangsdaten findest du einen Abschnitt Performance mit dem Schalter Let calmo.cloud tune PostgreSQL.
Das Ein- oder Ausschalten erstellt den PostgreSQL-Container einmal neu. Jeder Odoo-Dienst auf dem Server verliert für einige Sekunden seine Datenbankverbindungen und verbindet sich neu. Such dir dafür einen ruhigen Moment aus.
Du musst nichts ausfüllen. Jedes Feld ist leer und zeigt als Platzhalter den Wert, den calmo.cloud für deinen Server ermittelt hat — genau der wird angewendet.
Woher die Zahlen kommen #
calmo.cloud bemisst die Datenbank anhand der Hardware, die dein Monitoring-Agent meldet. Ein Server braucht daher aktiviertes Telegraf-Monitoring, bevor eine Empfehlung erscheint.
Der Arbeitsspeicher eines Servers wird dreigeteilt:
| Anteil | Was er abdeckt |
|---|---|
| System, Proxy und Agent | 10 % des Arbeitsspeichers, mindestens 512 MB und höchstens 4 GB, für Betriebssystem, Reverse-Proxy und Monitoring-Agent |
| PostgreSQL | Die Reserven für Wartung und Autovacuum sowie ein Cache für Tabellen- und Indexseiten, wenn der Server dafür Speicher übrig hat |
| Odoo | Alles Übrige, geteilt zwischen den Diensten auf dem Server |
Der Block Resource Budget oben im Performance-Abschnitt zeigt diese Aufteilung für deinen Server, mit einem Anteil pro Odoo-Dienst. Er erscheint außerdem auf der Metrics-Seite des Servers und im Performance-Abschnitt jedes Odoo-Dienstes.
Der Balken zeigt, was genommen werden darf, nicht, was gerade genutzt wird: jeder Dienst zählt mit dem Speicherlimit, das für ihn konfiguriert ist, und PostgreSQL mit dem, was seine Einstellungen reservieren. Ein Dienst, der für 2 GB konfiguriert ist, zählt als 2 GB, ob er ausgelastet ist oder nicht — genau das macht die Summe zu einem Versprechen, mit dem du planen kannst. Was die Maschine gerade wirklich tut, siehst du in den Server-Metriken.
Wenn du einen Dienst mit einem anderen Team teilst, sieht dieses Team dieselbe Aufteilung für die Maschine, auf der sein Dienst läuft — es braucht sie, um seinen eigenen Dienst sinnvoll zu bemessen — aber nie die Namen fremder Dienste. Die erscheinen dort als „Another team“.
PostgreSQL bekommt nur dann einen großen eigenen Cache, wenn es die Daten tatsächlich darin halten könnte. Sind die Datenbanken auf einem Server größer als der freie Arbeitsspeicher, lässt calmo.cloud diese Einstellung dort, wo das Datenbank-Image sie hat, und überlässt das Caching dem Betriebssystem, weil es das besser kann: Auf einem 8-GB-Server mit 35 GB Daten kostete ein 2-GB-Cache für PostgreSQL gemessen 14 % des Durchsatzes, weil jedes Megabyte, das er belegte, dem Betriebssystem zum Cachen derselben Tabellen fehlte. Auf einem Server, dessen Daten hineinpassen, nimmt er ein Viertel des freien Speichers.
Weil die Werte abgeleitet und nicht gespeichert werden, passt sich ein Server, der mehr Arbeitsspeicher bekommt, selbst an: Die Empfehlung folgt der Hardware, und beim nächsten Anwenden wächst PostgreSQL mit der Maschine.
Einen Wert selbst setzen #
Jedes der acht Felder kannst du mit einem eigenen Wert füllen, zum Beispiel 4GB für die Shared Buffers. Speicherwerte brauchen eine Einheit — 512MB, 4GB — weil eine nackte Zahl für PostgreSQL Disk-Blöcke bedeutet.
Auf einem Server ohne Monitoring gibt es nichts, wogegen sich bemessen ließe, daher prüft calmo.cloud nur, ob ein Wert im zulässigen Bereich liegt — nicht, ob er zur Maschine passt. Schaltest du das Monitoring ein, lehnt es zusätzlich Shared Buffers ab, die größer als 40 % des gemeldeten Arbeitsspeichers sind, denn ungefähr dort hört PostgreSQL auf, überhaupt starten zu können.
Ein Feld wieder zu leeren, ist der Weg zurück zum abgeleiteten Wert. Leer heißt „weiter ableiten“, nicht „kein Wert“, du musst also nie raten, was calmo.cloud gewählt hätte. Reset to recommended leert alle auf einmal.
Einstellungen, die calmo.cloud über diese acht hinaus verwaltet — Autovacuum, Checkpoints, das Write-Ahead-Log, der Query-Planner und das Logging langsamer Abfragen — sind schreibgeschützt unter Also applied aufgeführt. Odoos meistgenutzte Tabellen brauchen deutlich häufigere Autovacuum-Läufe, als PostgreSQL sie standardmäßig durchführt, und das macht den Großteil davon aus. Einige der acht werden auseinander berechnet, sodass das Erhöhen des einen das andere senkt: Nimmst du mehr Speicher für den Cache, bekommt jede Sortierung weniger, weil beides aus demselben Anteil der Maschine kommt.
Anwenden, und der eine Neustart #
Beim Speichern des Abschnitts werden die Einstellungen sofort in die laufende Datenbank geschrieben. Nichts wird unterbrochen: PostgreSQL liest seine Konfiguration neu ein, ohne eine einzige Verbindung zu verlieren.
Vier Einstellungen sind anders — die Shared Buffers, das Verbindungslimit, die Worker-Prozesse und die Autovacuum-Worker werden erst übernommen, wenn PostgreSQL neu startet. Sie werden sofort gespeichert, und oben im Tab erscheint ein Hinweis, der genau benennt, welche noch warten. Diese Liste kommt von PostgreSQL selbst, nicht aus einer Liste in calmo.cloud, sie sagt dir also die Wahrheit und verschwindet von selbst, sobald der Neustart passiert ist.
Nichts startet neu, bevor du Restart PostgreSQL drückst und bestätigst.
calmo.cloud sagt dir außerdem, wenn die Einstellungen, mit denen PostgreSQL läuft, nicht mehr die sind, die es haben sollte — weil der Server vergrößert wurde oder weil ein Dienst hinzugefügt, geändert oder entfernt wurde. Dann erscheint ein Hinweis mit einem Button Apply now. Das wendet calmo.cloud nie von allein an: Eine Datenbank, die sich alle Dienste eines Servers teilen, konfiguriert man nicht hinter deinem Rücken um.
Startet PostgreSQL mit den vorgegebenen Einstellungen nicht, nimmt calmo.cloud die Einstellungen, die einen Neustart brauchen, wieder heraus, fährt die Datenbank mit dem Rest hoch und sagt dir, was es entfernt hat. Genau diese Werte werden erst wieder geschrieben, wenn du sie änderst, damit nichts zweimal gegen dieselbe Wand läuft — und alles andere, was du gesetzt hast, bleibt angewendet. Die abgelehnte Konfiguration liegt neben dem Datenverzeichnis als postgresql.auto.conf.havsh-failed.
Eine Datenbank, die nur langsam wiederkommt — eine große, die nach einem unsauberen Stopp ihr Write-Ahead-Log nachspielt — wird in Ruhe gelassen. calmo.cloud greift nur in die Konfiguration ein, wenn der Container wirklich down ist, und wartet, wenn er läuft, aber noch keine Verbindungen annimmt.
Datenbankverbindungen #
Ein Odoo-Prozess öffnet mehrere Datenbankverbindungen, und PostgreSQL nimmt insgesamt eine feste Anzahl an. Wer das falsch bemisst, bringt ein ausgelastetes System auf eine Weise zum Scheitern, die zufällig aussieht: Sobald das Limit erreicht ist, weisen Dienste Anfragen ab.
calmo.cloud bemisst das Verbindungslimit für die Odoo-Prozesse auf dem Server und hält 15 Verbindungen für Backups, Monitoring und eine Administratorin oder einen Administrator frei. Die Tabelle Database connections zeigt eine Zeile pro Dienst — Prozesse × Verbindungen pro Prozess — und sagt, ob das, was deine Dienste versprechen, hineinpasst.
Die andere Hälfte dieser Rechnung liegt bei jedem Odoo-Dienst: Das Feld Database connections in seinem eigenen Performance-Abschnitt ist ein Anteil am Limit des Servers. Der Anteil wird aus dem Limit berechnet, das PostgreSQL haben wird, sobald dieser Dienst existiert, sodass ein zweiter Dienst nie einen Anteil bekommt, der im Moment des Speicherns nicht mehr passt — bis du die Datenbank-Einstellungen anwendest, meldet der Budget-Block weiter, dass der Server überbucht ist, weil er es ist. Klickst du auf einem Dienst Use recommended values, ist der Wert, den du bekommst, genau dieser Anteil, und die Empfehlung für seine Speicherlimits ist das, was nach der Reservierung von PostgreSQL und nach den anderen Diensten auf demselben Server übrig bleibt.
Fügst du einen Dienst hinzu und es werden mehr Verbindungen versprochen, als PostgreSQL erlaubt, sagt der Budget-Block das, und ein erneutes Anwenden der Datenbank-Einstellungen hebt das Limit an.
Einstellungen, die calmo.cloud in Ruhe lässt #
calmo.cloud schreibt und leert nur die Einstellungen, die es verwaltet. Alles andere, was du selbst an der Datenbank einstellst, bleibt unangetastet.
Einige werden bewusst nie verwaltet: die vorgeladenen Bibliotheken und Huge Pages (ein falscher Wert dort kann den Start der Datenbank komplett verhindern), Zeitzone und Collation (Odoo geht von UTC aus, und die Collation wird beim ersten Anlegen des Datenverzeichnisses festgelegt) sowie Listen-Adresse und Port (sie gehören dazu, wie die Plattform die Datenbank erreicht).
Was was überlebt #
Die Einstellungen liegen im Datenverzeichnis der Datenbank und überleben daher das Neuerstellen des Containers, einen Server-Neustart und ein Redeploy. Sie überleben nicht den Neuaufbau des Datenverzeichnisses selbst — danach wendet calmo.cloud sie beim nächsten Datenbank-Deployment von allein wieder an.