ZFS pozastavuje zápis po zaplnění bufferu

[Trubicoid2]

Ještě mě napadá, že může být problém se zarovnáním na 4k bloky. Hlavní problém bude ta deduplikace, ale zarovnání by taky mělo být.

Musí být zarovnaný partice, pak ten mdadm RAID, pak LUKS a nakonec i ZFS. Je to otrava, ale dělá se to většinou jen jednou. Nejlíp zarovnat třeba na 4MB, pro jistotu.

https://support.mayfirst.org/wiki/disk_alignment

http://wiki.illumos.org/display/illumos/ZFS+and+Advanced+Format+disks

[Reklama]

[Petr Kratochvíl]

Ještě mě napadá, že může být problém se zarovnáním na 4k bloky. Hlavní problém bude ta deduplikace, ale zarovnání by taky mělo být.

Děkuji za tip. Každopádně více než rychlost nyní řeším hlavně plynulost zápisu a aby bylo možné mazat snapshoty. Ano, může to spolu souviset.

Aktualizuji informace:

Zjistil jsem, že na ubuntu-zfs (nativní ZFS) cca po 1 dni přestal fungovat OS kvůli OOM aneb došla volná fyzická RAM.

Plynulost zápisu se výrazně zlepšila a nejproblematičtější snapshot se podařilo během 5 hodin smazat potom, co jsem včera odinstaloval ubuntu-zfs (nativní ZFS) a nainstaloval ZFS-FUSE. Akorát zlobí nepochopitelně oprávnění (soubor vlastní uživatel krato, nelze ho otevřít, provedu "chown krato" a už ho lze otevřít), nelze mountovat snapshoty (obchází se klonováním na nový volume) a když jsem se pokusil přihlásit do KDE s domovským adresářem na ZFS, tak ZFS-FUSE dost ošklivě spadl:

Kód: [Vybrat]

rsync: write failed on "/w/videa/cinema-20100908-2000.avi": Software caused connection abort (103)
rsync error: error in file IO (code 11) at receiver.c(389) [receiver=3.1.0]

Kód: [Vybrat]

server ~ # zpool list
connect: Spojení odmítnuto
Please make sure that the zfs-fuse daemon is running.
internal error: failed to initialize ZFS library
Jiné OS jsem zkusil, na doporučení zde FreeBSD a OpenIndiana (nástupce OpenSolaris). FreeBSD mi nesedlo a OpenIndiana zatím ve VirtualBoxu píše při "zpool import" něco o chybném vdev. Nevím, zda to není zmatené tím, že pool byl vytvořen v debian-like Linuxu, tj. s /dev/disk/by-id/<něco> místo /dev/dsk/<něco> atd. Asi to ještě zkusím nativně z Live flash.

Zkusím OpenIndiana nativně, podívám se na velikosti bloků a pak už dál nevím. Na velkou RAM nejsou finanční prostředky a navíc není jistota, že by na plynulost zápisu pomohla.

[Petr Kratochvíl]

Ještě doplním:

Po restartu přeinstalováno zpět na nativní ubuntu-zfs a spuštěno kopírování. To se po cca 470 MB pozastavilo ačkoliv to nevypadá, že by byl nedostatek volné RAM:

Kód: [Vybrat]

top - 02:04:58 up 3 min,  5 users,  load average: 1,77, 0,57, 0,21
Tasks: 914 total,   2 running, 912 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,8 us,  6,9 sy,  0,0 ni, 47,5 id, 44,8 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   4048168 total,  2257116 used,  1791052 free,    83540 buffers
KiB Swap: 16980988 total,        0 used, 16980988 free.  1039824 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                               
 6383 root       1 -19       0      0      0 D   8,5  0,0   0:02.98 z_wr_iss                                                                                             
 6723 root      20   0   25732   2356   1140 R   2,0  0,1   0:00.15 top                                                                                                   
  371 root      20   0       0      0      0 S   1,3  0,0   0:00.44 l2arc_feed                                                                                           
 6681 root      20   0       0      0      0 S   1,0  0,0   0:00.23 kworker/0:3                                                                                           
   61 root      20   0       0      0      0 S   0,3  0,0   0:00.41 kworker/0:2         
...

[Mirek Prýmek]

FreeBSD mi nesedlo

V čem ti nesedlo? Bude to pravděpodobně jenom nezvyk...

[Trubicoid2]

Tak ten dedup pořád nemáš vypnutej?

Kód: [Vybrat]

zpool list| grep dedupVono nestačí to jen vypnout, to se vztahuje na nově zapsaný data pouze. Tedy je potřeba vypnout, všechny data zazálohovat, smazat a nahrát znova. Bych zrovna udělal to zfs znova, bez mdadm a se zarovnáním. Stejný to je s kompresí, když přepneš na lz4, tak to platí jen pro nově zapsaná data.

Jinak možná blbne hw disku? Stál by za to ho prověřit jednak smartem a pak vlastní zfs

Kód: [Vybrat]

zpool scrub all
Taky ten disk je dost plnej, není to tím?

[Reklama]

