PBS Backup Server 3.4.1 bei Hetzner SX65 Garbage Collect

[Priberius]

Moin,

wir nutzen über Hetzner mehrere Sx 65 Dedicated Server als Proxmox Backup Server.

Die Konfiguration ist so:

NVME 1 = Proxmox Backup Server Installation

4x22TB SATA Festplatten als ZFS Storage

2. NVME aufgeteit 50/50 für zfs cache / logs

Wir haben immer wieder das Problem das der Garbage Collect Job bis zu einer Woche plötzlich dauert.

Die Konfiguration der Server ist immer gleich.


Auf den Servern befindet sich ungefähr gleiche Datenmenge 30 VMS / Snapshost Sicherungen. Sicherungen werden 14 Tage behalten danach sollen Sie gelöscht werden.

Auf dem Einen Server dauert das Garbage über den den gesamten Storage 3,5 Stunden

auf einem anderen identischem plötzlich7 Tage

Das gleiche ist mir schon mal aufgefallen, und ich habe den Backup Server neu aufgesetzt, dann lief es mal 2-3 Monate und jetzt ist der gleiche "scheiss" schon wieder...

Hat jemand eine Idee ?

 

[Falk R.]

Das ist ganz normal. Beim PBS nutzt dir der Cache nicht wirklich etwas. Das einzige was dir wirklich helfen würde, wäre ein Special Device Mirror, diesen brauchst du aber, bevor du Daten drauf schreibst.
Was für NVMe sind denn in den SX65 verbaut?

 

[Chris]

Moin,

wir nutzen über Hetzner mehrere Sx 65 Dedicated Server als Proxmox Backup Server.

Die Konfiguration ist so:

NVME 1 = Proxmox Backup Server Installation

4x22TB SATA Festplatten als ZFS Storage

Welches HDD Model ist hier im Einsatz?

2. NVME aufgeteit 50/50 für zfs cache / logs

Wir haben immer wieder das Problem das der Garbage Collect Job bis zu einer Woche plötzlich dauert.

Die Konfiguration der Server ist immer gleich.

Was ist hier mit immer wieder gemeint? Ist die langsame GC reproduzierbar? Bitte task log von einem schnellen und einem langsamen GC task als anhang hier hochladen.

Auf den Servern befindet sich ungefähr gleiche Datenmenge 30 VMS / Snapshost Sicherungen. Sicherungen werden 14 Tage behalten danach sollen Sie gelöscht werden.

Auf dem Einen Server dauert das Garbage über den den gesamten Storage 3,5 Stunden

auf einem anderen identischem plötzlich7 Tage

Welche PBS version läuft auf welchem server? Gibt es Unterschiede im Storage Layout und/oder Hardware?

Das gleiche ist mir schon mal aufgefallen, und ich habe den Backup Server neu aufgesetzt, dann lief es mal 2-3 Monate und jetzt ist der gleiche "scheiss" schon wieder...

Welche PBS version wurde zum neu aufsetzen verwendet? Korreliert das auftreten der langsamen GC mit einem upgrade?

Hat jemand eine Idee ?

Es gibt ein paar vereinzelte User reports hierzu [0], leider konnten wir das verhalten jedoch nicht nachvollziehen. Bitte um eine strace (zumindest über ein paar Stunden mit langsamer GC) wie hier [1] beschrieben generieren. Auch den output von arc_summary posten.

[0] https://forum.proxmox.com/threads/gc-very-slow-after-3-4-update.166214/
[1] https://forum.proxmox.com/threads/gc-very-slow-after-3-4-update.166214/post-772461

 

[Priberius]

Welches HDD Model ist hier im Einsatz?



Was ist hier mit immer wieder gemeint? Ist die langsame GC reproduzierbar? Bitte task log von einem schnellen und einem langsamen GC task als anhang hier hochladen.



Welche PBS version läuft auf welchem server? Gibt es Unterschiede im Storage Layout und/oder Hardware?



Welche PBS version wurde zum neu aufsetzen verwendet? Korreliert das auftreten der langsamen GC mit einem upgrade?



Es gibt ein paar vereinzelte User reports hierzu [0], leider konnten wir das verhalten jedoch nicht nachvollziehen. Bitte um eine strace (zumindest über ein paar Stunden mit langsamer GC) wie hier [1] beschrieben generieren. Auch den output von arc_summary posten.

[0] https://forum.proxmox.com/threads/gc-very-slow-after-3-4-update.166214/
[1] https://forum.proxmox.com/threads/gc-very-slow-after-3-4-update.166214/post-772461

1. Welches HDD Model ist hier im Einsatz? TOSHIBA_MG1AFA22TEY

