Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Ħαℓ₸℮ℵ ␏⫢ ⦚ 08. 12. 2021, 15:07:05
-
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
-
Těch 155 se mi zda na plotnový disk docela dobrá hodnota...
viz https://hdd.userbenchmark.com/ (https://hdd.userbenchmark.com/)
-
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:
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:
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.
-
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
[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.
-
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)
-
[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:
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
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
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é)
-
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ší.
https://en.wikipedia.org/wiki/Sparse_file