Monat: Dezember 2021

bonnie++ performance Disk IO-Werte unter FreeBSD mit zfs

Hier mal ein paar performance Messungen unter FreeBSD. Messungen sind ja alle sehr relativ, der eine mag das Andere, ich mag bonnie.
Die Messungen fanden statt auf einem i5-6600, 32GB Ram und FreeBSD 12.2, bonnie++1,98. Filesystem ist ZFS. Der Cache ist 29GB groß, das ZIL 1GB.

Samsung SSD 950 PRO 512GB

bonnie benchmark Samsung SSD 950Pro
Die 950PRO dient auch als cache und ZILs für einen Raid1 und einen Raid5-zpool

Die 950 Pro wurde abgelöst – durch eine SanDisk Extreme Pro 1TB. Sie dürfte baugleich mit der WD Black Series sein, WD kaufte SanDisk vor längerem.
Die performance Messungen fanden unter FreeBSD 13-Release statt.

SanDisk Extreme Pro 1TB

SanDisk Extreme Pro 1TB mit cache für zRaid unter FreeBSD 13.R

Raid1 mit 2x Seagate Barracuda 4TB

Bei der initialen Erstellung meines Raid1 bestehend aus 2 Seagate 4TB Festplatten des Typs ST4000DM004 hatte ich einfach den zpool create mit den raw-devices verwendet – und damit das sector 63 Problem:

2x4GB false sec63
raid1 mit cache und log (L2ARC - 29GB, logs 1GB beides auf nvme)
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1        64G  287k  99 10.4m   1 8373k   1  720k  99  2.7g  99 200.0   4
Latency             29770us      437s      430s   14303us     391us     859ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1            -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 165.746758   0 +++++ +++ +++++ +++ 566.048702   1
Latency             28743us      41us   54405ms    1516us      20us    5952ms

Dann habe ich das sector 63 Problem behoben:

gpart show ada3
=>        40  7814037088  ada3  GPT  (3.6T)
          40        2008        - free -  (1.0M)
        2048  7814033408     1  freebsd-zfs  (3.6T)
  7814035456        1672        - free -  (836K)

gpart show ada5
=>        40  7814037088  ada5  GPT  (3.6T)
          40        2008        - free -  (1.0M)
        2048  7814033408     1  freebsd-zfs  (3.6T)
  7814035456        1672        - free -  (836K)

Danach interessiert man sich dafür, wofür man sich die Arbeit gemacht hat und macht mal ein paar performance Messungen, angefangen mit einer Single-disk, über Zuschaltung von cache und zuletzt dem ZIL (log):

single disk, mit zfs 
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1-single 64G  306k  98  105m   7 30.1m   2  727k  98  179m   6 145.7   1
Latency             28417us   38531us    1541ms   45365us     173ms     478ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1-single     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 4154.577626   8 +++++ +++ +++++ +++ 3948.968091   7
Latency              1598us      36us     967ms    1535us      24us     468ms


raid1 - "naggisch"
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1        64G  299k  97 76.8m   6 40.8m   3  702k  96  232m   8 220.6   2
Latency             28550us   38345us     861ms   68444us     175ms     325ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1            -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 4145.272690   8 +++++ +++ +++++ +++ 3683.089828   7
Latency              1502us      30us     899ms    1463us      83us     441ms


raid1 mit cache (L2ARC - auf 29GB nvme)
[root@alpina /raid1]# bonnie++ -r 32768 -m alpinaR1_cache -u root
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1_cache  64G  230k  89 68.9m   5 39.8m   3  720k  99  235m   8 241.0   3
Latency             33220us    7303ms     623ms   29652us     269ms     341ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1_cache      -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 2690.164896   5 +++++ +++ +++++ +++ 4142.792682   8
Latency              1511us      37us    2925ms    1473us      25us     558ms


raid1 mit cache und log (L2ARC - 29GB, logs 1GB beides auf nvme)
[root@alpina /raid1]# bonnie++ -r 32768 -m alpinaR1_cache_log -u root
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1_cache_ 64G  258k  99 78.9m   6 46.4m   4  700k  96  229m   8 229.2   2
Latency             33061us    7278ms     567ms     103ms     196ms     391ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1_cache_log  -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 3669.165249   7 +++++ +++ +++++ +++ 3656.157708   7
Latency              1560us      36us    1601ms    1470us      26us     580ms

und hier nochmal das listing im direkten Vergleich:

single disk, mit zfs im Vergleich zur Raid1 config
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1-single 64G  306k  98  105m   7 30.1m   2  727k  98  179m   6 145.7   1
Latency             28417us   38531us    1541ms   45365us     173ms     478ms
alpinaR1_cache_log   258k  99 78.9m   6 46.4m   4  700k  96  229m   8 229.2   2
Latency             33061us    7278ms     567ms     103ms     196ms     391ms

Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1-single     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 4154.577626   8 +++++ +++ +++++ +++ 3948.9680 7
Latency              1598us      36us     967ms    1535us      24us     468ms
alpinaR1_cache_log   /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 3669.165249   7 +++++ +++ +++++ +++ 3656.1577 7
Latency              1560us      36us    1601ms    1470us      26us     580ms



2x4GB Raid1 mit false sec63 im Vergleich zur "bereinigten" config:

Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1-sec63       287k  99 10.4m   1 8373k   1  720k  99  2.7g  99 200.0   4
Latency             29770us      437s      430s   14303us     391us     859ms
alpinaR1_new         258k  99 78.9m   6 46.4m   4  700k  96  229m   8 229.2   2
Latency             33061us    7278ms     567ms     103ms     196ms     391ms

Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1-sec63      -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 165.746758   0 +++++ +++ +++++ +++ 566.048702 1
Latency             28743us      41us   54405ms    1516us      20us    5952ms
alpinaR1_new         /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 3669.165249   7 +++++ +++ +++++ +++ 3656.1577 7
Latency              1560us      36us    1601ms    1470us      26us     580ms

Interessant empfinde ich, daß ein Spiegel unter dem Strich erkennbar schlechtere Werte liefern kann, als die Single-disk – ausgenommen beim seq-output rewrite und seq-input-block.
Ansonsten ist der Vergleich zwischen alter RAID1 und neuer ganz passabel – man sieht deutlich schlechtere Werte in der alten RAID1-config:
seq. output Block 10MB/s zu 78MB/s,
rewrite 8k3 zu 46m,
seq Input Block 2.7g zu 229m??? ein schlechterer Wert dafür mit wesentlich weniger Last
random seeks
und allgemein weniger CPU-Last… und vor allem sieht man wesentlich geringere Latenzen -> hat sich also meiner Meinung nach gelohnt, also wird irgendwann später das Raid5 auch umgestellt!

Raid5 mit 4x Seagate IronWolf 6TB

Leider hatte ich auch bei der initialen Erstellung meines raidz1 Volumes (Raid5) aus 4x 6TB Festplatten (Seagate Ironwolf 5400rpm, ST6000VN001) nicht GPT zur Partitionierung verwendet, sondern die raw-devices direkt mit zpool angesprochen. Jetzt habe ich die Umstellung vorgenommen und vorher wie nachher bonnie++ Messungen vorgenommen (zpool in allen Fällen mit gleichen Daten gefüllt zu etwa 80%):

Benchmarking mit sector63 Fehler, mit cache, mit ZIL
Benchmarking raidz1 ohne cache ohne ZIL
Benchmarking raidz1 mit cache ohne ZIL
Benchmarking raidz1 mit cache mit ZIL

Signifikanteste Verbesserungen mit korrektem Blockalignment sieht man beim sequential Output: 244 zu 311MB/s, beim rewrite von 116 zu 169MB/s, beim sequential Input Block von 296 zu 502MB/s – interessanterweise hierbei überall mit mehr CPU-Last zu vorher (meine Theorie: Daten kommen logisch sauberer im alignment auf die Platte und somit sind schneller die Parity-Berechnungen erforderlich).
Random seeks haben sich verbessert von ~138/sec zu ~173/sec.
Weitere Verbesserungen zu sehen beim sequential create die Latenz hat sich von ~12,800µs auf ~1450µs verbessert und beim Random Create von 178ms zu ~1500µs.

Das sind so die signifikantesten Verbesserungen des RAID5 Stapels, welche sich beim benchmarking zeigen. Ich unterstelle, daß ich in der Praxis bestimmt nicht soviel merken werde. Mit der Umstellung ist aber ein mögliches Bottleneck beseitigt.

Die Werte mit ZIL als Verbesserung erachte ich als vernachlässigbar, in Relation zu der damit einhergehenden Gefahr eines Total-filesystem-Verlustes mit dem Hops-gehen eines ZILs. Dafür macht man kein RAID5, um Datenverlusten vorzubeugen. Also wird beim nächsten Umbau der Systemplatte der ZIL verschwinden.