2. Ja auf dem Server "ersten" Server ist das jetzt dauerhaft so.

3.Welche PBS version läuft auf welchem server? Gibt es Unterschiede im Storage Layout und/oder Hardware?
3.4.1 Nein.

4.Welche PBS version wurde zum neu aufsetzen verwendet? Korreliert das auftreten der langsamen GC mit einem upgrade?
Version 3.4 das kann sein, aber die Versionsstände sind auf beiden gleich. Genauso wie die Hardware 1:1 dann


Das einzige was mir noch einfällt und das war vor dem Neuaufsetzen genauso.... Ich habe am Tag zuvor während Backup Jobs liefen diese abgebrochen... Das waren Snapshots .... Seitdem ist das.... Und zwar beide male. Das kann jetzt Zufall sein, aber das ist der einzige Zusammenhang den ich herstellen kann...

Vielen Dank schonmal.

 

[Priberius]

Das ist ganz normal. Beim PBS nutzt dir der Cache nicht wirklich etwas. Das einzige was dir wirklich helfen würde, wäre ein Special Device Mirror, diesen brauchst du aber, bevor du Daten drauf schreibst.
Was für NVMe sind denn in den SX65 verbaut?

Moin,
danke für deine Antwort.


2 Stück Samsung MZVLB1T0HBLR-00000 sind verbaut.

Grüße

 

[Chris]

1. Welches HDD Model ist hier im Einsatz? TOSHIBA_MG1AFA22TEY

2. Ja auf dem Server "ersten" Server ist das jetzt dauerhaft so.

3.Welche PBS version läuft auf welchem server? Gibt es Unterschiede im Storage Layout und/oder Hardware?
3.4.1 Nein.

4.Welche PBS version wurde zum neu aufsetzen verwendet? Korreliert das auftreten der langsamen GC mit einem upgrade?
Version 3.4 das kann sein, aber die Versionsstände sind auf beiden gleich. Genauso wie die Hardware 1:1 dann


Das einzige was mir noch einfällt und das war vor dem Neuaufsetzen genauso.... Ich habe am Tag zuvor während Backup Jobs liefen diese abgebrochen... Das waren Snapshots .... Seitdem ist das.... Und zwar beide male. Das kann jetzt Zufall sein, aber das ist der einzige Zusammenhang den ich herstellen kann...

Vielen Dank schonmal.

Bitte auch um den strace output generieren wie oben verlinkt!

Des weiteren wäre von Interesse wäre zu sehen wie lange ein group list in den namespace in etwa braucht, welches über alle snapshots in der Gruppe iterieren muss benötigt.

Dazu ein time proxmox-backup-debug api get /admin/datastore/{datastore}/groups --ns <namespace> in all den namespace ausführen... sowie den root namespace ohne --ns parameter.

Zuletzt auch versuchen die letzte Version 3.4.2-1 im pbstest repo zu installieren, welche ein paar kleine Optimierungen in der group und snapshot Iterator Logik mit sich bringt.

Edit: Auch ein arcstat -a -o arcstat.txt 10 für ein paar Minuten von beiden PBS instanzen während laufender GC wäre von Interesse.

 

[Falk R.]

Moin,
danke für deine Antwort.


2 Stück Samsung MZVLB1T0HBLR-00000 sind verbaut.

Grüße

Das sind Consumer Grade SSDs ohne PLP und mit den Werten nicht wirklich als Special Device zu empfehlen.
Aus dem Hardwaresetup kannst du somit nicht viel raus holen. Eventuell kann Chris dir helfen, mit der Software noch etwas auf der lahmen Hardware heraus zu holen.

 

[Chris]

Das einzige was mir noch einfällt und das war vor dem Neuaufsetzen genauso.... Ich habe am Tag zuvor während Backup Jobs liefen diese abgebrochen... Das waren Snapshots .... Seitdem ist das.... Und zwar beide male. Das kann jetzt Zufall sein, aber das ist der einzige Zusammenhang den ich herstellen kann...

Vielen Dank schonmal.

Was in den arc summary logs noch auffällt ist der massive dnode cache bloat. Falls möglich den PBS rebooten und checken ob es etwas damit auf sich hat und das GC runtime issue weiter besteht. Oder PBS services stoppen, zpool exportieren und wieder inportieren, services wieder starten, das gibt auch den ARC wider frei.

Eventuell auch das arc max limit etwas anheben was bessere IO Performance bieten kann, für PVE empfehlen wir z.B. folgendes ARC max limit https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_zfs_limit_memory_usage

Und wie @Falk R. schon richtig angemerkt hat, ein ZFS special device ist sehr zu empfehlen.