Ho un server di backup Ubuntu 16.04 con HDD 8x10TB tramite un backplane SATA 3.0. Gli 8 Hard Disk sono assemblati su un RAID6, è in uso un filesystem EXT4. Questo filesystem memorizza un'enorme quantità di piccoli file con moltissime operazioni SEEK ma un throughput IO basso. In effetti, ci sono molti piccoli file da diversi server che vengono scansionati ogni giorno tramite rsnapshot (più INODI diretti agli stessi file. Ho prestazioni molto scarse poiché il file system (60 TB netto) ha superato il 50% di utilizzo. Al momento, il l'utilizzo è al 75% e a

du -sch /backup-root/

richiede diversi giorni (!). La macchina ha 8 core e 16G di RAM. La RAM è totalmente utilizzata dalla cache del filesystem del sistema operativo, 7 core su 8 sono sempre inattivi a causa di IOWAIT.

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

Mi manca l'esperienza con questo tipo di utilizzo del filesystem. Quali opzioni devo mettere a punto. Quale filesystem avrebbe prestazioni migliori con questo scenario? Esistono opzioni per coinvolgere la RAM per altre opzioni di memorizzazione nella cache rispetto a quella integrata nel sistema operativo?

Come gestite grandi quantità di piccoli file su assiemi RAID di grandi dimensioni?

Grazie Sebastian

Ho una configurazione simile (anche se più piccola), con dischi 12x 2 TB in un array RAID6, utilizzata per lo stesso scopo ( rsnapshotserver di backup).

Innanzitutto, è perfettamente normale du -hsimpiegare così tanto tempo su un file system così grande e usato. Inoltre dutiene conto degli hardlink, che causano un carico della CPU considerevole ed esplosivo oltre all'ovvio carico di IO.

La tua lentezza è dovuta al fatto che i metadati del filesystem si trovano in blocchi molto distanti (in termini LBA), causando molte ricerche. Poiché un normale disco RPM da 7,2 K fornisce circa 100 IOPS, è possibile vedere come sono necessarie ore, se non giorni, per caricare tutti i metadati.

Qualcosa che puoi provare per (non distruttivamente) migliorare la situazione:

• assicurati di non avere mlocate/slocateindicizzato il tuo /backup-root/(puoi usare la funzione prunefs per evitarlo), altrimenti il cestino della cache dei metadati comprometterà gravemente il tuo tempo di backup;
• per lo stesso motivo, evitare di correre dusu /backup-root/. Se necessario, esegui dusolo la sottocartella specifica interessata;
• inferiore vfs_cache_pressuredal valore predefinito (100) a uno più conservativo (10 o 20). Questo indicherà al kernel di preferire la memorizzazione nella cache dei metadati, piuttosto che la memorizzazione nella cache dei dati; questo dovrebbe, a sua volta, accelerare la rsnapshot/rsyncfase di scoperta;
• puoi provare ad aggiungere un dispositivo di memorizzazione nella cache dei metadati, ad esempio tramite lvmcache o bcache . Questo dispositivo di metadati dovrebbe ovviamente essere un SSD;
• aumenta la tua RAM disponibile.
• mentre usi ext4, fai attenzione ai problemi di allocazione degli inode (leggi qui per un esempio). Questo non è direttamente correlato alle prestazioni, ma è un fattore importante quando si hanno così tanti file su un filesystem basato su ext.

Altre cose che puoi provare - ma queste sono operazioni distruttive:

• usa XFS con entrambi -ftypee -finobtset di opzioni;
• usa ZFS su Linux (ZoL) con ARC e primarycache=metadataimpostazione compressi (e, forse, un L2ARC per cache di sola lettura).

Questo filesystem memorizza un'enorme quantità di piccoli file con moltissime operazioni SEEK ma un throughput IO basso.

🎉

Questa è la cosa che cattura molte persone al giorno d'oggi. Purtroppo, le FS convenzionali non si adattano bene qui. Posso darti probabilmente solo alcuni consigli quando si tratta della configurazione che hai già: EXT4 su RAID-6 su HDD :

1. Più in vm.vfs_cache_pressurebasso, diciamo a 1. Cambia il pregiudizio della cache per preservare più metadati (inode, dentry) invece dei dati stessi e dovrebbe avere un effetto positivo nel ridurre il numero di ricerche
2. Aggiungi più RAM . Sebbene possa sembrare strano per un server che non esegue alcuna app piggy, ricorda: l'unico modo per ridurre le ricerche è mantenere più metadati in uno spazio di archiviazione più veloce, dato che hai solo 16 GB sembra che dovrebbe essere relativamente facile da aumentare la quantità di RAM
3. Come ho detto, EXT4 non è una buona scelta per il caso d'uso che hai, ma puoi comunque utilizzare alcune delle funzionalità che esso offre per lenire il dolore:
   • il journal esterno è supportato in modo da poter provare ad aggiungere SSD (meglio rispecchiato) e posizionare lì il journal. Dai un'occhiata a " ext4: avvertenze sui journal esterni "
   • Prova a cambiare la modalità journal con "montaggio su journaling di tutti i dati"data=journal
