{"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\/es\/blog\/administrirovanie\/haki-pri-rabote-s-bolshim-chislom-melkih-fajlov","title":{"rendered":"Trucos para trabajar con un gran n\u00famero de archivos peque\u00f1os","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La idea del art\u00edculo surgi\u00f3 espont\u00e1neamente de una discusi\u00f3n en los comentarios de un art\u00edculo. \u00abAlgo sobre inode\u00bb<\/a><\/noindex>.<\/p>\n

\"Trucos
\n
\nEl hecho es que la peculiaridad interna del funcionamiento de nuestros servicios es el almacenamiento de una enorme cantidad de archivos peque\u00f1os. En este momento tenemos alrededor de cientos de terabytes de esos datos. Y nos encontramos con algunas obvias e inesperadas dificultades y hemos logrado superarlas.<\/p>\n

Por eso comparto nuestra experiencia, tal vez le sirva a alguien.
\n<\/a><\/noindex><\/p>\n

Primer problema: \u00abNo hay espacio disponible en el dispositivo\u00bb<\/h2>\n

\nComo se mencion\u00f3 en el art\u00edculo anteriormente citado, el problema es que hay bloques libres en el sistema de archivos, pero los inodes se han agotado.<\/p>\n

Se puede verificar el n\u00famero de inodes usados y libres con el comando df -ih<\/code>:<\/p>\n

\"Trucos
\n
\nNo voy a resumir el art\u00edculo, en breve, en el disco hay tanto bloques para datos como bloques para metainformaci\u00f3n, que son los inodes (nodo de \u00edndice). Su cantidad se establece al inicializar el sistema de archivos (hablando de ext2 y sus sucesores) y no cambia despu\u00e9s. El equilibrio entre bloques de datos e inodes se calcula a partir de datos promedio, en nuestro caso, cuando hay muchos archivos peque\u00f1os, el equilibrio debe inclinarse hacia un mayor n\u00famero de inodes.<\/p>\n

En Linux ya se han previsto opciones con diferentes equilibrados, y todas estas configuraciones precalculadas se encuentran en el archivo \/etc\/mke2fs.conf<\/code>.
\nPor lo tanto, al inicializar el sistema de archivos mediante mke2fs, se puede especificar el perfil necesario.<\/p>\n

Aqu\u00ed hay algunos ejemplos del archivo:<\/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
\nPuedes seleccionar la opci\u00f3n de uso requerida con el par\u00e1metro «-T» al invocar mke2fs. Tambi\u00e9n puedes especificar manualmente los par\u00e1metros necesarios si no hay una soluci\u00f3n lista.<\/p>\n
M\u00e1s detalles se describen en los manuales para mke2fs.conf<\/code> y mke2fs<\/code>.<\/p>\n
Una caracter\u00edstica que no se mencion\u00f3 en el art\u00edculo anteriormente citado es que se puede establecer el tama\u00f1o del bloque de datos. Es evidente que para archivos grandes tiene sentido utilizar un tama\u00f1o de bloque mayor, mientras que para archivos peque\u00f1os, uno menor. <\/p>\n
Sin embargo, es importante tener en cuenta una caracter\u00edstica interesante, como la arquitectura del procesador.
\nEn su momento, pens\u00e9 que necesitaba un tama\u00f1o de bloque m\u00e1s grande para grandes archivos de fotos. Esto ocurri\u00f3 en un entorno dom\u00e9stico, en un almacenamiento de archivos de WD en arquitectura ARM. Sin pensarlo mucho, configur\u00e9 el tama\u00f1o de bloque a 8k o 16k en lugar del est\u00e1ndar de 4k, habiendo medido previamente el ahorro. Todo funcion\u00f3 perfectamente hasta que el propio almacenamiento fall\u00f3, aunque el disco segu\u00eda funcionando. Al colocar el disco en una computadora normal con un procesador Intel est\u00e1ndar, recib\u00ed una sorpresa: tama\u00f1o de bloque no soportado. Los datos estaban ah\u00ed, todo bien, pero no se pod\u00edan leer. Los procesadores i386 y similares no pueden trabajar con tama\u00f1os de bloque que no correspondan al tama\u00f1o de la p\u00e1gina de memoria, que es exactamente 4k. En resumen, termin\u00f3 usando utilidades del espacio de usuario, todo fue lento y triste, pero recuperamos los datos. Para quienes est\u00e9n interesados, busquen el nombre de la utilidad. fuseext2<\/code>. La moraleja: o pensar en todos los casos de antemano, o no pretender ser un superh\u00e9roe y usar configuraciones est\u00e1ndar para hogares.<\/p>\n
UPD. Seg\u00fan el comentario del usuario berez<\/a><\/noindex> , aclaro que para i386 el tama\u00f1o del bloque no debe exceder 4k, pero no tiene que ser necesariamente 4k; es decir, se permiten 1k y 2k.<\/p>\n
As\u00ed que, as\u00ed es como resolvimos los problemas.<\/p>\n
Primero, nos encontramos con el problema cuando un disco de varios terabytes se llen\u00f3 de datos, y no pod\u00edamos reorganizar la configuraci\u00f3n del sistema de archivos.<\/p>\n
En segundo lugar, necesit\u00e1bamos una soluci\u00f3n urgente.<\/p>\n
Como resultado, llegamos a la conclusi\u00f3n de que era necesario cambiar el equilibrio, reduciendo el n\u00famero de archivos.
\nPara reducir el n\u00famero de archivos, decidimos agruparlos en un solo archivo comprimido. Teniendo en cuenta nuestra especificidad, agrupamos en un solo archivo todos los archivos de un determinado per\u00edodo y llevamos a cabo la compresi\u00f3n mediante una tarea cron diariamente durante la noche.<\/p>\n
Elegimos un archivo zip. En los comentarios del art\u00edculo anterior se suger\u00eda tar, pero hay una dificultad: no tiene un \u00edndice y los archivos dentro est\u00e1n dispuestos secuencialmente (no es por nada que \u00abtar\u00bb es una abreviatura de \u00abTape Archive\u00bb, un legado de las unidades de cinta), es decir, si se necesita leer un archivo al final del archivo, hay que leer todo el archivo, ya que no hay desplazamientos para cada archivo en relaci\u00f3n con el comienzo del archivo. Por lo tanto, esta es una operaci\u00f3n lenta. En zip todo es mucho mejor: tiene ese \u00edndice y desplazamientos de archivos dentro del archivo, y el tiempo de acceso a cada archivo no depende de su ubicaci\u00f3n. En nuestro caso, se pod\u00eda establecer la opci\u00f3n de compresi\u00f3n \u00ab0\u00bb, ya que todos los archivos ya hab\u00edan sido comprimidos previamente en gzip.<\/p>\n
Los clientes recuperan archivos a trav\u00e9s de nginx, y de acuerdo con la API antigua, simplemente se especifica el nombre del archivo, por ejemplo as\u00ed:<\/p>\n
http:\/\/www.server.com\/hydra\/20170416\/0453\/3bd24ae7-1df4-4d76-9d28-5b7fcb7fd8e5\n<\/code><\/pre>\n
\nPara descomprimir archivos sobre la marcha, encontramos y conectamos el m\u00f3dulo nginx-unzip-module (https:\/\/github.com\/youzee\/nginx-unzip-module<\/a><\/noindex>) y configuramos dos upstreams.<\/p>\n
Como resultado, la configuraci\u00f3n fue la siguiente:<\/p>\n
\"Trucos
\n
\nLos dos hosts en la configuraci\u00f3n eran como sigue:<\/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
\nY la configuraci\u00f3n de los upstreams en el nginx superior:<\/p>\n
upstream storage {\n  server server.com:8081;\n  server server.com:8082;\n}\n<\/code><\/pre>\n
\nC\u00f3mo funciona:<\/p>\n