FreeBSD, ZFS und dedup

Ein paar dedup-Erfahrungen möchte ich hier mitteilen…

Dedup ist ein feature im zfs, welches Daten auf Blocklevel-Ebene dedupliziert. Wird also eine Datei zweimal in zfs-Volume kopiert, wird sie nur einmal ihren Speicherplatz beanspruchen. Aktuell habe ich in meinem Serverchen 2 zpools, einen Raid1-basierten (2x4TB) mit aktiviertem dedup und einen mit Raid5 (4x6TB).
Da dedup sehr viel memory für die Verwaltung benötigt (die sogenannten ddt-tables), wurde auf einer nvme für jeden zpool neben einem 1GB großes ZIL (zfs intent log; Pufferung von metadaten im synchronen IO) ein 29GB großer cache für den L2ARC (hier werden die ddt-Tabellen verwaltet).

[maulwurf@alpina ~]$ zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
WD14TB    12.7T  10.5T  2.24T        -         -    12%    82%  1.11x  ONLINE  -
archiv    21.8T  16.8T  5.01T        -         -    24%    77%  1.14x  ONLINE  -
backup3G  2.72T   497G  2.23T        -         -     0%    17%  1.00x  ONLINE  -
raid1     3.62T  3.45T   180G        -         -    47%    95%  1.17x  ONLINE  -
root       382G   257G   125G        -         -    40%    67%  1.03x  ONLINE  -

Im zpool raid1 liegt ein zfs Volume „backup“, in welches regelmäßig eine WordPress-Seite gesichert wird, sowie eines für Musik-Dateien…
Im zpool archiv befindet sich ein Time Machine-Volume (zusätzlich ein Archiv für große files), auf welches 2 High-Sierra Systeme sowie 2 Big Sur Systeme (macOS) Installationen gesichert werden.
Die Idee ist einfach: Da fallen einige „Dubletten“ an, welche hervorragend dedupliziert werden können… leider gibt aber die zpool-Statistik nur Infos aus, welche den pool als Ganzes betreffen. Im Zuge einer Optimierung der zpool device Verwaltung, muss der zpool archiv noch neu eingerichtet werden.
Für die Reorganisierung wurde eine externe Backup-Festplatte mit 14TB angeschafft, das Kopieren des zfs mit den Backupdaten (9TB/~27,000 files) via zfs send/receive geschah recht zügig mit rund 150MB/s. Danach erfolgte das gleiche Verfahren mit dem Time Machine-Volume (3.75TB/~190,000 files), welches eine Woche brauchte, anfänglich mit rund 30MB/s, letztlich bei knapp 7.6MB/s im Schnitt landete für transferierte 4.14TB (Ausgabe vom Transfer mit -v Option). Was mich verwundert, warum ~400GB mehr transferiert wurden, als vom Urpsrungsvolume angegeben wurden – die Verwunderung wird dann vom Ärger verdrängt, wenn man feststellen darf, daß beim Ziel-zpool keine compression aktiviert war…
Nunja, die Backup-Platte hat keinen L2ARC-cache, was ich als mögliche Ursache für den langsamen Transfer sehe (hat sich beim Wiederherstellen mehr oder minder bestätigt)…
Der Restore war wesentlich erfreulicher, hat er das DatenVolume beim Backup noch um rund 400GB erhöht, behielt der Prozess es diesmal bei und die Datentransferrate lag bei beachtlichen 63MB/s für das dedup-Volume.
Jetzt kommt die Frage, hat der L2ARC cache ausgereicht?, hierzu ist folgende Ausgabe als Ergebnis interessant, beim monitoring hat man die Nutzung prima verfolgen können:

maulwurf@alpina /raid5]# zpool iostat -v raid5
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
raid5       4.93T  16.9T    177  2.77K  5.32M  72.4M
  raidz1    4.93T  16.9T    177  2.77K  5.32M  72.4M
    ada0p1      -      -    46    532  1.30M  26.3M
    ada1p1      -      -     43    531  1.28M  25.7M
    ada2p1      -      -     43    531  1.44M  26.3M
    ada4p1      -      -     44    532  1.42M  25.6M
  nvd0p6     128K   960M      0      0      1  24.9K
cache           -      -      -      -      -      -
  nvd0p7    19.5G  9.52G    504     41  1.20M  3.09M
