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/)
Citace od: lathe kdy 08. 12. 2021, 15:07:05
Disky by měl umět >220MB/s.
A to je přesně co za disk?
Citace od: lathe kdy 08. 12. 2021, 15:07:05
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/nulljede 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/nulljede do 80 MB/s. Ale samozřejmě záleží ještě na datech. Já vzal cosi nekomprimovatelného.
Citace od: lathe kdy 08. 12. 2021, 15:07:05
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ě)
Citace od: Křišťan Surname kdy 09. 12. 2021, 01:11:25
Citace od: lathe kdy 08. 12. 2021, 15:07:05
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)
Citace od: lathe kdy 09. 12. 2021, 08:45:41
[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/sdd 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/sdd 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/sCitace od: lathe kdy 09. 12. 2021, 08:45:41
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