ZFS cache nachträglich einrichten...

[jedie]

Ich hab ein kleinen proxmox server im lokalen Netz laufen... Ist ein 8 Kern Xeon und einer 128GB SSD für das System und einer 3TB HDD für Daten.

Ich hab immer relative Hohe Load Werte, offenbar vorwiegend wegen ZFS IO. Die IO delay Anzeige schlägt auch immer ganz gut aus...

Erst dachte ich, das 16GB RAM ein wenig knapp sind. Deswegen hab ich es kürzlich auf 32GB erhöht. Aber viel gebracht hat es nicht.

Beim schreiben auf Platte kann ich in iotop den Prozess "z_wr_iss" sehen, der viel IO macht...


Ich möchte nun eine zusätzliche SSD für ZFS cache einbauen. Hab ich Auswahl, ob es eine 512GB oder eine 1TB sein soll... Bringt mehr auch mehr? Also merkt man den unterschied zwischen 512GB und 1TB? oder wäre 1TB übertrieben bei nur 3TB Daten?

Unter https://pve.proxmox.com/wiki/ZFS_on_Linux bei "Add cache and log to an existing pool" steht das man zwei GPT Partitionen für ZIL (log) und L2ARC (cache) einrichten soll...
Welche Aufteilung ist Sinnvoll? 50 / 50 ? oder für log weniger als für cache?!?

EDIT: Nach ein wenig suche, hab ich Aussagen gefunden, das 8GB für ZIL (log) vollkommen ausreichend ist... Stimmt das?

 

[Dunuin]

Erstmal sollte gesagt werden, dass da SSDs fürs Caching meist nicht viel bringen und Consumer SSDs sehr schnell kaputtgeschrieben sein können.

L2ARC bringt nichts solange dein RAM nicht voll ist. Und ist dein RAM voll solltest du mehr RAM kaufen anstatt eine SSD für L2ARC, sofern da mehr RAM in den Rechner passt.
SLOG bringt Null bei normalen Async Writes. Das ist nur für Sync Writes, also eher etwas, wenn du viele Datenbanken betreibst. Auch kann der SLOG nicht mehr als 1/4 (oder war es 1/8?) der Größe des RAMs sein, also nur 8GB nutzbar. Da kann aber trotzdem eine große SSD Sinn machen, weil die dann nicht so schnell kaputtgeschrieben ist.
Special Device für Metadaten kann etwas bringen, aber wenn die ausfällt sind auch alle Daten auf den HDDs weg.

Wenn du SLOG und L2ARC gemeinsam auf eine SSD packst, dann bremsen die sich gegenseitig aus.

Wenn die HDDs zu langsam sind bringt da Cachen meist nicht viel. Lieber gleich die HDDs rauswerfen und durch SSDs ersetzen. Oder wenigstens die VMs von SSDs laufen lassen und die HDDs dann nur noch per NFS/SMB als Datengrab nutzen.

 

[jedie]

Hm... Ich sag mal so, der Wechsel von 16GB auf 32GB hat nicht besondert viel gebracht.
Das Mainboard vom ProLiant ML10 v2 hat nur 4 RAM sockel, die mit 4x8GB DDR3 ECC Riegel gefüllt sind. Größere "unregistred" Module finde ich nicht und sind vermutlich recht teuer... Also mehr RAM geht nicht so einfach...

Ich kopiere gerade 1,8GB Bilder per NFS über Gigabit Lan auf den Rechner. Es sind im Schnitt gerade mal 1,8MB/Sek.
Beim lesen z.B. von größeren ISO Dateien komme ich auf ca. 26MB/Sek. Das ist ja ganz okay...

Der NFS Export ist direkt vom proxmox host system gemacht.

RAM Auslastung dabei bei ca. 22GB ... Load bei 2.35... CPU dreht fast Däumchen.

Die 3TB Platte ist mit ca. 1,5TB voll... Wenn ich mir die SSD Preise ansehe muss ich min. 170€ hinlegen für ein 2TB Modell... Das wäre vielleicht echt eine Überlegung Wert...

