¿Cómo afecta el número de subdirectorios al rendimiento de lectura / escritura del disco en Linux?

Tengo una unidad con formato EXT3 en un servidor Linux CentOS. Esta es una unidad de datos de aplicaciones web y contiene un directorio para cada cuenta de usuario (hay 25,000 usuarios). Cada carpeta contiene archivos que ese usuario ha subido. En general, esta unidad tiene aproximadamente 250 GB de datos.

¿La estructuración de la unidad con todos estos directorios afecta el rendimiento de lectura / escritura de la unidad? ¿Tiene algún otro aspecto de rendimiento que desconozco?

¿Hay algo inherentemente malo o malo en estructurar las cosas de esta manera? ¿Quizás la elección incorrecta del sistema de archivos?

Recientemente intenté fusionar dos unidades de datos y me di cuenta de que EXT3 está limitado a 32,000 subdirectorios. Esto me hizo preguntarme por qué. Parece tonto que lo haya construido de esta manera, considerando que cada archivo tiene una identificación única que corresponde a una identificación en la base de datos. Pobre de mí ...

Es fácil probar las opciones por usted mismo, en su entorno y comparar los resultados. Sí, hay un impacto negativo en el rendimiento a medida que aumenta el número de directorios. Sí, otros sistemas de archivos pueden ayudar a superar esas barreras o reducir el impacto.

El sistema de archivos XFS es mejor para este tipo de estructura de directorios. ext4 probablemente esté bien hoy en día. El acceso y las operaciones en el directorio simplemente disminuirán a medida que aumente la cantidad de subdirectorios y archivos. Esto es muy pronunciado en ext3 y no tanto en XFS.

La respuesta no es tan simple como la elección del sistema de archivos. Los sistemas de archivos sanos dejaron de usar listas lineales para directorios hace mucho tiempo, lo que significa que el número de entradas en un directorio no afecta el tiempo de acceso a los archivos ...

excepto cuando lo hace.

De hecho, cada operación se mantiene rápida y eficiente sin importar el número de entradas, pero algunas tareas implican un número creciente de operaciones. Obviamente, hacer un simple lslleva mucho tiempo, y no ves nada hasta que todos los inodos han sido leídos y ordenados. Hacer ls -U(sin clasificar) ayuda un poco porque puedes ver que no está muerto, pero no reduce el tiempo de forma perceptiva. Menos obvio es que cualquier expansión de comodines tiene que verificar todos y cada uno de los nombres de archivo, y parece que en la mayoría de los casos también se debe leer todo el inodo.

En resumen: si puede estar seguro de que ninguna aplicación (incluido el acceso de shell) usará wildard, puede obtener directorios enormes sin ningún remordimiento. Pero si puede haber algunos comodines al acecho en el código, mejor mantenga los directorios por debajo de mil entradas cada uno.

editar :

Todos los sistemas de archivos modernos usan buenas estructuras de datos para directorios grandes, por lo que una sola operación que tiene que encontrar el inodo de un archivo específico será bastante rápida incluso en directorios enormes.

Pero, la mayoría de las aplicaciones no solo realizan operaciones únicas. La mayoría de ellos hará un directorio completo o una coincidencia de comodines. Sin embargo, son lentos porque implican la lectura de todas las entradas.

Por ejemplo: supongamos que tiene un directorio con un millón de archivos llamado 'foo-000000.txt' a través de 'foo-999999.txt' y un solo 'natalieportman.jpeg'. Estos serán rápidos:

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

estos fallarán, pero también fallarán rápidamente:

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

estos serán lentos, incluso si devuelven muy pocos resultados; incluso aquellos que fallan, fallan después de escanear todas las entradas:

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

Primero asegúrese de que la partición ext3 tenga la dir_indexbandera establecida.

sudo dumpe2fs /dev/sdaX |grep --color dir_index

Si falta, puede habilitarlo. Debe desmontar el sistema de archivos y luego ejecutar:

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

Luego monte el sistema de archivos.

No hace ninguna diferencia hasta que alcanza los 32,000 nombres ext3 por límite de directorio. La actualización a ext4 puede evitar eso, así como los otros beneficios que tiene ext4.

Cuantas más entradas (archivos y directorios) tenga dentro de un solo directorio, más lento será el acceso. Esto es cierto para todos los sistemas de archivos, aunque algunos son peores que otros.

Una mejor solución es crear una jerarquía de directorios, como esta:

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

Y si aún necesita un mejor rendimiento, puede ampliar varios niveles:

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

La mayoría de los sistemas de correo utilizan este truco con sus archivos de cola de correo.

Además, descubrí que con algunos sistemas de archivos, solo haber tenido en el pasado muchas entradas en un directorio hará que el acceso al directorio sea lento. Haga un ls -lden el directorio para ver el tamaño de la entrada del directorio en sí. Si son varios MB o más y el directorio está relativamente vacío, entonces puede estar obteniendo un bajo rendimiento. Cambie el nombre del directorio, cree uno nuevo con el mismo nombre y los mismos permisos y propiedad, y luego mueva el contenido de su antiguo directorio al nuevo. He usado este truco muchas veces para acelerar significativamente los servidores de correo que el sistema de archivos ha ralentizado.

