{"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\/fr\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","title":{"rendered":"Astuces pour travailler avec un grand nombre de petits fichiers","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'id\u00e9e de cet article est n\u00e9e spontan\u00e9ment d'une discussion dans les commentaires d'un article. \u00abQuelques informations sur l'inode\u00bb<\/a><\/noindex>.<\/p>\n

\"Astuces
\n
\nEn effet, la sp\u00e9cificit\u00e9 interne du fonctionnement de nos services est de stocker un nombre consid\u00e9rable de petits fichiers. Actuellement, nous avons environ des centaines de t\u00e9raoctets de ces donn\u00e9es. Nous avons rencontr\u00e9 quelques pi\u00e8ges \u00e9vidents et moins \u00e9vidents et avons r\u00e9ussi \u00e0 naviguer \u00e0 travers eux.<\/p>\n

C'est pourquoi je partage notre exp\u00e9rience, cela pourrait \u00eatre utile \u00e0 quelqu'un.
\n<\/a><\/noindex><\/p>\n

Premier probl\u00e8me : \u00abAucun espace disponible sur le p\u00e9riph\u00e9rique\u00bb<\/h2>\n

\nComme mentionn\u00e9 dans l'article ci-dessus, le probl\u00e8me est qu'il y a des blocs libres dans le syst\u00e8me de fichiers, mais les inodes sont \u00e9puis\u00e9s.<\/p>\n

Le nombre d'inodes utilis\u00e9s et libres peut \u00eatre v\u00e9rifi\u00e9 avec la commande df -ih<\/code>:<\/p>\n

\"Astuces
\n
\nJe ne vais pas r\u00e9sumer l'article, en bref, sur le disque, il y a \u00e0 la fois des blocs pour les donn\u00e9es directement, ainsi que des blocs pour les m\u00e9tadonn\u00e9es, appel\u00e9s inodes (noeud d'index). Leur nombre est d\u00e9fini lors de l'initialisation du syst\u00e8me de fichiers (il s'agit d'ext2 et de ses descendants) et ne change pas par la suite. L'\u00e9quilibre entre les blocs de donn\u00e9es et les inodes est calcul\u00e9 \u00e0 partir des donn\u00e9es moyennes, dans notre cas, avec de nombreux petits fichiers, cet \u00e9quilibre doit pencher du c\u00f4t\u00e9 du nombre d'inodes \u2014 il doit y en avoir plus.<\/p>\n

Linux a d\u00e9j\u00e0 pr\u00e9vu des options avec un \u00e9quilibre diff\u00e9rent, et toutes ces configurations pr\u00e9d\u00e9finies se trouvent dans le fichier \/etc\/mke2fs.conf<\/code>.
\nAinsi, lors de l'initialisation initiale du syst\u00e8me de fichiers via mke2fs, vous pouvez sp\u00e9cifier le profil n\u00e9cessaire.<\/p>\n

Voici quelques exemples extraits du fichier :<\/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
\nVous pouvez choisir le bon cas d'utilisation avec l'option «-T» lors de l'appel \u00e0 mke2fs. Vous pouvez \u00e9galement d\u00e9finir manuellement les param\u00e8tres n\u00e9cessaires si aucune solution pr\u00eate \u00e0 l'emploi n'est disponible.<\/p>\n
Davantage de d\u00e9tails sont d\u00e9crits dans les manuels pour mke2fs.conf<\/code> et mke2fs<\/code>.<\/p>\n
Une caract\u00e9ristique non abord\u00e9e dans l'article ci-dessus est qu'il est possible de d\u00e9finir la taille des blocs de donn\u00e9es. \u00c9videmment, pour les grands fichiers, il est logique d'avoir une plus grande taille de bloc, pour les petits fichiers \u2014 une plus petite. <\/p>\n
Cependant, il convient de prendre en compte une caract\u00e9ristique int\u00e9ressante : l'architecture du processeur.
\nUn jour, je me suis rendu compte que j'avais besoin d'une taille de bloc plus grande pour les gros fichiers photo. C'\u00e9tait dans un contexte domestique, sur un serveur de fichiers domestique WD bas\u00e9 sur l'architecture ARM. Sans trop r\u00e9fl\u00e9chir, j'ai d\u00e9fini la taille de bloc sur 8k ou 16k au lieu de 4k, apr\u00e8s avoir mesur\u00e9 les \u00e9conomies r\u00e9alis\u00e9es. Tout allait bien jusqu'\u00e0 ce que le serveur tombe en panne, alors que le disque \u00e9tait toujours fonctionnel. En pla\u00e7ant le disque dans un ordinateur classique avec un processeur Intel ordinaire, j'ai eu la surprise de d\u00e9couvrir que la taille de bloc n'\u00e9tait pas prise en charge. Les donn\u00e9es \u00e9taient l\u00e0, tout allait bien, mais il \u00e9tait impossible de les lire. Les processeurs i386 et similaires ne peuvent pas travailler avec des tailles de bloc qui ne correspondent pas \u00e0 la taille de la page m\u00e9moire, qui est exactement de 4k. En somme, cela a fini par n\u00e9cessiter l'utilisation d'outils de l'espace utilisateur, tout \u00e9tait lent et triste, mais nous avons r\u00e9cup\u00e9r\u00e9 les donn\u00e9es. Pour ceux que cela int\u00e9resse \u2014 recherchez le nom de l'outil fuseext2<\/code>. La morale de l'histoire : soit anticiper tous les cas \u00e0 l'avance, soit ne pas se prendre pour un super-h\u00e9ros et utiliser les param\u00e8tres standard pour les utilisateurs moyens.<\/p>\n
UPD. Suite \u00e0 la remarque d'un utilisateur berez<\/a><\/noindex> , je pr\u00e9cise que pour i386, la taille du bloc ne doit pas d\u00e9passer 4k, mais elle n'a pas besoin d'\u00eatre rigoureusement de 4k, donc des tailles de 1k et 2k sont acceptables.<\/p>\n
Alors, comment avons-nous r\u00e9solu les probl\u00e8mes ?<\/p>\n
Tout d'abord, nous avons rencontr\u00e9 le probl\u00e8me lorsque le disque multi-t\u00e9rabyte \u00e9tait plein de donn\u00e9es, et que nous ne pouvions pas modifier la configuration du syst\u00e8me de fichiers.<\/p>\n
Deuxi\u00e8mement, une solution imm\u00e9diate \u00e9tait n\u00e9cessaire.<\/p>\n
En fin de compte, nous en sommes venus \u00e0 la conclusion qu'il fallait r\u00e9tablir l'\u00e9quilibre en r\u00e9duisant le nombre de fichiers.
\nPour diminuer le nombre de fichiers, il a \u00e9t\u00e9 d\u00e9cid\u00e9 de regrouper les fichiers dans une seule archive. Compte tenu de notre sp\u00e9cificit\u00e9, nous avons regroup\u00e9 dans une seule archive tous les fichiers sur une certaine p\u00e9riode, et nous avons effectu\u00e9 l'archivage via une t\u00e2che cron chaque nuit.<\/p>\n
Nous avons choisi le zip. Dans les commentaires de l'article pr\u00e9c\u00e9dent, un tar \u00e9tait propos\u00e9, mais il y a une difficult\u00e9 : il n'a pas de table des mati\u00e8res, et les fichiers y sont stock\u00e9s de mani\u00e8re s\u00e9quentielle (ce n'est pas par hasard que \u00ab tar \u00bb est l'abr\u00e9viation de \u00ab Tape Archive \u00bb, un h\u00e9ritage des lecteurs \u00e0 bande), c'est-\u00e0-dire que si vous devez lire un fichier \u00e0 la fin de l'archive, vous devez lire toute l'archive, car il n'y a pas de d\u00e9calages pour chaque fichier par rapport au d\u00e9but de l'archive. Cela rend l'op\u00e9ration longue. Avec le zip, tout est beaucoup mieux : il a cette table des mati\u00e8res et des d\u00e9calages de fichiers \u00e0 l'int\u00e9rieur de l'archive, et le temps d'acc\u00e8s \u00e0 chaque fichier ne d\u00e9pend pas de sa position. De plus, dans notre cas, nous pouvions d\u00e9finir l'option de compression \u00e0 \u00ab 0 \u00bb, car tous les fichiers avaient d\u00e9j\u00e0 \u00e9t\u00e9 compress\u00e9s avec gzip.<\/p>\n
Les clients r\u00e9cup\u00e8rent les fichiers via nginx, et selon l'ancienne API, il suffit d'indiquer simplement le nom du fichier, par exemple :<\/p>\n
http:\/\/www.server.com\/hydra\/20170416\/0453\/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5\n<\/code><\/pre>\n
\nPour d\u00e9compresser les fichiers \u00e0 la vol\u00e9e, nous avons trouv\u00e9 et connect\u00e9 le module nginx-unzip-module (https:\/\/github.com\/youzee\/nginx-unzip-module<\/a><\/noindex>) et configur\u00e9 deux upstreams.<\/p>\n
Le r\u00e9sultat a donn\u00e9 cette configuration :<\/p>\n
\"Astuces
\n
\nLes deux h\u00f4tes dans les param\u00e8tres \u00e9taient comme suit :<\/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
\nEt la configuration des upstreams sur le nginx en amont :<\/p>\n
upstream storage {\n  server server.com:8081;\n  server server.com:8082;\n}\n<\/code><\/pre>\n
\nComment \u00e7a fonctionne :<\/p>\n