Aceasta este o continuare a: Scrie în rețea de mare viteză cu capacitate mare de stocare. Configurația s-a schimbat considerabil.
Am o piscină cu o singură raid-z2 cu 6 unități, toate unitățile Exos X18 CMR. Folosind fio și teste manuale Știu că matricea poate susține în medie 800 MB/s scrieri secvențiale, acest lucru este bine și în conformitate cu performanța așteptată a acestei matrice. Aparatul este un Ryzen5 Pro 2400 GE (4C/8T, 3,8 GHz boost) cu 32G ECC RAM, unitate de pornire/sistem NVMe și porturi Ethernet 2x10Gbps (Intel x550-T2). Rulez un sistem Arch actualizat cu zfs 2.1.2-1.
Cazul meu de utilizare este o arhivă video de cea mai mare parte (~30G) video scris o dată, citit o dată, comprimat. Am dezactivat o vreme, a stabilit recordsize=1M, a stabilit compresios=off și dedup=off deoarece datele sunt de fapt incompresibile și testarea a arătat o performanță mai slabă cu compresie=lz4 decât oprit în ciuda a ceea ce a spus internetul și nu există date duplicate prin proiectare. Acest bazin este partajat prin intermediul rețelei prin Samba. Mi-am reglat rețeaua și Samba până la punctul în care transferul de la NVMe NTFS pe o mașină Windows la NVMe ext4 ajunge la 1 GB/s, adică destul de aproape de a satura legătura de 10 Gbps cu 9K Jumbo Frames.
Aici mă confrunt cu probleme. Vreau să pot transfera o întreagă arhivă video 30G la 1 GB/s pe raid-z2 matrice care poate suporta doar scriere secvențială de 800 MB/s. Planul meu este să folosesc paginile murdare bazate pe RAM pentru a absorbi spillover-ul și a le lăsa să se întoarcă pe disc după ce transferul este „finalizat” pe partea clientului. M-am gândit că tot ce am nevoie este (1024-800)*30~=7G de pagini murdare din RAM care pot fi eliminate pe disc peste ~10 secunde după finalizarea transferului. Înțeleg implicațiile asupra integrității datelor ale acestui lucru și riscul este acceptabil, deoarece pot oricând să transfer fișierul din nou mai târziu, timp de până la o lună, în cazul în care o pierdere de energie duce la pierderea sau incompletitatea fișierului.
Cu toate acestea, nu pot face ca ZFS să se comporte în modul în care mă aștept... Am editat-o /etc/modprobe.d/zfs.conf fisier asa:
opțiuni zfs zfs_dirty_data_max_max=25769803776
opțiuni zfs zfs_dirty_data_max_max_percent=50
opțiuni zfs zfs_dirty_data_max=25769803776
opțiuni zfs zfs_dirty_data_max_percent=50
opțiuni zfs zfs_delay_min_dirty_percent=80
Am alergat corespunzător mkinitcpio -P comandă pentru a-mi reîmprospăta initramfs și am confirmat că setările au fost aplicate după o repornire:
# arc_summary | grep dirty_data
zfs_dirty_data_max 25769803776
zfs_dirty_data_max_max 25769803776
zfs_dirty_data_max_max_percent 50
zfs_dirty_data_max_percent 50
zfs_dirty_data_sync_percent 20
i.e. Am setat numărul maxim de pagini murdare la 24G, ceea ce este cu mult mai mult decât 7G de care am nevoie, și țin apăsat pentru a începe să întârzie scrierile până când se utilizează 80% din aceasta. Din câte am înțeles, pool-ul ar trebui să poată absorbi 19G în RAM înainte de a începe să respingă scrierile de la client (Samba) cu latență.
Totuși, ceea ce observ scriind de la clientul Windows este că, după aproximativ 16 secunde la viteza de scriere de ~1 GB/s, performanța de scriere scade de pe o stâncă (iostat încă arată discurile care lucrează din greu pentru a spăla datele) despre care pot doar să presupun că este mecanismul de respingere pentru limitarea scrierii a ZFS. Cu toate acestea, acest lucru nu are sens, deoarece cel puțin, chiar dacă nimic nu a fost spălat în cele 16 secunde, ar fi trebuit să se instaleze în 3 secunde mai târziu.În plus, cade din nou la sfârșit, vezi imaginea: [
][https://i.stack.imgur.com/Yd9WH.png]
Am încercat să ajustez zfs_dirty_data_sync_percent să încep să scriu mai devreme, deoarece bufferul paginii murdare este mult mai mare decât valoarea implicită și am încercat, de asemenea, să ajustez scalarea activă a io cu zfs_vdev_async_write_active_{min,max}_dirty_percent pentru a începe și mai devreme pentru a face scrierile la viteză mai rapidă cu tamponul mare murdar. Ambele au mutat ușor poziția stâncii, dar nu aproape de ceea ce mă așteptam.
Întrebări:
- Am înțeles greșit cum funcționează întârzierea de accelerare a scrierii?
- Este posibil ceea ce încerc să fac?
- Dacă da, cu ce greșesc?
Da, știu, urmăresc literalmente câteva secunde și nu voi recupera niciodată efortul depus pentru a realiza acest lucru. E ok, este ceva personal între mine și ZFS în acest moment și o chestiune de principiu ;)