----------  -----  -----  -----  -----  -----  -----

von den zur Verfügung stehenden 29GB (L2ARC cache) werden in etwa 2/3 genutzt, für dieses Volume also ausreichend (?)- der ZIL wird fast gar nicht verwendet (mehr oder minder logisch)…
Jetzt kopier ich noch das rund 300GB große Backup-Volume vom raid1 pool in den raid5 – 

11:08:51    303G   raid1/backup@backup
received 303GB stream in 5217 seconds (59.5MB/sec)
[root@alpina /raid5]# zpool iostat -v raid5
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
raid5       5.31T  16.5T    176  2.76K  5.02M  71.2M
  raidz1    5.31T  16.5T    176  2.76K  5.02M  71.2M
    ada0p1      -      -     46    532  1.22M  25.9M
    ada1p1      -      -     43    531  1.21M  25.2M
    ada2p1      -      -     43    531  1.35M  25.9M
    ada4p1      -      -     44    532  1.33M  25.2M
  nvd0p6     256K   960M      0      0      1  48.2K
cache           -      -      -      -      -      -
  nvd0p7    18.6G  10.4G    515     41  1.22M  3.05M
----------  -----  -----  -----  -----  -----  -----

Man sieht hier sogar noch eine Abnahme der cache (L2ARC) Nutzung.

Interessant zur Berechnung benötigter Ressourcen ist der Artikel „dedup or not dedup„, in welchem auch beschrieben wird, wieviel voraussichtlich an ARC-Speicher benötigt wird, in meinem hier betrachteten Falle (vor Umstellung):

[root@alpina ~]# zdb -b raid1 

Traversing all blocks to verify nothing leaked ...

loading concrete vdev 1, metaslab 14 of 15 .....
3.87T completed (3323MB/s) estimated time remaining: 277098hr 45min 20sec        
	No leaks (block sum matches space maps exactly)

	bp count:              35419785
	ganged count:                 0
	bp logical:       4477203583488      avg: 126404
	bp physical:      4252535812096      avg: 120061     compression:   1.05
	bp allocated:     4270123028480      avg: 120557     compression:   1.05
	bp deduped:        463651233792    ref>1: 1992696   deduplication:   1.11
	Normal class:     3806470971392     used: 95.50%

	additional, non-pointer bps of type 0:     132437
	Dittoed blocks on same vdev: 1466474

[root@alpina ~]# zdb -b archiv

Traversing all blocks to verify nothing leaked ...

loading concrete vdev 1, metaslab 14 of 15 .....
17.5T completed (14304MB/s) estimated time remaining: 341616hr 56min 05sec        
	No leaks (block sum matches space maps exactly)

	bp count:             111509014
	ganged count:                 0
	bp logical:      14381112954368      avg: 128968
	bp physical:     13922814364672      avg: 124858     compression:   1.03
	bp allocated:    19192156401664      avg: 172113     compression:   0.75
	bp deduped:        710846349312    ref>1: 3355041   deduplication:   1.04
	Normal class:    18481309908992     used: 77.06%

	additional, non-pointer bps of type 0:     197376
	Dittoed blocks on same vdev: 1664068

Rechnet man den Speicherbedarf für den pool raid1 aus (bp count: 35419785 x 320bytes), kommt man auf ~10GB; bei knapp 32GB Ram und der Kausalität, daß für dedup nur ca 25% vom ARC genutzt werden, ist der Hauptspeicher definitiv zu klein.
Der pool archiv mit seinem Time Machine-Volume würde um die 33GB beanspruchen wollen.

Somit habe ich mittlerweile den Entschluss gefasst, auf dem RAID1 keine Deduplikation mehr zu verwenden und das backup-zfs auf das archiv umzuziehen, sowie den L2ARC für archiv auf 96GB zu erweitern.

Das „Ende“ aktuell vom Lied:

[maulwurf@alpina ~]# zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
backup3G  2.72T   497G  2.23T        -         -     0%    17%  1.00x  ONLINE  -
raid1     3.62T  3.19T   443G        -         -    41%    88%  1.19x  ONLINE  -
raid5     21.8T  17.2T  4.60T        -         -     6%    78%  1.16x  ONLINE  -
root       382G   259G   123G        -         -    41%    67%  1.03x  ONLINE  -

References:
zfs dedup or not dedup
zfs, arc overview
memory requirements dedup/L2ARC