Almacenamiento de miles de files en un directory

Tengo un website que estoy revisando por problemas de performance y errores, y encontré un código de almacenamiento en caching que guarda en caching miles de files en un solo directory.

Entiendo que esto no es bueno y que la E / S se degradará y también escuché sobre un posible problema de inodo.

Y sé cómo arreglar el código de almacenamiento en caching, pero el problema es que en este punto la reparación sería muy costosa.

La pregunta : ¿Cuál es el peor de los casos si lo vivo como es ahora? ¿Qué pasará con el website? (ahora este único directory de caching tiene 400K files)

Soy nuevo en Ubuntu. Y entiendo que esto podría ser un tema fuera de lugar. Pero creo que esta es una pregunta de "sistema" y no pertenece a la parte de 'progtwigción' del stackoverflow.

¡Gracias!

ACTUALIZACIÓN: el sistema de files es UFS

La situación es algo sorprendente. UFS es un sistema de files inusual para una installation Linux de producción. El acceso de escritura de UFS en Linux normalmente debe estar explícitamente habilitado en el kernel, ya que se ha considerado experimental durante muchos años:

CONFIG_UFS_FS_WRITE: soporte de escritura del sistema de files UFS (PELIGROSO)

Responda S aquí si desea intentar escribir en particiones UFS. Esto es experimental, por lo que debe hacer una copy de security de sus particiones UFS de antemano.

Al igual que muchos filesystems tradicionales, UFS usa búsquedas secuenciales de files dentro de los directorys. Esto sí lleva a problemas de performance para directorys con muchos files, ya que el time de búsqueda crece linealmente con la cantidad de files. En los BSD, donde UFS suele ser el sistema de files pnetworkingeterminado , este problema conduce directamente a la creación de Dirhash , una búsqueda de tabla hash para directorys, que mejora significativamente el performance.

Por lo que sé, el soporte de UFS bajo Linux no usa Dirhash. Por lo tanto, puede esperar experimentar problemas de performance cada vez mayores a medida que crece la cantidad de files en su directory. En términos de acceso secuencial, los files 400K son muchos y se puede esperar un performance significativo.

La split de files entre subdirectorys gestiona eficazmente el problema de acceso secuencial. Alternativamente, podría pasar a un sistema de files que admita una estructura de almacenamiento de files más sofisticada. Por ejemplo, XFS implementa acceso rápido a files para directorys grandes mediante el uso de treees B + .

Tu segunda preocupación fue sobre inodos. Por lo general, el número de inodos en su sistema de files es fijo, y esto generalmente es una function de la cantidad de espacio disponible en el momento de creación del sistema de files. Por ejemplo, /etc/mke2fs.conf mantiene la relación de inode pnetworkingeterminada (número de inodos por x bytes) para los filesystems ext.

Normalmente, este número es mucho más grande que la cantidad de files que es probable que cree, y no es motivo de preocupación. Sin embargo, puede verificar el uso de su inodo con df -i . Si las limitaciones de inodos son probablemente un problema, jugar con directorys no lo ayudará, ya que los inodos son un concepto de todo el sistema de files, independiente del directory. En este caso, se vería forzado a volver a crear el sistema de files, estableciendo el parámetro del inodo ( -i ) a mkfs apropiada.

En un sistema de files UNIX normal (basado en inode), incluido UFS, es una aproximación razonable decir que cada file o directory que cree utiliza un inodo. Tener muchos files en un directory no cambia esto.

Los problemas habituales con el enfoque que describes son:

  • los filesystems usan algorithms hash o estructuras de datos de tipo tree para search directorys para acelerar la búsqueda y la creación, cuantos más files tenga en un solo directory, más lenta será. Con hashing, esta ralentización puede ser bastante pronunciada a medida que ocurren las colisiones.
  • los commands típicos de Unix tienen problemas (específicamente la orderación de ls y la expansión de shell glob), aunque normalmente mucho antes de que se desacelere el sistema de files.
  • a medida que el directory gane nuevos files, se asignarán más bloques, se fragmentará cada vez más y se requerirá más acceso de disco duro.

Los filesystems más modernos (ext3 / 4) usan estructuras de datos tipo B-tree para mantener los directorys orderados, como parte de sus datos en el disco. Creo que la implementación de UFS usa hashing en memory (basado en el uso y la documentation de FreeBSD, no tengo mucha experiencia directa con UFS en Linux) ya que el formatting en disco no usa hashes.

Tiene buena información y enlaces de UFS: https://serverfault.com/questions/53416/max-total-files-in-a-directory-in-freebsd-6-ufs

El peor caso probable es que en algún momento experimentará una desaceleración notable y que empeora cada vez que acceda a ese directory. Cuando llegue a ese punto, será tedioso solucionarlo (de acuerdo con mi experiencia con las queues de Sendmail).

Le recomiendo que monitoree (y grafique) el time de espera de su sistema, y ​​conozca iotop y slabtop si no lo hace.

Si es posible, también sugiero que pruebe algunos experimentos simples para sincronizar la creación de 1000 files en su directory de caching, y compare con eso en un directory vacío.