{"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\/pt\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","title":{"rendered":"Dicas para trabalhar com um grande n\u00famero de pequenos arquivos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A ideia do artigo surgiu espontaneamente de uma discuss\u00e3o nos coment\u00e1rios de um artigo. \u00abAlgo sobre inode\u00bb<\/a><\/noindex>.<\/p>\n

\"Dicas
\n
\nA quest\u00e3o \u00e9 que a especificidade interna do funcionamento dos nossos servi\u00e7os \u00e9 o armazenamento de um n\u00famero enorme de arquivos pequenos. No momento, temos cerca de centenas de terabytes desses dados. E nos deparamos com algumas armadilhas \u00f3bvias e n\u00e3o t\u00e3o \u00f3bvias e passamos por elas com sucesso.<\/p>\n

Por isso, estou compartilhando nossa experi\u00eancia, pode ser \u00fatil para algu\u00e9m.
\n<\/a><\/noindex><\/p>\n

Primeiro problema: \u00abSem espa\u00e7o dispon\u00edvel no dispositivo\u00bb<\/h2>\n

\nComo mencionado no artigo anteriormente citado, o problema \u00e9 que h\u00e1 blocos livres no sistema de arquivos, mas inodes se esgotaram.<\/p>\n

Voc\u00ea pode verificar o n\u00famero de inodes usados e livres com o comando df -ih<\/code>:<\/p>\n

\"Dicas
\n
\nN\u00e3o vou recontar o artigo, em resumo, no disco h\u00e1 tanto blocos diretamente para dados quanto blocos para metainforma\u00e7\u00f5es, os quais s\u00e3o inodes (nodo \u00edndice). O n\u00famero deles \u00e9 definido na inicializa\u00e7\u00e3o do sistema de arquivos (falamos do ext2 e seus sucessores) e n\u00e3o muda depois. O equil\u00edbrio entre blocos de dados e inodes \u00e9 calculado a partir de dados estat\u00edsticos, mas, em nosso caso, onde h\u00e1 muitos arquivos pequenos, o equil\u00edbrio deve se deslocar na dire\u00e7\u00e3o do n\u00famero de inodes \u2014 deve haver mais deles.<\/p>\n

No Linux, j\u00e1 foram previstas variantes com diferentes balan\u00e7os, e todas essas configura\u00e7\u00f5es pr\u00e9-calculadas est\u00e3o no arquivo \/etc\/mke2fs.conf<\/code>.
\nPortanto, na inicializa\u00e7\u00e3o inicial do sistema de arquivos atrav\u00e9s do mke2fs, voc\u00ea pode especificar o perfil desejado.<\/p>\n

Aqui est\u00e3o alguns exemplos do arquivo:<\/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\u00c9 poss\u00edvel selecionar a op\u00e7\u00e3o de uso desejada com a op\u00e7\u00e3o «-T» ao chamar o mke2fs. Tamb\u00e9m \u00e9 poss\u00edvel especificar manualmente os par\u00e2metros necess\u00e1rios, caso n\u00e3o haja uma solu\u00e7\u00e3o pronta.<\/p>\n
Mais detalhes est\u00e3o descritos nos manuais para mke2fs.conf<\/code> e mke2fs<\/code>.<\/p>\n
Uma caracter\u00edstica n\u00e3o abordada no artigo mencionado acima \u00e9 que voc\u00ea pode definir o tamanho do bloco de dados. \u00c9 evidente que para grandes arquivos vale a pena um tamanho de bloco maior; para pequenos, um menor. <\/p>\n
No entanto, vale a pena considerar uma caracter\u00edstica interessante, como a arquitetura do processador.
\nUm tempo atr\u00e1s, pensei que precisava de um tamanho de bloco maior para arquivos grandes de fotos. Era um ambiente dom\u00e9stico, em um armazenamento dom\u00e9stico WD com arquitetura ARM. Sem pensar muito, defini o tamanho do bloco como 8k ou 16k em vez do padr\u00e3o de 4k, depois de medir a economia. E tudo estava \u00f3timo at\u00e9 o momento em que o pr\u00f3prio armazenamento falhou, embora o disco estivesse intacto. Ao colocar o disco em um computador comum com um processador Intel, recebi uma surpresa: tamanho de bloco n\u00e3o suportado. A situa\u00e7\u00e3o ficou complicada. Os dados estavam l\u00e1, tudo bem, mas n\u00e3o era poss\u00edvel ler. Processadores i386 e similares n\u00e3o conseguem trabalhar com tamanhos de bloco que n\u00e3o correspondem ao tamanho da p\u00e1gina de mem\u00f3ria, que \u00e9 exatamente 4k. No geral, a situa\u00e7\u00e3o foi resolvida usando utilit\u00e1rios do espa\u00e7o do usu\u00e1rio, tudo foi lento e triste, mas conseguimos salvar os dados. Para quem tiver interesse - procure pelo nome do utilit\u00e1rio. fuseext2<\/code>. Moral da hist\u00f3ria: ou pense em todos os casos antecipadamente, ou n\u00e3o tente se passar por super-her\u00f3i e use as configura\u00e7\u00f5es padr\u00e3o para donas de casa.<\/p>\n
UPD. Com a observa\u00e7\u00e3o do usu\u00e1rio berez<\/a><\/noindex> esclare\u00e7o que para i386 o tamanho do bloco n\u00e3o deve exceder 4k, mas n\u00e3o necessariamente deve ser exatamente 4k, ou seja, tamanhos de 1k e 2k s\u00e3o permitidos.<\/p>\n
Ent\u00e3o, como n\u00f3s resolvemos os problemas.<\/p>\n
Primeiro, encontramos o problema quando um disco de m\u00faltiplos terabytes estava cheio de dados, e n\u00e3o pod\u00edamos refazer a configura\u00e7\u00e3o do sistema de arquivos.<\/p>\n
Em segundo lugar, a solu\u00e7\u00e3o precisava ser urgente.<\/p>\n
No final, chegamos \u00e0 conclus\u00e3o de que precis\u00e1vamos mudar o equil\u00edbrio, reduzindo o n\u00famero de arquivos.
\nPara reduzir o n\u00famero de arquivos, decidimos compactar os arquivos em um \u00fanico arquivo. Considerando nossa especificidade, agrupamos em um \u00fanico arquivo todos os arquivos de um determinado per\u00edodo e realizamos a arquiva\u00e7\u00e3o com uma tarefa cron diariamente \u00e0 noite.<\/p>\n
Selecionamos o arquivo zip. Nos coment\u00e1rios do artigo anterior, foi sugerido usar tar, mas isso traz uma dificuldade: ele n\u00e3o possui um \u00edndice, e os arquivos est\u00e3o armazenados sequencialmente (n\u00e3o \u00e9 \u00e0 toa que \"tar\" \u00e9 uma abrevia\u00e7\u00e3o de \"Tape Archive\", um legado dos suportes em fita), ou seja, se voc\u00ea precisar ler um arquivo no final do arquivo, ter\u00e1 que ler todo o arquivo, pois n\u00e3o h\u00e1 deslocamentos para cada arquivo em rela\u00e7\u00e3o ao in\u00edcio do arquivo. Portanto, esta \u00e9 uma opera\u00e7\u00e3o demorada. No zip, tudo \u00e9 muito melhor: ele tem o tal \u00edndice e os deslocamentos dos arquivos dentro do arquivo, e o tempo de acesso a cada arquivo n\u00e3o depende de sua localiza\u00e7\u00e3o. E no nosso caso, poder\u00edamos definir a op\u00e7\u00e3o de compacta\u00e7\u00e3o \"0\", pois todos os arquivos j\u00e1 estavam previamente compactados em gzip.<\/p>\n
Os clientes baixam arquivos atrav\u00e9s do nginx e, de acordo com a API antiga, basta informar o nome do arquivo, por exemplo:<\/p>\n
http:\/\/www.server.com\/hydra\/20170416\/0453\/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5\n<\/code><\/pre>\n
\nPara descompactar arquivos on-the-fly, encontramos e conectamos o m\u00f3dulo nginx-unzip-module (https:\/\/github.com\/youzee\/nginx-unzip-module<\/a><\/noindex>) e configuramos dois upstreams.<\/p>\n
O resultado foi uma configura\u00e7\u00e3o como esta:<\/p>\n
\"Dicas
\n
\nOs dois hosts nas configura\u00e7\u00f5es eram assim:<\/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 a configura\u00e7\u00e3o dos upstreams no nginx superior:<\/p>\n
upstream storage {\n  server server.com:8081;\n  server server.com:8082;\n}\n<\/code><\/pre>\n
\nComo funciona:<\/p>\n