[Petr Kratochvíl]

Tak ten dedup pořád nemáš vypnutej?

Kód: [Vybrat]

zpool list| grep dedupVono nestačí to jen vypnout, to se vztahuje na nově zapsaný data pouze. Tedy je potřeba vypnout, všechny data zazálohovat, smazat a nahrát znova. Bych zrovna udělal to zfs znova, bez mdadm a se zarovnáním. Stejný to je s kompresí, když přepneš na lz4, tak to platí jen pro nově zapsaná data.

Dedup při zápisu je jedním z hlavních důvodů, proč jsem přešel z Btrfs na ZFS.

Jinak možná blbne hw disku? Stál by za to ho prověřit jednak smartem a pak vlastní zfs

Kód: [Vybrat]

zpool scrub all

Disk byl hned po koupi pro jistotu zkontrolován přes "badblocks -w". Díky za tip na zpool scrub. Je se obávám, že výsledek budu vědět až za několik dní nebo týdnů.

Taky ten disk je dost plnej, není to tím?

To je jeho účel. Potřebuji aby fungoval i plný.

Přemýšlel jsem o návratu k Btrfs, ale nějak mi s ním nefungoval nástroj na deduplikaci (bedup?), která se navíc provádí jen na již uložených datech (na dedup při zápisu se pracuje) a navíc mám strach z nezralosti, viz některé bug fixy a vylepšení teprve v nedávné době, viz https://btrfs.wiki.kernel.org/index.php/Changelog , konkrétně např.:

• btrfs-progs 4.1.2 (Jul 2015): urgent bugfix: mkfs creates invalid filesystem, must be recreated
• v4.2 (Aug 2015): deduplication does not change mtime/ctime

[Mirek Prýmek]

Disk byl hned po koupi pro jistotu zkontrolován přes "badblocks -w". Díky za tip na zpool scrub. Je se obávám, že výsledek budu vědět až za několik dní nebo týdnů.

Opakuju: tohle není normální situace, máš tam něco velmi špatně.

To je jeho účel. Potřebuji aby fungoval i plný.

Opět špatný předpoklad/požadavek.

You need to keep free space in your pool. It's mainly for copy-on-write actions and snapshots. Performance declines at about 85% utilization. You can go higher, but there's a definite impact.

http://serverfault.com/questions/511154/zfs-performance-do-i-need-to-keep-free-space-in-a-pool-or-a-file-system

Ty chceš prostě vlastnosti Ferrari a rozpočet máš na Wartburga, to nikdy fungovat nebude. Nemůžeš chtít desítky terrabajtů, postupně přidávat disky za běhu, deduplikovat a jánevímcoještě a honit to na kdovíjaké plečce se 4GB RAM. To prostě nejde, smiř se s tím. Buď to udělej pořádně, nebo to nedělej vůbec, tímhle způsobem nemá smysl se o to snažit.

[trubicoid2]

ta deduplikace potřebuje 20GB RAM na každý TB dat (http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe), teda v tvým případě je třeba kolem 160GB RAM jen na deduplikaci

pokud tolik RAM nebudeš mít, nebude to fungovat, systém bude padat a je třeba to vypnout

na btrfs ta offline deduplikace zase nevyžaduje RAM, navíc jestli děláš hlavně snapshooty, tak oni nebudou na btrfs ze začátku zabírat místo, jako by byly deduplikovaný

záleží, co chceš dělat

[technik007_cz]

Ještě mě napadá, že může být problém se zarovnáním na 4k bloky. Hlavní problém bude ta deduplikace, ale zarovnání by taky mělo být.

Zjistil jsem, že na ubuntu-zfs (nativní ZFS) cca po 1 dni přestal fungovat OS kvůli OOM aneb došla volná fyzická RAM.

Dosla pamet ?
Zkus to zachranit timhle:

echo "# Min 512MB / Max  512MB RAM limit
options zfs zfs_arc_min=536870912
options zfs zfs_arc_max=536870912" > /etc/modprobe.d/zfs.conf
update-initramfs -k all -u

Muzes i treb limit 1GB, popripade v atributech zfs dej primarycache=none.
Primary cache je v RAM, vykon pujde rapidne dolu, proto doporucuju SSD cache aspon 32GB.

Prokopirovat data na novy pool bez deduplikace.
Jak bylo zminovano nekolikrat, nemas na to RAM.
Sam jsem byl v teto situaci mrznuti, zatuh systemu pri kopirovani, musel jsem to vyresit prekopirovanim vsech dat na novy pool.

[Vladimír Drgoňa]

a myslím problém bude s tou deduplikací, kolik máš ram? máš l2arc? já měl deduplikaci jen na 4T (půlka plná) zapnutou a s 16GB RAM to dělalo velmi velké problémy, musel jsem deduplikaci vypnout.

Mám sice jen 4 GB RAM, ale swap 16 GB je téměř vždy prázdný. Jsem si vědom, že by to mohlo zpomalovat zápis na disk, ale rozhodně jsem nečekal problémy s plynulostí zápisu. Matně si vzpomínám, že vypnutí dedup nepomohlo, ale mohu to zkusit po příštím restartu (mazání snapshotu stále běží).

