Fórum Root.cz
Hlavní témata => Server => Téma založeno: smaza 01. 11. 2023, 09:40:12
-
Dobrý den,
snažím se postavit domací NAS/virtualizační server na HP microserver GEN8 ve specifikaci:
CPU: Xeon E3-1220L V2
RAM: 16GB ECC
HDD: 4x WD30EFRX WD Red 3TB
SSD: ADATA 120GB
Gb LAN
Měl jsem to vymyšleno tak, že na SSD nainstaluju Proxmox a z HDD vytvořím ZFS stripped mirrors (analogie RAID10). V Proxmoxu bych pak spravoval LXC a Docker kontejnery včetně NASu se sambou.
Jakmile jsem měl vše připraveno, zkoušel jsem nějaké testovací kopírování velkých souborů na smb share. Při startu kopírování se rychlost pohybovala na horních limitech Gigabitové sítě, nicméně po několika sekundách rychlost spadla prakticky na nulu. IO delay se pohybovalo v rozmezí 50-80% CPU load > 6, kopírování spadlo. Zkoušel místo ZFS použit BTRFS ale vysledek byl prakticky stejný. Nakonec jsem zkoušel sekveční zápis na disky pomocí
# dd if=/dev/zero of=/mnt/test/tempfile bs=1M count=1024 conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 53.5769 s, 20.0 MB/s
Co jsem se díval na bechmarky, tak by se měl zápis pohybovat nad 120MB/s.
Zatím jsou to zkoušel na dvou discích, výsledek stejný. Nevíte v čem může být problém případně co otestovat?
Děkuji.
-
Mas B120i radic v RAID modu?
-
Ne. Mám zapnutý AHCI mód.
-
zkus rychlost na lokale a ne pres sit. testni na pripojeny ZFS:
dd if=/dev/zero of=/mnt/kde_mam_zfs/tempfile bs=1M count=1024 conv=fdatasync status=progresszkus raid2z na 4 discich
-
dd if=/dev/zero of=/mnt/kde_mam_zfs/tempfile bs=1M count=1024 conv=fdatasync status=progresszkus raid2z na 4 discich
Nevím v jakém to má tazatel teď stavu - zkoušel tam různé souborové systémy, ale zatím bych neházel žádná doporučení na různé konfigurace ZFS, přehazování vdevů, když zatím vůbec neví, čím to je.
Pokud na tom nejsou zatím žádná data, tak bych začal přímo testem blokových zařízení, abych vyloučil problém s hardwarem a teprve pak bych šel do vyšších vrstev.
Takže dd napřímo do zařízení toho jednotlivých disků.
Např. na Linuxu bych tam poslal něco jako
dd if=/dev/urandom of=/dev/sdX bs=1M count=1024 oflag=direct status=progress
Takovýhle gen 8 server jsem před pár lety nastavoval jako NAS s FreeBSD a ZFS, byl tam byly 8TB disky v ekvivalentu RAID10 (dva mirrorované vdevy), 8GB RAM. V podstatě bez jakékoliv výkonové optimalizace (výchozí blocksize pro dataset - 128k). Pro takovýhle sekvenční zápis při kopírování velkých souborů jsem byl někde okolo 80-100MB/s přes síť a SMB2.
-
Identická rychlost na všech HDD.
root@pve:~# dd if=/dev/zero of=/mnt/test/tempfile bs=1M count=1024 conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 53.5769 s, 20.0 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sda bs=1M count=1024 oflag=direct status=progress
1067450368 bytes (1.1 GB, 1018 MiB) copied, 52 s, 20.5 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 52.3376 s, 20.5 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sdc bs=1M count=1024 oflag=direct status=progress
1064304640 bytes (1.1 GB, 1015 MiB) copied, 52 s, 20.5 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 52.4687 s, 20.5 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sdd bs=1M count=1024 oflag=direct status=progress
1055916032 bytes (1.1 GB, 1007 MiB) copied, 52 s, 20.3 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 52.877 s, 20.3 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sdb bs=1M count=1024 oflag=direct status=progress
1063256064 bytes (1.1 GB, 1014 MiB) copied, 52 s, 20.4 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 52.5368 s, 20.4 MB/s
-
Když nabootuju do Gparted a pustím dd, rychlosti jsou 35MB/s.
-
To je fakt divný, ty disky by měly bez FS dávat daleko víc. Další divnost je, že je to na všech portech a discích +/- stejná hodnota.
Ten řadič HP B120i je takový divný hybrid, první dva porty mají 6Gbit SATA, druhé dva pak 3Gbit. Ale pořád i 3Gbit je to hodně nad tím, aby to limitovalo točivé disky.
Už si bohužel přesně nepamatuju, co jsem konkrétně předtím řešil za konfiguraci G8 a které tam bylo CPU (myslím, že ten slabší Celeron, ne Xeon), disky byly tuším HGST DC.
Nicméně podobný HP Gen8 Microserver se mi někdy tenhle týden dostane do ruky, můžu to zkusit změřit, dám vám vědět.
Ještě mě napadlo, kolik dává pro zajímavost to SSD, co máte na systém? Počítám, že je to připojené na stejném SATA řadiči místo interní CD mechaniky.. takže kdyby tam bylo úzké hrdlo, mělo by se to taky projevit.
-
Každopádně, tím testem rovnou do těch blokových zařízení jste vyloučil jakýkoliv filesystém. Takže nemá moc smysl řešit optimalizace ZFS, BTRFS, nějakého MD RADIu atp., dokud se nerozsekne proč jsou tak pomalé ty samotné disky.
-
Ne. Mám zapnutý AHCI mód.
Tak to prepni do RAID modu.
-
A co s tím pak v Linuxu udělá? Ten B120i RAID řadič měl nějaké poslední ovladače od HP do starého RHEL (6 když ten server uvedli, pár prvních releasu pro 7 možná). Když tam není tenhle ovladač, nevidíte to ani jako blokové zařízení (na rozdíl třeba od obecných fakeraidů Intel RST, RSTe)
-
Ještě jsem mkrnul do biosi a radič byl v modu Legacy tak se omluvám za mystifikaci, přepnul jsem ho do AHCI (někde jsem ale četl, že by to na výkon nemělo mít vliv). V gparted se teď dostanu na 60MB/s viz příloha. Pořád je to ale polovina. sde je SSD.
-
Hele ten HW v zakladni konfiguraci (G1610T + 4GB) da 600MB/s na cteni (se 4ma diskama).
Skoro plny btrfs R5 + sifrovani dava kolem 80MB/s pres sambu na zapis (realne to limituje ten CPU).
Zadny specielni nastavovani netreba. Jen te varuju, pokud nevis, tak z ty paty ksandy to bydefault neumi nabootovat. Da se to vyresit tak, ze z toho udelas jednodiskovej raid (v konfiguraci) ale ma to tu vlastnost, ze to po vypnuti tu konfiguraci zapomene, takze to musis pokazdy nastavit znova. Takze lepsi reseni je vrazit tam CFko nebo USB dongle (vevnitr je normalni USB konektor) a /boot dat tam.
-
https://www.truenas.com/community/threads/write-performance-issues-with-scale-22-02-on-hp-microserver-gen-8.99884/post-689488
https://www.reddit.com/r/homelab/comments/ivdobv/microserver_gen8_terrible_io_performance/g5vwd8g/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
-
Ještě jsem mkrnul do biosi a radič byl v modu Legacy tak se omluvám za mystifikaci, přepnul jsem ho do AHCI (někde jsem ale četl, že by to na výkon nemělo mít vliv). V gparted se teď dostanu na 60MB/s viz příloha. Pořád je to ale polovina. sde je SSD.
Tak to bylo tím. Legacy režim emuluje režim UltraATA (staré paralelní IDE), které má reálná maxima okolo těch původních hodnot.
Naměřených 60-70 MB/s je takhle napřímo přes dd do točivého SATA disku a bez další optimalizace scheduleru zařízení v Linuxu normální. Oproti těm 20 MB/s předtím, to byl exces.
Důvod je ten, že za této situace (s dd) se do zařízení zapisuje typicky jeden blok současně a je tam aktivní jeden I/O request. Jinými slovy - queue depth je 1 (z max. 32 u SATA zařízení) a zdaleka se nevyužije možnost efektivnějšího přenosu a optimalizace zápisu do disku.
Čtení ve výchozím nastavení scheduleru je trochu jiné, tam se ještě projeví přednačítání bloků (read-ahead), takže to se i takhle s dd a bez optimalizace přiblíží maximální propustnosti z disku.
Nebál bych se toho, v reálném provozu a s případnou další optimalizací bude ta rychlost sekvenčního zápisu daleko vyšší. Podle mě se klidně dostanete na ten dvojnásobek. To dd bylo jen rychlá cesta, jak zjistit, že tam nemáte jiný problém.
-
Ještě pár hodnot na porovnání.
Dnes se mi dostal shodou okolností do ruky také HP Microserver Gen 8, základní model se slabším CPU G1610T.
Měl jsem po ruce dva volné HDD. Starý 2TB Hitachi vytažený z vyřazeného pole a novější 6TB Seagate IronWolf Pro.
Vyzkoušel jsem dd zápis s tím samým příkazem pro srovnání.
Pak jsem totéž zreplikoval v benchmarku fio (balíček ve většině distribucí), který umožňuje nastavit zmíněný queue depth (QD), abyste viděl rozdíl.
Device Model: HDS723020ALA640 RSD HUA
dd
user@lunar:~$ sudo dd if=/dev/urandom of=/dev/sda bs=1M count=1k status=progress oflag=direct
1068498944 bytes (1.1 GB, 1019 MiB) copied, 16 s, 66.7 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 16.0867 s, 66.7 MB/s
fio QD 1
Run status group 0 (all jobs):
WRITE: bw=64.2MiB/s (67.3MB/s), 64.2MiB/s-64.2MiB/s (67.3MB/s-67.3MB/s), io=7700MiB (8074MB), run=120006-120006msec
Run status group 1 (all jobs):
READ: bw=138MiB/s (145MB/s), 138MiB/s-138MiB/s (145MB/s-145MB/s), io=16.2GiB (17.4GB), run=120003-120003msec
fio QD 8
Run status group 0 (all jobs):
WRITE: bw=137MiB/s (144MB/s), 137MiB/s-137MiB/s (144MB/s-144MB/s), io=16.0GiB (17.2GB), run=120050-120050msec
Run status group 1 (all jobs):
READ: bw=138MiB/s (145MB/s), 138MiB/s-138MiB/s (145MB/s-145MB/s), io=16.2GiB (17.4GB), run=120061-120061msec
Model Family: Seagate IronWolf Pro
Device Model: ST6000NE0023-2EX110
dd
user@lunar:~$ sudo dd if=/dev/urandom of=/dev/sdc bs=1M count=1k status=progress oflag=direct
1072693248 bytes (1.1 GB, 1023 MiB) copied, 14 s, 76.6 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 14.0178 s, 76.6 MB/s
fio QD 1
Run status group 2 (all jobs):
WRITE: bw=77.7MiB/s (81.5MB/s), 77.7MiB/s-77.7MiB/s (81.5MB/s-81.5MB/s), io=9329MiB (9782MB), run=120003-120003msec
Run status group 3 (all jobs):
READ: bw=222MiB/s (232MB/s), 222MiB/s-222MiB/s (232MB/s-232MB/s), io=26.0GiB (27.9GB), run=120001-120001mse
fio QD 8
Run status group 2 (all jobs):
WRITE: bw=222MiB/s (233MB/s), 222MiB/s-222MiB/s (233MB/s-233MB/s), io=26.0GiB (27.9GB), run=120032-120032msec
Run status group 3 (all jobs):
READ: bw=222MiB/s (233MB/s), 222MiB/s-222MiB/s (233MB/s-233MB/s), io=26.1GiB (28.0GB), run=120034-120034msec
Je tam pěkně poznat, že se po zvýšení QD propustnost při zápisu víceméně srovná se čtením.
Jinak finální výkon a optimalizace celého systému pro daný workload má spoustu aspektů, co to můžou ovlivnit.
Tohle je ideální kombinace velkého bloku a příhodného QD, a hází to víceméně maximální propustnost pro rotační disky na začátku plotny.
-
Jak už bylo v odkazu od a12, tak microserver vypíná u disků write-cache. Jde to zapnout v biosu anebo hdparm. Kouknout se jde pomocí sudo hdparm -W /dev/sda
Vypnutí write-cache vypne i NCQ a zápis je celkově pomalý. Kouknout jde pomocí cat /sys/block/sda/device/queue_depth
Mělo by tam být 32. Když je tam 1, tak je NCQ vypnuté.
Taky sloty 1 a 2 jsou SATA3, kdežto 3, 4 a CD jen SATA2. To ale je spíš důležité pro SSD než pro HDD.
-
Děkuji všem za podnětné příspěvky. Ten Legacy mód jsem tam měl zapnutý, abych mohl bootovat ze sata portu na desce, ve kterém mám strčené to SSD. Viz zde https://op-co.de/blog/posts/microserver_gen8_fix_boot_order/ (https://op-co.de/blog/posts/microserver_gen8_fix_boot_order/). Trochu se v tom pohrabu a pak dám report.
Díky.
-
Taky by bylo zahodno zkontrolovat jakou rychlosti bezi
dd if=/dev/urandom of=/dev/null ...
-
V podstatě můžeš mít v biosu co chceš a pak třeba v /etc/rc.local zapneš pro každý disk
hdparm -W 1 /dev/sda
echo 32 > /sys/block/sda/device/queue_depth
A mělo by to zapisovat rychle.
Další možnost je mít /boot ma microSD kartě, co se zasunuje přímo do MB.
-
Taky by bylo zahodno zkontrolovat co dava
dd if=/dev/urandom of=/dev/null ...
To je pravda, na E3-1265L V2 to jede přes 300 MB/s, ale ten Celer bude trochu pomalejší. Jestli jde jen o rychlost, tak je lepší brát jako zdroj /dev/zero
-
V biosu jsem zapnul raid radič a povolil cache. Vytvořeil RAID0 z SSD disku a systém normálně nabootoval z SSD. Asi vyřešeno. Díky moc.
root@pve:~# hdparm -W /dev/sda
/dev/sda:
write-caching = 1 (on)
root@pve:~# hdparm -W /dev/sdb
/dev/sdb:
write-caching = 1 (on)
root@pve:~# hdparm -W /dev/sdc
/dev/sdc:
write-caching = 1 (on)
root@pve:~# hdparm -W /dev/sdd
/dev/sdd:
write-caching = 1 (on)
root@pve:~# cat /sys/block/sda/device/queue_depth
32
root@pve:~# dd if=/dev/urandom of=/dev/null
^C6753515+0 records in
6753514+0 records out
3457799168 bytes (3.5 GB, 3.2 GiB) copied, 17.0893 s, 202 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sda bs=1M count=1024 oflag=direct status=progress
933232640 bytes (933 MB, 890 MiB) copied, 6 s, 155 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.87877 s, 156 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sdb bs=1M count=1024 oflag=direct status=progress
1059061760 bytes (1.1 GB, 1010 MiB) copied, 7 s, 151 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.11022 s, 151 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sdc bs=1M count=1024 oflag=direct status=progress
1040187392 bytes (1.0 GB, 992 MiB) copied, 7 s, 149 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.23144 s, 148 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sdd bs=1M count=1024 oflag=direct status=progress
1006632960 bytes (1.0 GB, 960 MiB) copied, 7 s, 144 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.45791 s, 144 MB/s
root@pve:~#
-
Ještě si s tím hraju přepnul jsem zpátky na Legacy a zapnul cache. Rychlosti plus mínus stejné. Nicméně queue_depth=1, když chci zapsat hodnotu 32 napíše mi to:
root@pve:~# echo 32 > /sys/block/sda/device/queue_depth
-bash: /sys/block/sda/device/queue_depth: Permission denied
root@pve:~# hdparm -W /dev/sd[abcd]
/dev/sda:
write-caching = 1 (on)
/dev/sdb:
write-caching = 1 (on)
/dev/sdc:
write-caching = 1 (on)
/dev/sdd:
write-caching = 1 (on)
root@pve:~# dd if=/dev/urandom of=/dev/sda bs=1M count=1024 oflag=direct status=progress
932184064 bytes (932 MB, 889 MiB) copied, 6 s, 155 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.88844 s, 156 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sdb bs=1M count=1024 oflag=direct status=progress
1038090240 bytes (1.0 GB, 990 MiB) copied, 8 s, 130 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.2777 s, 130 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sdc bs=1M count=1024 oflag=direct status=progress
1056964608 bytes (1.1 GB, 1008 MiB) copied, 7 s, 151 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.12634 s, 151 MB/s
root@pve:~# dd if=/dev/urandom of=/dev/sdd bs=1M count=1024 oflag=direct status=progress
1035993088 bytes (1.0 GB, 988 MiB) copied, 8 s, 129 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.29229 s, 129 MB/s
root@pve:~# cat /sys/block/sda/device/queue_depth
1