4. Prova a spostare i file al di fuori del singolo ambito FS . Ad esempio, se hai LVM-2 qui puoi creare volumi di dimensioni inferiori e usarli per un momento, quindi quando si riempie, creane uno nuovo e così via.
   • Se non hai LVM-2 puoi provare a farlo con / dev / loop ma non è così conveniente e probabilmente meno performante

UPD. : dal momento che si è rivelato essere RAID-6 RAID software Linux (LSR), ecco l'articolo aggiuntivo:

5. L'LSR ha le proprie opzioni di ottimizzazione che molte persone sembrano trascurare
   • Stripe cache , che può essere impostata così al massimo: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- Ma fai questo con cura (usa un valore inferiore se necessario) poiché la dimensione è multipla di dimensione di blocco e in base alla dimensione di blocco che hai scelto, ci vorrebbe una quantità diversa di RAM
   • Diario esterno che può essere anche su quegli SSD con mirroring ( ma attualmente il dispositivo MD creato senza diario non può essere convertito per usarne uno ).

- Questo è probabilmente la maggior parte di ciò che può essere migliorato senza riprogettazione ex novo.

Ho prestazioni molto scadenti poiché il file system (60 TB netti) ha superato il 50% di utilizzo. Al momento l'utilizzo è al 75%

Questo è un problema molto serio perché quell'alto livello di occupazione dello spazio su disco ha solo peggiorato la frammentazione. E più frammentazione significa più ricerche. Non chiedo più perché abbia dato prestazioni più o meno accettabili prima di raggiungere il 50%. Molti manuali hanno chiari consigli per non consentire alle FS di crescere oltre il 75-80%.

RAID6 non ti aiuta molto in questo caso, qualcosa come ZFS potrebbe consentire metadati e accesso alla directory molto più rapidi mantenendo velocità allo stesso modo.

Unità a strisce RAID-6, quindi tutto l'IO va a tutte le unità. È piuttosto inefficiente con molti piccoli file. Tuttavia, questo probabilmente non è il tuo problema principale che è ...

Ext4 non è adatto per file system di grandi dimensioni con milioni di file. Usa XFS . Ho un filesystem XFS che corre fino a 1,2 PB e con un massimo di 1 miliardo di file, nessun problema. Usa semplicemente XFS .

Grazie a tutti coloro che hanno dato una risposta alla mia domanda.

Ecco come l'ho risolto:

Prima di tutto, ho aggiunto la quantità massima di RAM alla scheda. Sfortunatamente, la scheda supporta solo fino a 64 GB di RAM. Ho osservato il comportamento dopo l'espansione ed è stato deludente. Sebbene tutta la RAM disponibile sia stata utilizzata per la cache IO, le prestazioni del backup RSNAPSHOT non sono migliorate in modo misurabile.

Quindi ho dovuto tirare la grande mazza. Ho aggiunto due dischi NVME da 1 TB e li ho assemblati in un RAID 1. Il RAID 6 composto da 8 HDD da 10 TB è stato smontato in un RAID 1 (composto da 2x HDD da 10 TB, ext4) e un RAID 5 (costituito da HDD da 6x10 TB). Il RAID 1 ora contiene il sistema operativo e la copia funzionante dei server (che vengono sincronizzati 4 volte al giorno su questa unità).

Il RAID5 è ora un dispositivo con supporto BCACHE, supportato da NVME-RAID 1 e formattato con ext4. Questa unità contiene le copie RSNAPSHOT. Ogni notte, i file vengono sincronizzati da RAID1 a RAID5, il che dimezza il throughput IO di RAID5 rispetto al precedente RAID6, che conteneva le copie funzionanti E gli snapshot di backup. Grazie a BCache, non tutti i singoli file vengono letteralmente scritti sui dischi, ma tutte le modifiche su un blocco vengono scritte una volta, anche se contiene diverse modifiche ai singoli file. Ciò ha ulteriormente ridotto gli IOps sugli HDD.

Infine, ho modificato la mia configurazione di RSnapshot. In precedenza, c'erano 31 snapshot giornalieri e 18 snapshot mensili, che hanno portato a 49 generazioni di backup. Ora, ho il classico 7d / 4w / 12m / 1y-Design, che riduce il numero di generazioni di backup fino a 24.

Dopo queste modifiche (e con la RAM da 64 GB menzionata sopra), la durata di un'istantanea è scesa da ~ 20 ore a 1,5 ore. I dispositivi BCache hanno un tasso di hit della cache dell'82% (dopo 6 settimane di funzionamento regolare).

Missione compiuta. Grazie a tutti voi per i vostri pensieri e input.