L2ARC je téměř 100 GB, pokud se nemýlím a je společně s logem na SSD disku:

Kód: [Vybrat]

                                            capacity     operations    bandwidth
pool                                     alloc   free   read  write   read  write
---------------------------------------  -----  -----  -----  -----  -----  -----
all                                      6,95T   304G     94      0   237K  1,45K
  dm-name-all                            6,95T   304G     94      0   237K  1,35K
logs                                         -      -      -      -      -      -
  ata-CT250BX100SSD1_1532F00A52C0-part6      0    80M      0      0    137     95
cache                                        -      -      -      -      -      -
  ata-CT250BX100SSD1_1532F00A52C0-part5  1,19G  96,6G     62     32   151K   174K

Pozerám na výpis. Ak je log partícia veľká 80MB, tak sa veľmi rýchlo zaplní a ďalší zápis drhne. Osobne mám na serveri 4GB log a videl som ho zaplnený viac ako zpolovice.
Dedup je fajn, ale so 4GB RAM na ňu rovno zabudni. Mne zabíjala server so 16GB RAM, deduplikovaných dát bolo menej ako 1TB.
ZFS obsadí všetku voľnú pamäť, pokiaľ nemá nejaké špeciálne nastavenia. Vo FreeBSD je to vfs.zfs.arc_max, v Linuxe podobne: zfs_arc_max.

[Mirek Prýmek]

Pozerám na výpis. Ak je log partícia veľká 80MB, tak sa veľmi rýchlo zaplní a ďalší zápis drhne.

Áááá, dobrej postřeh, toho jsem si ani nevšimnul, nenapadlo by mě, že někdo bude na ssd vyhrazovat 80MB To by dost stálo za zkoušku ten ZIL odstranit, jak to s výkonem pohne. Může to udělat za běhu, takže pohoda.

[technik007_cz]

Ja jsem mel log cache par mega a stacilo to. Tady opravdu se nejdriv dela a pak keca jak v hospode?
"Ta cache je tak mala a tak ji smazeme..."
To opravdu si neumite najít v dokumentaci k cemu tam je?
Jste amateri a nikdy na problém takhle neprijdete  !

[Vladimír Drgoňa]

Ja jsem mel log cache par mega a stacilo to. Tady opravdu se nejdriv dela a pak keca jak v hospode?
"Ta cache je tak mala a tak ji smazeme..."
To opravdu si neumite najít v dokumentaci k cemu tam je?
Jste amateri a nikdy na problém takhle neprijdete  !

Koľko je pár mega? 10MB? 20MB? Minimálna partícia v zfs môže mať 64MB.
 Log(ZIL) alebo cache (L2ARC)? Sú to pre mňa 2 odlišné partície. Každá má zmysel, každá je určená na niečo iné a spolu sa dopĺňajú.
Podľa dokumentácie Oracle by som ju navrhoval zvýšiť na 2GB, vychádzam z použitej RAM:

• The minimum size of a log device is the same as the minimum size of each device in a pool, which is 64 MB. The amount of in-play data that might be stored on a log device is relatively small. Log blocks are freed when the log transaction (system call) is committed.
• The maximum size of a log device should be approximately 1/2 the size of physical memory because that is the maximum amount of potential in-play data that can be stored. For example, if a system has 16 GB of physical memory, consider a maximum log device size of 8 GB.

Osobne používam ZFS už viac ako 5 rokov, 4 roky ju mám na produkčnom serveri takže viem o čom píšem. Nemám na čo prichádzať, je úplne jasné, že v takej konfigurácii nemôže dedup nikdy seriózne fungovať. Pri zápisoch do 1MB/s by to možno fungovalo, ale pri plne obsadenom HDD určite nie.

[Mirek Prýmek]

Log(ZIL) alebo cache (L2ARC)? Sú to pre mňa 2 odlišné partície. Každá má zmysel, každá je určená na niečo iné a spolu sa dopĺňajú.

Přesně tak. L2ARC může být libovolně malá a může se klidně i porouchat, nic se neděje. ZIL je přesný opak - porouchat se nesmí (obsahuje ještě na disk nezapsaná data) a velikost musí mít dostatečnou podle toho, kolik se na disk (maximálně) zapisuje. Pokud se na ZIL nedá zapisovat v dostatečném množství a rychleji než na samotný disk, postrádá smysl a degraduje výkon.

[P]

kde zacat? napriklad tym, ze mas malo RAM. ze pouzivas kus softu, ktory nevidel poriadny vyvoj a testovanie poslednych 7 rokov. ze ocakavas luxus rolls roycu za cenu trabanta z druhej ruky.

ako plan, preinstaluj na posledny solaris (11.3), pridaj druhy disk, vypni dedup a zapni zrkadlo. potom pridaj RAMku (vela RAMky, kopec RAM). kym nevycerpas moznost pridavat RAM, nepridavaj zbytocne ZIL a L2ARC.

potom sa vrat, poradime