{"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":"Trucchi per lavorare con un gran numero di piccoli file","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

\"Trucchi
\n
\nIl fatto \u00e8 che la specificit\u00e0 interna del lavoro dei nostri servizi \u00e8 la memorizzazione di un'enorme quantit\u00e0 di file di piccole dimensioni. Attualmente abbiamo circa centinaia di terabyte di questi dati. E ci siamo imbattuti in alcune ovvie e non cos\u00ec evidenti insidie e le abbiamo affrontate con successo.<\/p>\n

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

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

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

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

\"Trucchi
\n
\nNon ripeter\u00f2 l'articolo, in breve, sul disco ci sono sia blocchi per i dati che blocchi per la meta-informazione, questi ultimi sono gli inode (index node). Il loro numero \u00e8 definito al momento dell'inizializzazione del filesystem (si parla di ext2 e dei suoi eredi) e non cambia pi\u00f9. L'equilibrio tra i blocchi di dati e gli inode \u00e8 calcolato su dati medi, nel nostro caso, avendo molti file di piccole dimensioni, l'equilibrio deve spostarsi verso il numero di inode\u2014ce ne devono essere di pi\u00f9.<\/p>\n

In Linux hanno gi\u00e0 previsto varianti con diversi equilibri, e tutte queste configurazioni pre-calcolate si trovano nel file \/etc\/mke2fs.conf<\/code>.
\nPertanto, durante l'inizializzazione iniziale 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 inoltre possibile specificare manualmente i parametri necessari se non \u00e8 disponibile una soluzione pronta.<\/p>\n
Maggiori dettagli sono descritti nei manuali per mke2fs.conf<\/code> e mke2fs<\/code>.<\/p>\n
Una peculiarit\u00e0 non trattata nell'articolo sopra citato \u00e8 che \u00e8 possibile specificare la dimensione del blocco dati. \u00c8 evidente che per file di grandi dimensioni \u00e8 sensato avere una dimensione del blocco maggiore, per i file piccoli, invece, una dimensione minore. <\/p>\n
Tuttavia, \u00e8 importante considerare una caratteristica interessante, come l'architettura del processore.
\nUn giorno mi sono reso conto che per grandi file fotografici avevo bisogno di una dimensione di blocco pi\u00f9 grande. Era tutto in un ambiente domestico, su un'unit\u00e0 di archiviazione domestica WD basata su architettura ARM. Senza pensarci troppo, ho impostato la dimensione del blocco a 8k o 16k invece del normale 4k, dopo aver misurato i risparmi. E tutto andava benissimo fino al momento in cui l'unit\u00e0 di archiviazione non ha smesso di funzionare, mentre il disco era sano. Mettendo il disco in un computer normale con un normale processore Intel, ho ricevuto una sorpresa: dimensione del blocco non supportata. Eccoci. I dati ci sono, tutto bene, ma non si possono leggere. I processori i386 e simili non possono lavorare con dimensioni di blocco che non corrispondono alla dimensione di pagina della memoria, e questa \u00e8 esattamente 4k. Insomma, la faccenda si \u00e8 conclusa con l'uso di utility nello spazio utente, tutto \u00e8 stato lento e triste, ma i dati sono stati salvati. Chi \u00e8 interessato, cerchi per nome dell'utilit\u00e0 fuseext2<\/code>. Morale: o pensare a tutti i casi in anticipo, o non comportarsi da supereroe e utilizzare le impostazioni standard per le casalinghe.<\/p>\n
UPD. A seguito dell'osservazione dell'utente berez<\/a><\/noindex> specifico che per i386 la dimensione del blocco non deve superare 4k, ma non deve necessariamente essere esattamente 4k, quindi sono ammesse anche 1k e 2k.<\/p>\n
Quindi, come abbiamo risolto i problemi.<\/p>\n
Innanzitutto, ci siamo imbattuti nel problema quando un disco da molti terabyte era pieno di dati e non potevamo modificare la configurazione del file system.<\/p>\n
In secondo luogo, era necessaria una soluzione urgente.<\/p>\n
Alla fine, abbiamo concluso che era necessario cambiare l'equilibrio, riducendo il numero di file.
\nPer ridurre il numero di file, \u00e8 stato deciso di raggrupparli in un unico archivio. Considerando la nostra specificit\u00e0, abbiamo raggruppato in un unico archivio tutti i file per un certo intervallo di tempo, eseguendo l'archiviazione tramite un compito cron ogni notte.<\/p>\n
\u00c8 stato selezionato un archivio zip. Nei commenti all'articolo precedente era stato suggerito il tar, ma con esso c\u2019\u00e8 una difficolt\u00e0: non ha un indice e i file sono disposti in modo sequenziale (non a caso \u00abtar\u00bb \u00e8 un'abbreviazione di \u00abTape Archive\u00bb, un'eredit\u00e0 dei nastri di memoria), cio\u00e8 se \u00e8 necessario leggere un file alla fine dell'archivio, \u00e8 necessario leggere tutto l'archivio, poich\u00e9 non ci sono offset per ogni file rispetto all'inizio dell'archivio. Quindi \u00e8 un'operazione lunga. In zip \u00e8 tutto molto migliore: ha quel famoso indice e offset dei file all\u2019interno dell\u2019archivio, e il tempo di accesso a ciascun file non dipende dalla sua posizione. Inoltre, nel nostro caso era possibile impostare l'opzione di compressione \u00ab0\u00bb, poich\u00e9 tutti i file erano gi\u00e0 stati compressi in gzip.<\/p>\n
I clienti prelevano i file tramite nginx e, secondo il vecchio API, basta specificare il nome del file, per esempio in questo modo:<\/p>\n
http:\/\/www.server.com\/hydra\/20170416\/0453\/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5\n<\/code><\/pre>\n
\nPer decomprimere i file al volo, abbiamo trovato e collegato il modulo nginx-unzip-module (https:\/\/github.com\/youzee\/nginx-unzip-module<\/a><\/noindex>) e abbiamo configurato due upstream.<\/p>\n
Il risultato \u00e8 stata la seguente configurazione:<\/p>\n
\"Trucchi
\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+)\/(\n  \ny) {\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 nel 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