Výkon čtení disku a komprese v NASu (A53 4jádro) - hodnoty

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Jaké bych měl očekávat hodnoty výkonu v NASu s 64bit procesorem ARM  A53 čtyřjádro.  Má 2 sloty pro sata iii i disky se hlásí  jako v režimu SATA 6Gb/s ("in use").Spíš tedy bych chtěl zhodnotit zde napsané hodnoty:

1.)
rychlost  čtení disku dd if=/dev/sda of=/dev/null bs=1/2/4M .....155MB/s, 145 u konce kapacity 10TB

Disky by měl umět >220MB/s.

2.) komprese gzip  dd if=/dev/sda of=/dev/null bs=1/2/4M | gzip -1/-9 >/jinydisk/outfile.out .... 4 MB/ s!!!!!!!!!!!!!! (nebo případně ...gzip -c || dd of=soubor-jinydisk) To je nepoužitelné, já potřebuji opět stovky MB/s


Prosím o nějaké tipy čím by to mohlo být... u 2.  ještě musí vyzkoušet víc faktorů (of=/přímo-partition-sdc3) - především se zapisuje na disk USB3.0  a ještě ve filesystému exfat, který jsem tam musel dodat ručně (mount.exfat do /usr/sbin) a ručně připojit

[Reklama]

[Karmelos]

Těch 155 se mi zda na plotnový disk docela dobrá hodnota...
viz https://hdd.userbenchmark.com/

[Jan Fikar]

Disky by měl umět >220MB/s.

A to je přesně co za disk?

2.) komprese gzip  dd if=/dev/sda of=/dev/null bs=1/2/4M | gzip -1/-9 >/jinydisk/outfile.out .... 4 MB/ s!!!!!!!!!!!!!! (nebo případně ...gzip -c || dd of=soubor-jinydisk) To je nepoužitelné, já potřebuji opět stovky MB/s

Tak dobré je ze začátku pro test komprese posílat do /dev/null. Taky gzip je pomalý, jestli trváte na gz, jde použít pigz, který použije všechna jádra. Mám A55 čtyřjádro 2GHz:

Kód: [Vybrat]

cat bigfile | pigz -1 | pipebench > /dev/null
jede tak jen do 18 MB/s. Pokud použijete rychlejší zstd (-T0 použije všechny jádra), nebo staré jednovláknové lzop nebo lz4, tak by to mohlo jít:

Kód: [Vybrat]

cat bigfile | zstd -T0 -1 | pipebench > /dev/null
jede do 80 MB/s. Ale samozřejmě záleží ještě na datech. Já vzal cosi nekomprimovatelného.

[Jakub Štech]

2.) komprese gzip  dd if=/dev/sda of=/dev/null bs=1/2/4M | gzip -1/-9 >/jinydisk/outfile.out

Co tady tou inkantací přesně myslíte? dd čte /dev/sda, posílá to do /dev/nullu, a jeho stdout (na který neposílá nic) komprimujete... tedy měříte rychlost gzipu na stojící rouře.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Pardon , dohnalo mě Copy Paste jako Maláčovou. Sorry, hledal jsem ve slovníku... Nejdřív jsem myslel, že jde o inkontinenci.  Test s gz byl samozřejmě bez "of->null".
A jen poznámka na okraj, měřil jsem to i s "před"příkazem time a i | dd of, abych měl přehled o množství dat na vstupu i výstupu

Kód: [Vybrat]

[root@nasturbace #]$ time dd if=/dev/sda bs=1M count=160 skip=4000000 | gzip -1nebo9 -c  | dd of=/dev/null

### skoro prázdná oblast
160+0 records in
160+0 records out
167772160 bytes (160.0MB) copied, 6.811203 seconds, 23.5MB/s
real    0m 6.81s
user    0m 0.00s
sys     0m 0.62s
319+1 records in
319+1 records out
163592 bytes (159.8KB) copied, 6.817881 seconds, 23.4KB/s

### neprázdná oblast (pozor, osmina velikosti)

sudo time dd if=/dev/sda bs=1M count=20 skip=19000 | gzip -c -4  | dd of=/dev/null
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 5.780149 seconds, 3.5MB/s
real    0m 5.78s
user    0m 0.00s
sys     0m 0.06s
40925+1 records in
40925+1 records out
20953927 bytes (20.0MB) copied, 5.807068 seconds, 3.4MB/s


Holt asi na to budu muset použít i7... I komprese prázdného místa jede 20MB/s

A ještě nějaká rada, když chci aby byla utilizována maximální rychlost čtení i zápisu, vyplatí se to nějak "bufferovat do RAM", pokud by byl druhý(nebo i první) disk pomalejší? (S přihlédnutím, že občas se tam najde blok nul a tím pádem by se výstupní disk mohl chvíli flákat) . Že kdybych použil "mezi" pipami něco jako dd if | docasnybuffer14GBRAM |dd of.... (Vykládám to lapidárně)

2.) komprese gzip  dd if=/dev/sda of=/dev/null bs=1/2/4M | gzip -1/-9 >/jinydisk/outfile.out

Co tady tou inkantací přesně myslíte