Auf der anderen Seite kann es doch irgendwie nicht sein, das das schreiben so langsam ist... Wie sieht das wohl aus, wenn ich statt ZFS einfach btrfs nehmen würde? (Wobei: Geht proxmox überhaupt auf btfs?!? Nach https://pve.proxmox.com/wiki/Roadmap zu urteilen ist das noch nicht fertig, oder?)

 

[jedie]

Hab gerade https://pbs.proxmox.com/docs/sysadmin.html#add-cache-and-log-to-an-existing-pool gefunden:

The maximum size of a log device should be about half the size of physical memory, so this is usually quite small. The rest of the SSD can be used as cache.

Ich gehe mal davon aus, das mit "physical memory" das RAM gemeint ist oder?

Erstmal sollte gesagt werden, dass da SSDs fürs Caching meist nicht viel bringen und Consumer SSDs sehr schnell kaputtgeschrieben sein können.

Mir fällt gerade ein: Sollte ich die 3TB HDD mit einer SSD tauschen, wird das auch nur eine Consumer SSD sein. Von daher ist das mit dem kaputtschreiben so oder so ein Problem Wobei die c't ja auch gezeigt hatte das da doch eine Menge geht. Wobei das auch schon wieder eine weile lang her ist...

Das Caching kann ich jetzt einfach so mal probieren, ohne das es ein großer Aufwand wäre. Die HDD mit SSD tauschen ist da schon deutlich Aufwendiger...

EDIT: Gerade verschiebe ich ein paar GB direkt auf dem host. Da ist der Durchsatz auch nicht berauschen. Offenbar ist schreiben halt generell nie schneller als ~6MB/s

root@pve:~# zpool list
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
hdd_pool1  2,72T  1,35T  1,37T        -         -    43%    49%  1.15x    ONLINE  -
rpool       119G  10,2G   109G        -         -    60%     8%  1.06x    ONLINE  -

root@pve:~# lsblk -o NAME,PHY-SeC
NAME     PHY-SEC
sda          512
├─sda1       512
├─sda2       512
└─sda9       512
sdb         4096
├─sdb1      4096
└─sdb9      4096
zd0         4096
zd16        8192
├─zd16p1    8192
└─zd16p2    8192
zd32        8192
zd48        8192
├─zd48p1    8192
├─zd48p2    8192
└─zd48p5    8192

 

[Dunuin]

Du hast Deduplikation aktiviert. Das kann extrem ausbremsen und frisst richtig RAM. Faustformel ist 4GB + 5GB RAM pro 1TB Rohkapazität bei aktivierter Deduplikation. Da müsstest du ja schon mindestens 19GB vom RAM als ARC nehmen. Ohne Deduplikation wären das nur 4GB + 1GB RAM pro 1TB Rohkapazität und 7GB RAM würde für den ARC schon reichen. Wenn du Proxmox damals mit nur 16GB RAM installiert hast, dann sollte dein ARC auf 8GB limitiert sein, falls du das nicht nachher manuell umgestellt hast (Eintrag in der /etc/modprobe.d/zfs.conf). Ich würde das ARC Limit mal erhöhen oder die Deduplikation deaktivieren und gucken wie die Schreibrate dann ist.
Deine Fragmentierung ist mit 43% auch recht hoch was auch ausbremsen kann. Bei mir auf dem FreeNAS mit raidz1 bei 4 HDDs (75% gefüllt) habe ich z.B. nur eine Fragmentierung von 4%. Da muss der Schreibkopf in den HDDs dann wesentlich weniger hin- und herspringen wenn eine Datei nicht quer über die ganze Festplatte verteilt ist.

 

[jedie]

Wenn du Proxmox damals mit nur 16GB RAM installiert hast, dann sollte dein ARC auf 8GB limitiert sein, falls du das nicht nachher manuell umgestellt hast (Eintrag in der /etc/modprobe.d/zfs.conf). Ich würde das ARC Limit mal erhöhen

Das stimmt. es gibt aber keine /etc/modprobe.d/zfs.conf:

root@pve:~# ls -la /etc/modprobe.d/
insgesamt 14
drwxr-xr-x   2 root root   3 Dez 17 09:33 .
drwxr-xr-x 109 root root 213 Dez 17 09:33 ..
-rw-r--r--   1 root root 171 Apr 26  2016 pve-blacklist.conf

Allerdings scheint mir der ARC eh dynamisch zu sein, hat aktuell 10GB:

root@pve:~# arc_summary

------------------------------------------------------------------------
ZFS Subsystem Report                            Fri Jan 01 12:08:03 2021
Linux 5.4.78-2-pve                                            0.8.5-pve1
Machine: pve (x86_64)                                         0.8.5-pve1

ARC status:                                                      HEALTHY
        Memory throttle count:                                         0

ARC size (current):                                    67.7 %   10.6 GiB
        Target size (adaptive):                        68.8 %   10.8 GiB
        Min size (hard limit):                         6.2 %  1002.1 MiB
        Max size (high water):                           16:1   15.7 GiB
        Most Frequently Used (MFU) cache size:         31.1 %    2.9 GiB
        Most Recently Used (MRU) cache size:           68.9 %    6.5 GiB
        Metadata cache size (hard limit):              75.0 %   11.7 GiB
        Metadata cache size (current):                 25.2 %    3.0 GiB
        Dnode cache size (hard limit):                 10.0 %    1.2 GiB
        Dnode cache size (current):                    46.9 %  564.1 MiB

ARC hash breakdown:
        Elements max:                                             910.2k
        Elements current:                              37.5 %     341.7k
        Collisions:                                                 9.7M
        Chain max:                                                     6
        Chains:                                                    13.2k

ARC misc:
        Deleted:                                                    3.8M
        Mutex misses:                                                156
        Eviction skips:                                              271

ARC total accesses (hits + misses):                               222.9M
        Cache hit ratio:                               97.6 %     217.4M
        Cache miss ratio:                               2.4 %       5.5M
        Actual hit ratio (MFU + MRU hits):             97.4 %     217.0M
        Data demand efficiency:                        99.2 %      51.4M
        Data prefetch efficiency:                      12.2 %       3.2M

Cache hits by cache type:
        Most frequently used (MFU):                    69.6 %     151.2M
        Most recently used (MRU):                      30.2 %      65.8M
        Most frequently used (MFU) ghost:               0.2 %     347.2k
        Most recently used (MRU) ghost:                 0.5 %       1.2M

Cache hits by data type:
        Demand data:                                   23.5 %      51.0M
        Demand prefetch data:                           0.2 %     393.1k
        Demand metadata:                               76.2 %     165.6M
        Demand prefetch metadata:                       0.2 %     402.0k

Cache misses by data type:
        Demand data:                                    7.6 %     415.3k
        Demand prefetch data:                          52.1 %       2.8M
        Demand metadata:                               38.9 %       2.1M
        Demand prefetch metadata:                       1.4 %      76.4k

DMU prefetch efficiency:                                          110.2M
        Hit ratio:                                      4.6 %       5.0M
        Miss ratio:                                    95.4 %     105.1M

L2ARC not detected, skipping section

Solaris Porting Layer (SPL):
        spl_hostid                                                     0
        spl_hostid_path                                      /etc/hostid
        spl_kmem_alloc_max                                       1048576
        spl_kmem_alloc_warn                                        65536
        spl_kmem_cache_expire                                          2
        spl_kmem_cache_kmem_limit                                   2048
        spl_kmem_cache_kmem_threads                                    4
        spl_kmem_cache_magazine_size                                   0
        spl_kmem_cache_max_size                                       32
        spl_kmem_cache_obj_per_slab                                    8
        spl_kmem_cache_obj_per_slab_min                                1
        spl_kmem_cache_reclaim                                         0
        spl_kmem_cache_slab_limit                                  16384
        spl_max_show_tasks                                           512
        spl_panic_halt                                                 0
        spl_schedule_hrtimeout_slack_us                                0
        spl_taskq_kick                                                 0
        spl_taskq_thread_bind                                          0
        spl_taskq_thread_dynamic                                       1
        spl_taskq_thread_priority                                      1
        spl_taskq_thread_sequential                                    4

...

 

[jedie]

Hab gerade https://www.admin-magazine.com/HPC/Articles/Tuning-ZFS-for-Speed-on-Linux gefunden... Da ist beschrieben das man eine /etc/modprobe.d/zfs.conf selbst anlegen kann um damit die ARC größe per zfs_arc_max zu beeinflussen. Erscheint mit aber wenig hilfreich.

Da ist allerdings auf Seite 2 und 3 beschrieben, das der Level 2 ARC (L2ARC) ein "read cache" ist und der ZFS Intent Log (ZIL) quasi ein write cache ist...

Mit dem lesen hab ich ja weniger ein Problem. Ob ein ZIL cache auf einer separaten SSD was bringt, wenn der Flaschenhals die "dedup info" ist, der nicht in's RAM passt?

Und eine Frage noch: Wenn man einen L2ARC und ZIL auf einer SSD packt. Kann man den auch wieder einfach deaktivieren? Btw. was passiert, wenn die SSD defekt ist?

 

[Dunuin]

Wenn du den ARC Limit nicht selbst setzt nutzt Proxmox halt 50% vom RAM dafür, daher dein "Max size (high water): 16:1 15.7 GiB".
Ich würde wirklich mal Deduplikation deaktivieren und gucken wie es dann läuft. Einsparen tut das bei dir ja auch nur 15% von der Kapazität und dafür sorgt es für Verlangsamung und kann auch mit der Grund dafür sein, warum deine HDD so fragmentiert ist.
Mit einer Hitrate von 97% kannst du dir den L2ARC echt sparen. Der kann sogar alles langsamer machen, weil dann halt von der langsamen SSD und nicht vom schnellen RAM gelesen wird.

Und ZIL/SLOG wird halt wirklich NUR für Sync Writes benutzt. Musst du gucken ob du da überhaupt Sync Writes benutzt. NFS sollte im Normalfall z.B. Async Writes machen, da wird das auch keinen Tick schneller wenn du den ZIL auf eine SSD legst.

Wenn die SSD ausfällt ist das beim SLOG/ZIL erst einmal nicht mehr so das Problem. Sollte aber zeitgleich auch ein Stromausfall stattfinden, dann ist dein ganzer Pool zerschossen. Wenn man auf Nummer sicher gehen will sollte man auch das SLOG als Mirror anlegen.

SLOG und L2ARC kannst du problemlos wieder später vom Pool entfernen.

 

[JohnD]

Dedup ist sehr wahrscheinlich dein Problem.
Exportiere die Daten, lösche den Pool und lege den neu an (ohne Dedup) und spiele dein Backup wieder ein.
Bei deiner Dedup Ratio ist die Funktion sowieso völlig sinnlos (kostet nur viel Leistung).

 

[jedie]

Okay... Geht nur über Pool neu erstellen?

EDIT: offenbar nicht: https://mschwaig.github.io/2017/01/...plication-while-adding-a-mirror-to-a-zfs-pool

 

[JohnD]

Stimmt. Dedup ist auf Dataset level.
Deaktiviere Dedup für den ganzen Pool, kopiere die Daten via ZFS Send auf ein temporäres dataset und lösche das original.
Dann das neue Dataset umbenennen damit es wie das alte heißt und proxmox nicht verwirrt ist.

 

[jedie]

Also ich hab mir jetzt zwei 2TB SSDs angeschafft, will darauf ein RAID1 machen und das ganze dann ohne dedup...

Wie sollte ich das RAID machen? Mit mdadm nicht, oder?

 

[JohnD]

Einfach einen zfs mirror pool anlegen. Mdadm stört da nur .

 

[jedie]

Ja, sowas hab ich mir schon fast gedacht... Wo finde ich nähere Informationen zur Vorgehensweise?

 

[jedie]

Hab mal einfach zpool create ssd mirror /dev/sdd /dev/sdc gemacht und zack er ist da...

root@pve:~# zpool list
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
hdd_pool1  2,72T  1,62T  1,09T        -         -    45%    59%  1.14x    ONLINE  -
rpool       119G  13,1G   106G        -         -    60%    10%  1.06x    ONLINE  -
ssd        1,81T   117K  1,81T        -         -     0%     0%  1.00x    ONLINE  -

Aber wie bekomme ich jetzt die Daten rüber? PVE komplett runterfahren?!?

 

[jedie]

Im laufenden Betrieb weigert sich "zfs send" auf die gemountete Partition zu zu greifen.
Hab im grub menü die rescue Einträge aktiviert und versuche es im rescue modus.

EDIT2:

So scheint es zu funktionieren:

root@pve:~# zpool import hdd_pool1
root@pve:~# zpool import ssd
root@pve:~# zfs snapshot -r hdd_pool1@snapshot20210202
root@pve:~# zfs send hdd_pool1@snapshot20210202 | pv | zfs recv -dvF ssd
root@pve:~# zpool export hdd_pool1
root@pve:~# zpool export ssd
root@pve:~# zpool import ssd hdd_pool1
root@pve:~# zpool import hdd_pool1 hdd_pool1old

Ist das dann auch korrekt umbenannt? Also nach reboot?

 

[jedie]

So, alles kopiert und neu gestartet. Sieht gut aus, einige VMs/Cointainer laufen so wie immer... Doch einer nicht:

TASK ERROR: zfs error: cannot open 'hdd_pool1/subvol-107-disk-2': dataset does not exist

Das ist doch merkwürdig, oder?

Auf dem neuen SSD mirror ist das auch nicht drauf.

Hab nochmal die alte Platte rein gemacht, da ist es noch drauf:

root@pve:~# zfs list -t snapshot
NAME                                                USED  AVAIL     REFER  MOUNTPOINT
hdd_pool1@snapshot20210202                           14K      -       26K  -
hdd_pool1/rpoolbackup20160531@snapshot20160531       14K      -       23K  -
hdd_pool1/rpoolbackup20160531@snapshot20210202        0B      -       23K  -
hdd_pool1/subvol-100-disk-2@snapshot20210202        189M      -     1,52T  -
hdd_pool1/subvol-103-disk-1@snapshot20210202       1,76G      -     3,45G  -
hdd_pool1/subvol-104-disk-0@snapshot20210202          0B      -      229M  -
hdd_pool1/subvol-104-disk-1@snapshot20210202          0B      -      549M  -
hdd_pool1/subvol-104-disk-2@snapshot20210202       9,78M      -      638M  -
hdd_pool1/subvol-105-disk-0@snapshot20210202       16,1M      -      612M  -
hdd_pool1/subvol-108-disk-0@frisch                 47,4M      -      381M  -
hdd_pool1/subvol-108-disk-0@snapshot20210202          0B      -     1,40G  -
hdd_pool1/vm-107-disk-0@snapshot20210202              0B      -     1,08G  -
hdd_pool1old@snapshot20210202                         8K      -      112K  -
hdd_pool1old/rpoolbackup20160531@snapshot20160531    72K      -       96K  -
hdd_pool1old/rpoolbackup20160531@snapshot20210202     0B      -       96K  -
hdd_pool1old/subvol-100-disk-2@snapshot20210202       8K      -     1,53T  -
hdd_pool1old/subvol-103-disk-1@snapshot20210202       8K      -     3,58G  -
hdd_pool1old/subvol-104-disk-0@snapshot20210202       0B      -      295M  -
hdd_pool1old/subvol-104-disk-1@snapshot20210202       8K      -      708M  -
hdd_pool1old/subvol-104-disk-2@snapshot20210202       8K      -      709M  -
hdd_pool1old/subvol-105-disk-0@snapshot20210202       8K      -      681M  -
hdd_pool1old/subvol-107-disk-2@snapshot20210202     144K      -      278G  -
hdd_pool1old/subvol-108-disk-0@frisch              55,2M      -      441M  -
hdd_pool1old/subvol-108-disk-0@snapshot20210202       8K      -     1,62G  -
hdd_pool1old/vm-107-disk-0@snapshot20210202           8K      -     1,35G  -
hdd_pool1old/vm-107-disk-1@snapshot20210202           0B      -       56K  -
rpool@snapshot20160531                                0B      -       96K  -

Warum wurde hdd_pool1old/subvol-107-disk-2 mit zfs send nicht auch kopiert?!?

Ich mache nun folgendes:

zfs send hdd_pool1old/subvol-107-disk-2@snapshot20210202 | pv | zfs recv -dvF hdd_pool1

 

[jedie]

Ah!

cannot receive new filesystem stream: out of space

Deswegen fehlt es. Verdammt.