Desarrollé un servidor de almacenamiento recientemente que necesitaba crear decenas de millones de archivos y cientos de miles de directorios. Comparé XFS con ext4 y reiserfs. Descubrí que en mi caso ext4 era un poco más rápido que XFS. Reiser era interesante pero tenía limitaciones, por lo que fue descartado. También encontré que ext4 era significativamente más rápido que ext3.

Cuando obtiene muchos archivos por directorio, el tiempo de apertura de archivos comienza a sufrir. La E / S de archivo no. El tiempo de eliminación de archivos también sufre. Sin embargo, no es demasiado lento en ext4. Sin embargo, es bastante notable en ext3. XFS y ext4 son bastante rápidos en esto.

La última vez que vi XFS y estaba sopesando las ventajas y desventajas de usar XFS sobre ext4, encontré informes de pérdida de datos con XFS. No estoy seguro de que esto siga siendo un problema o si alguna vez lo fue, pero me puso lo suficientemente nervioso como para evitarlo. Como ext4 es el fs predeterminado en Ubuntu, ganó fácilmente sobre XFS.

Por lo tanto, además de la sugerencia de tylerl que ayudará desde la perspectiva de la administración, le sugiero que pueda actualizar a ext4. El límite por directorio es 64000 entradas con ext4

Otro beneficio es que el tiempo fsck es sustancialmente más rápido. Nunca he tenido problemas con la corrupción.

Lo bueno de ext4 es que puedes montar un volumen ext3 en ext4 para probarlo. Consulte: Migración de un sistema en vivo del sistema de archivos ext3 a ext4

Una cita de ese enlace:

Si no está afectado por las limitaciones de ext3 y no está dispuesto a correr riesgos, puede que no valga la pena. Por otro lado, al completar con éxito el procedimiento de migración, su sistema puede funcionar más rápido, experimentar verificaciones más cortas del sistema de archivos y tener una mayor confiabilidad sin efectos nocivos.

Entonces, adelante y pruébalo. Sugerir su copia de seguridad primero.

Definitivamente va a haber algunas consecuencias de hacer esto. El principal será IO read / write. Más allá de eso, es solo una forma muy aterradora de tratar con ese tipo de datos (a esa escala).

En el pasado, utilicé XFS para superar los límites de Ext3 con éxito.

La primera lista de los contenidos del sistema de archivos llevará un tiempo hasta que el sistema haya leído toda la información del directorio / archivo. Las operaciones suplementarias serán más rápidas porque el núcleo ahora tiene la información en caché.

He visto a los administradores ejecutar 'find / somepath 2> & 1> / dev / null' en cron de forma regular para mantener el caché activo, lo que resulta en un mejor rendimiento.

Tengo algunas preguntas y algunos posibles hallazgos de cuellos de botella.

Primero, ¿es este un sistema CentOS 5 o 6? Porque en 6, tenemos una herramienta increíble llamada blktrace que es ideal para medir el impacto en este tipo de situaciones.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

Luego podemos analizar la salida con btt y llegar a dónde está el cuello de botella, la aplicación, el sistema de archivos, el programador, el almacenamiento, en qué componente el IO pasa la mayor parte del tiempo.

Ahora, teóricamente, llegando a su pregunta, obviamente aumentará el número de inodos y a medida que continúe creando o accediendo a archivos o directorios nuevos o existentes dentro de los directorios, aumentará el tiempo de acceso. El núcleo tiene que atravesar una jerarquía de sistema de archivos más vasta y, por lo tanto, eso es sin duda una sobrecarga.

Otro punto a tener en cuenta es que a medida que aumenta el número de directorios, el uso de caché de inodo y dentry aumentará, lo que significa el consumo de más RAM. Esto viene bajo memoria de losa, por lo que si su servidor se está quedando sin memoria, ese es otro punto de pensamiento.

Hablando de un ejemplo del mundo real, recientemente vi que en una ext3 fs altamente anidada, crear un subdirectorio por primera vez está tomando alrededor de 20 segundos, mientras que en ext4 está tomando alrededor de 4 segundos. Esto se debe a cómo se estructura la asignación de bloques en diferentes sistemas de archivos. Si usa XFS o ext4, no hace falta decir que obtendrá un aumento en el rendimiento, por mínimo que sea.

Entonces, si solo está preguntando cuál es la elección correcta del sistema de archivos, ext3 está un poco desactualizado. Es todo lo que puedo ofrecer sin más datos y puntos de referencia.

No es una opción en CentOS 5, y no estoy seguro de cuánto es una opción en CentOS 6, pero tengo el presentimiento de que un árbol B o una solución basada en árbol B *, es decir, BTRFS proporcionaría un rendimiento consistente, si no significativamente mejor en su particular escenario, si solo uno pudiera confiarle los datos preciosos con la conciencia tranquila (todavía no lo haría).

Pero si puede permitírselo, podría probarlo.