{"id":36999,"date":"2019-10-31T22:15:13","date_gmt":"2019-10-31T19:15:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov\/"},"modified":"2019-10-31T22:15:13","modified_gmt":"2019-10-31T19:15:13","slug":"haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","title":{"rendered":"Suggerimenti per lavorare con un gran numero di file di piccole dimensioni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'idea dell'articolo \u00e8 nata spontaneamente da una discussione nei commenti a un articolo. \u00abQualcosa su inode\u00bb<\/a><\/noindex>.<\/p>\n

\"Suggerimenti
\n
\nIl punto \u00e8 che la nostra infrastruttura prevede il salvataggio di enormi quantit\u00e0 di piccoli file. Attualmente abbiamo circa centinaia di terabyte di dati. E abbiamo incontrato alcune ovvie e non cos\u00ec ovvie problematiche e le abbiamo affrontate con successo.<\/p>\n

Perci\u00f2 condivido la nostra esperienza, potrebbe essere utile a qualcuno.
\n<\/a><\/noindex><\/p>\n

Primo problema: \u00abNo space left on device\u00bb<\/h2>\n

\nCome accennato nell'articolo precedente, il problema \u00e8 che ci sono blocchi liberi nel filesystem, ma gli inode sono esauriti.<\/p>\n

Puoi controllare il numero di inode utilizzati e disponibili con il comando df -ih<\/code>:<\/p>\n

\"Suggerimenti
\n
\nNon voglio ripetere l'articolo, ma in breve, su un disco ci sono sia blocchi per i dati sia blocchi per le informazioni meta, ovvero gli inode (index node). Il loro numero \u00e8 fissato al momento dell'inizializzazione del filesystem (si parla di ext2 e dei suoi discendenti) e non cambia in seguito. L'equilibrio tra i blocchi dati e gli inode \u00e8 calcolato sulla base di dati statistici medi; nel nostro caso, avendo molti piccoli file, l'equilibrio dovrebbe spostarsi a favore del numero di inode \u2014 devono essercene di pi\u00f9.<\/p>\n

In Linux sono gi\u00e0 previste opzioni con diversi equilibri, e tutte queste configurazioni precalcolate si trovano nel file \/etc\/mke2fs.conf<\/code>.
\nPertanto, durante l'inizializzazione del filesystem tramite mke2fs, \u00e8 possibile specificare il profilo desiderato.<\/p>\n

Ecco alcuni esempi dal file:<\/p>\n

    small = {\n        blocksize = 1024\n        inode_size = 128\n        inode_ratio = 4096\n    }\n\n    big = {\n        inode_ratio = 32768\n    }\n\n    largefile = {\n        inode_ratio = 1048576\n        blocksize = -1\n    }\n<\/code><\/pre>\n
\n\u00c8 possibile scegliere l'opzione di utilizzo desiderata con l'opzione «-T» durante la chiamata a mke2fs. \u00c8 anche possibile specificare manualmente i parametri desiderati, se non ci sono soluzioni pronte.<\/p>\n
Maggiore dettagli sono descritti nei manuali per mke2fs.conf<\/code> e mke2fs<\/code>.<\/p>\n
Una caratteristica non trattata nell'articolo precedente \u00e8 che si pu\u00f2 specificare la dimensione del blocco dati. Ovviamente, per file di grandi dimensioni ha senso avere blocchi pi\u00f9 grandi, per file piccoli, invece, \u00e8 meglio avere blocchi pi\u00f9 piccoli. <\/p>\n
Tuttavia, \u00e8 importante tenere conto di una caratteristica interessante: l'architettura della CPU.
\nIn un certo momento, ho pensato che per i grandi file di foto avessi bisogno di un blocco pi\u00f9 grande. Era tutto a casa, su un NAS WD con architettura ARM. Non ci ho pensato due volte e ho impostato la dimensione del blocco a 8k o 16k invece del standard 4k, dopo aver misurato il risparmio. E tutto funzionava perfettamente fino al momento in cui il NAS si guast\u00f2, anche se il disco era integro. Mettendo il disco in un PC normale con un processore Intel, ho ricevuto una sorpresa: dimensione del blocco non supportata. Non ci siamo riusciti. I dati ci sono, tutto bene, ma non si possono leggere. I processori i386 e simili non possono gestire dimensioni di blocco che non corrispondono alla dimensione della pagina di memoria, la quale \u00e8 esattamente 4k. Alla fine, abbiamo dovuto usare utilit\u00e0 dal user space; \u00e8 stato tutto lento e triste, ma i dati sono stati salvati. Chi \u00e8 interessato \u2014 google per il nome dell\u2019utilit\u00e0 fuseext2<\/code>. Morale: o pianificate tutto in anticipo, o non comportatevi da supereroe e usate le impostazioni standard per le casalinghe.<\/p>\n
UPD. A seguito del commento dell'utente berez<\/a><\/noindex> preciso che per i386 la dimensione del blocco non deve superare 4k, ma non deve necessariamente essere esattamente 4k, quindi sono ammissibili anche 1k e 2k.<\/p>\n
Dunque, come abbiamo risolto i problemi.<\/p>\n
Innanzitutto, ci siamo trovati di fronte al problema quando un disco multimille terabyte era pieno di dati, e non potevamo modificare la configurazione del filesystem.<\/p>\n
In secondo luogo, era necessario trovare una soluzione urgente.<\/p>\n
Alla fine, abbiamo concluso che dovevamo cambiare l'equilibrio, riducendo il numero di file.
\nPer ridurre il numero di file, abbiamo deciso di raggruppare i file in un unico archivio. Considerando la nostra specificit\u00e0, abbiamo accorpato in un solo archivio tutti i file di un certo lasso di tempo, eseguendo la compressione con un'attivit\u00e0 cron giornaliera di notte.<\/p>\n
Abbiamo scelto l'archivio zip. Nei commenti all'articolo precedente era stato suggerito tar, ma con esso c'\u00e8 una difficolt\u00e0: non ha un indice e i file sono memorizzati in modo continuo (non a caso \u00abtar\u00bb \u00e8 un'abbreviazione per \u00abTape Archive\u00bb, eredit\u00e0 dei supporti a nastro), cio\u00e8, se devi leggere un file alla fine dell'archivio, devi leggere tutto l'archivio, poich\u00e9 non ci sono offset per ogni file rispetto all'inizio dell'archivio. Pertanto, \u00e8 un'operazione lunga. Con zip \u00e8 tutto molto meglio: ha un indice e offset dei file all'interno dell'archivio, e il tempo di accesso a ogni file non dipende dalla sua posizione. Inoltre, nel nostro caso, \u00e8 possibile specificare l'opzione di compressione \u00ab0\u00bb, poich\u00e9 tutti i file erano gi\u00e0 stati compressi in gzip.<\/p>\n
I clienti scaricano i file tramite nginx, e secondo il vecchio API, viene semplicemente indicato il nome del file, ad esempio:<\/p>\n
http:\/\/www.server.com\/hydra\/20170416\/0453\/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5\n<\/code><\/pre>\n
\nPer estrarre i file al volo, abbiamo trovato e integrato il modulo nginx-unzip-module (https:\/\/github.com\/youzee\/nginx-unzip-module<\/a><\/noindex>) e configurato due upstream.<\/p>\n
Il risultato \u00e8 stata la seguente configurazione:<\/p>\n
\"Suggerimenti
\n
\nDue host nelle impostazioni apparivano cos\u00ec:<\/p>\n
server {\n  listen *:8081;\n\n  location \/ {\n    root      \/home\/filestorage;\n  }\n}<\/code><\/pre>\n
<\/p>\n
server {\n  listen *:8082;\n\n  location ~ ^\/hydra\/(d+)\/(\\d+)\/(.+)$ {\n    root      \/home\/filestorage;\n    file_in_unzip_archivefile \"\/home\/filestorage\/hydra\/$1\/$2.zip\";\n    file_in_unzip_extract \"$2\/$3\";\n    file_in_unzip;\n  }\n}\n<\/code><\/pre>\n
\nE la configurazione degli upstream sul nginx superiore:<\/p>\n
upstream storage {\n  server server.com:8081;\n  server server.com:8082;\n}\n<\/code><\/pre>\n
\nCome funziona:<\/p>\n