Sorry, hledal jsem ve slovníku... Nejdřív jsem myslel, že jde o inkontinenci.

[Reklama]

[czechsys]

Takze to shrneme:
1] chcete stovky MBps pro kompresi (a zkousite nejpomalejsi formaty typu zip...)
2] zdroj je 1-2 disky na SATA3
3] chcete to posilat na usb3

Hm, rekl bych, ze mate trochu velke oci.

ad 1] lz4, zstd a podobne rychle kompresni algoritmy
ad 2] jak dojdou cache, tak to zpomali, zvlast, jak to nebude sekvencne ulozene na disku (a to nebude)

[Jan Fikar]

Kód: [Vybrat]

[root@nasturbace #]$ time dd if=/dev/sda bs=1M count=160 skip=4000000 | gzip -1nebo9 -c  | dd of=/dev/null


tak jestli jde o kompresi prázdného místa, je lepší použít jako vstup prostě /dev/zero, který ty nuly bude dávat rychleji než disk

time dávat nemusíte, nové dd má status=progress, nebo jde použít pipebench a podobné

gzip -c nemusí být, ty trubky sám detekuje

a dd of=/dev/null taky nemusí být, stačí prostě > /dev/null

A ten mnou navrhovaný pigz nebo zstd se vám nelíbí kvůli čemu? Je to několikrát rychlejší. Na prázdných datech:

Kód: [Vybrat]

dd if=/dev/zero bs=1M status=progress count=1024 | gzip -1 > /dev/null
1039138816 bytes (1.0 GB, 991 MiB) copied, 14 s, 74.2 MB/s

Kód: [Vybrat]

dd if=/dev/zero bs=1M status=progress count=1024 | pigz -1 > /dev/null
1064304640 bytes (1.1 GB, 1015 MiB) copied, 6 s, 177 MB/s

Kód: [Vybrat]

dd if=/dev/zero bs=1M status=progress count=1024 | zstd -T0 -1 > /dev/null
806354944 bytes (806 MB, 769 MiB) copied, 2 s, 403 MB/s

A ještě nějaká rada, když chci aby byla utilizována maximální rychlost čtení i zápisu, vyplatí se to nějak "bufferovat do RAM", pokud by byl druhý(nebo i první) disk pomalejší? (S přihlédnutím, že občas se tam najde blok nul a tím pádem by se výstupní disk mohl chvíli flákat) . Že kdybych použil "mezi" pipami něco jako dd if | docasnybuffer14GBRAM |dd of.... (Vykládám to lapidárně)

myslím, že to nepomůže. nejpomalejší bude ta komprese, obzvlášť když tam necháte jednovláknový gzip. pomůže velký bs, ale to už máte 1M, to asi stačí

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Důvod nepoužití těch utilit, je lenost +  že to právě běží na NASu, s vlastním "os", kde není ani smartmontools (získávání smart je tam zrůdnost a hdparm je osekaný, neumí -M) , apt, dpkg, pacman, yum a nepřipojen k internetu, takže používám "co dům dá". 

Asi si ho stáhnu  a  zkopíruji do sbin/ stejně jako nepodporaný exFAT co tam "neměl podporu".




Proč by to nemělo být "uložené" sekvenčně? Opakuji, nebudu kopírovat soubory, ale blokové zařízení. Zdrojová data z podstaty budou sekvenčně čtená a možná snad je obava u těch zapisovaných, ale tam jsem myslel, že pomůže buffer a velké bloky, kdy na disk se vychrlí vždy blok o 100MB třeba a i tím bude zajištěné, že buď se zapíše krátký komprimovaný blok a nebo se 1:1 zkopíruje "nekomprimovaný" ( poněkud binárně řečeno- komprese g/zip jak ji známe přece  precuje někde mezi)

A nebo se poohlédnu po již hotovém řešení...


Přitom by mi stačilo  to jednoduché řešení - nulové bloky to zapisovat nebude a nenulové to zapíše celé (akorát otázka je vhodná velikost bloku něco mezi 4MB a 512MB?) a zápis nějaké "bitmapy" obsazení.

Účel: v podstatě mít možnost přistupovat k 10TB disku velice rychle. Ale nemám peníze na nákup 10TB SSD. Proto chci disk přečíst předem (cca 10-15 hodin) a uložit ho bez nul, což dle odhadu bude 25% max. a pak se v něm pohybovat. (A  nebo aspoň udělat bitmapu, ze které uvidím hned, kde jsou ty bloky rozmístěné)

[Jan Fikar]

To IMHO nebude fungovat. Jistě by všichni uvítali výkon SSD při použití pouze HDD, ale nejde to. Komprese i vynechání nul vše jen zpomalí.

Navíc nechápu o jaké nuly jde. Jde o prázdná místa na disku, kam nebylo ještě nic zapsáno? To nemá na čtení žádný vliv, FS to přeskočí. Nebo jde o nuly v souborech? Na to existují tzv. sparse soubory. S výhodou lze použít na obrazy disků, kde nevyužité místo nezabírá nic ve výsledném souboru. Ale i tak je to ve výsledku pomalejší.

Kód: [Vybrat]

https://en.wikipedia.org/wiki/Sparse_file