Ich habe einen Proxmox-Cluster mit einem einzelnen Knoten und möchte eine neue VM mit PostgreSQL und TimescaleDB starten. Nachdem ich viel darüber gelesen habe, wie man ZFS-Volumes für diesen Zweck optimiert, habe ich immer noch Zweifel bezüglich der Cache-Optionen. Wir haben 3 Caches: Den Proxmox-Cache (ARC), den Linux-VM-Cache (LRU) und den PostgreSQL-Cache (Clock Sweep); in der Reihenfolge von weiter entfernt nach näher an den DBs.
Ich habe viele Informationen gelesen, einige davon widersprüchlich, also weiß ich nicht, ob das stimmt, aber es scheint, dass der PG-Cache nicht auf die gleiche Weise wie ein Kernel-Cache konzipiert ist, der versucht, alles aufzufangen und nur zu löschen, wenn nicht genug Platz zum Weiterspeichern vorhanden ist. Tatsächlich scheint es eher ein Puffer für die Daten zu sein, die gerade verarbeitet werden, und kein Langzeit-Cache. Tatsächlich wird er als Shared Buffer bezeichnet. Ich vermute, das ist der Grund, warum das Dokument nicht empfiehlt, Shared Buffers auf einen hohen Prozentsatz des verfügbaren RAM einzustellen, wie es ARC tut, sondern irgendwo zwischen 25 und 50 %. Es scheint, dass der echte PG-Cache der Kernel-Cache ist und nicht Shared Buffers.
Unter Berücksichtigung dieser Tatsache sind einige mögliche Konfigurationen zu berücksichtigen:
- Erstellen Sie eine VM mit einer moderaten Menge an RAM (sagen wir 12 GB) und setzen Sie shared_buffers auf 10 GB. Versuchen Sie Folgendes: 1) Sorgen Sie für ausreichend Speicher, der als Puffer für laufende Abfragen dient. 2) Reduzieren Sie den RAM der VM, damit sie ihren Cache nicht verwendet, der mit seiner LRU-Konfiguration der schlechteste sein sollte, und verwenden Sie stattdessen einen ARC-Cache mit besseren Gewichten. Das Problem bei dieser Konfiguration kann darin liegen, dass sich der Cache außerhalb der VM befindet und die Leistung verringern könnte, anstatt sie zu verbessern. Ich bin mir auch nicht sicher, wie viel Platz ich über die Größe der shared_buffers hinaus übrig habe, um das VM-Betriebssystem und die anderen DB-Prozesse laufen zu lassen.
- Erstellen Sie eine VM mit viel RAM (sagen wir 48 GB) und halten Sie die Shared_Buffer bei denselben 10 GB. Außerdem legt ZFS den primären Cache auf Metadaten fest. Auf diese Weise ist der Cache näher an der Datenbank und innerhalb der VM, allerdings mit einer schlechteren Logik. Es scheint, dass LRU für die Datenbank ziemlich schlecht ist.
- Erstellen Sie eine VM mit viel RAM und primarycache=all. Ich denke, das ist schlecht, weil: 1) VM- und Proxmox-Caches um Ressourcen konkurrieren. 2) Cache-Duplizierung.
Um einen Kontext zu geben: Der Knoten verfügt über insgesamt 64 GB RAM und PG/TimescaleDB ist die anspruchsvollere/prioritärere Anwendung, die darauf ausgeführt wird.
Sind meine anfänglichen Annahmen also richtig? Welche Konfiguration wird besser funktionieren? Was würden Sie ändern?
Freundliche Grüße und vielen Dank für Ihre Zeit,
Tyrannisieren
Antwort1
Ich empfehle Lösung Nr. 4: Erstellen Sie eine VM mit viel RAM und verwenden Sie diese auf der KVM-Seite (Proxmox) cache=nonefür die Datenfestplatte. Dadurch wird Proxmox daran gehindert, den Host-Seitencache überhaupt zu verwenden, wodurch die eigentliche Speichersynchronisierung effektiv ausgeführt wird. Auf diese Weise kommen Sie in Ihrer VM so nah wie möglich an Bare Metal heran und können Ihre Caches dort feinabstimmen.
Beachten Sie, dass bei allen mir bekannten Datenbanken (einschließlich PostgreSQL) der RAM-Puffer nicht nur ein Festplattencache ist, sondern zumindest einen Teil der Daten in einem lesebereiten Format speichert, das nicht dem Festplattenformat entspricht. Dies bedeutet, dass für den DB-Prozess reservierter RAM wertvoller ist als RAM, der nur als E/A-Puffer verwendet wird.
Wenn Ihre Datenbank eine Abfrage aus (ihrem eigenen) RAM beantworten kann, wird sie überhaupt nicht durch den IO-Stapel ausgeführt, was die Latenzzeit enorm verkürzt.