prefacio
Como un sistema de almacenamiento de archivos distribuido de alto rendimiento y propósito general, YRCloudFile se usa ampliamente en escenarios como IA/conducción autónoma, HPC, análisis cuantitativo, renderizado de efectos visuales y big data. Para un ancho de banda extremo, algunos requieren un alto IOPS para archivos grandes. , mientras que otros necesitan admitir una gran cantidad de archivos pequeños, y estos requisitos implicarán muchas optimizaciones y decisiones de diseño.
Hoy, discutiremos cómo optimizar el rendimiento de una gran cantidad de archivos pequeños en el escenario de entrenamiento de IA. Dado que el acceso a archivos en el escenario de entrenamiento se abre en modo de solo lectura, este artículo se centrará en la parte de optimización de los archivos pequeños de sólo lectura.
El proceso de lectura y escritura de archivos.
En primer lugar, comprendamos brevemente el proceso de operación requerido para leer el archivo. Tome cat a small file como ejemplo: primero, antes de leer el archivo, debe verificar si el archivo existe a través de la búsqueda. Para confirmar la existencia, debe abrir el archivo a través de abrir, leer el contenido del archivo a través de lectura, y luego cierre el archivo hasta cerrar después de leer el contenido del archivo. Para sistemas de archivos de red como: YRCloudFile, NFS, etc., existen revalidate y stat para actualizar los inodos. Tenga en cuenta que la búsqueda solo se llama la primera vez que el sistema de archivos abre un archivo. Podemos verificar el proceso anterior a través de strace:
Las operaciones fadvise y mmap en la figura anterior son operaciones exclusivas de cat, por lo que no es necesario comprenderlas en profundidad aquí. Además, con respecto a buscar y revalidar, la razón por la que estas dos operaciones no aparecen en la figura anterior es que están ocultas dentro del sistema de archivos y no están expuestas a través de llamadas al sistema.
Cuello de botella de metadatos para archivos pequeños
En las operaciones de archivos pequeños, las operaciones de metadatos representan una gran proporción, incluso alcanzando el 70%-80%, mientras que la lectura y escritura de negocios reales solo representa una pequeña parte.En este momento, el rendimiento de los metadatos se convierte en un cuello de botella de rendimiento.
A través de la discusión anterior, aprendimos que las operaciones requeridas para leer archivos son: buscar, abrir, leer, cerrar, stat, revalidar, y cada operación va acompañada de una sobrecarga de red. Entre ellos, la búsqueda solo se llama cuando el sistema de archivos lee el archivo por primera vez, y la sobrecarga de leer el archivo varias veces es básicamente insignificante Para facilitar la descripción, la búsqueda no se tratará a continuación. Abrir, cerrar, stat y revalidar son todas operaciones de metadatos, y solo hay una llamada, mientras que solo leer es la operación de datos que realmente necesita la empresa, y cuanto más grande sea el archivo, más llamadas realizará. Podemos saber a través del cálculo que cuanto más grande es el archivo, más tiempos de lectura, mayor la proporción de operaciones de datos y menor la proporción de operaciones de metadatos, y viceversa. A continuación, echemos un vistazo más de cerca a los escenarios de lectura de archivos grandes y pequeños:
Primero, analicemos el escenario de leer archivos grandes. Por ejemplo, para leer un archivo de 100M y leer datos de 1M cada vez, se requieren 100 llamadas de lectura. Hay 4 operaciones de metadatos correspondientes: abrir, cerrar, stat y revalidar. El número total de operaciones es 104, por lo que se puede calcular que las operaciones de datos representan 100/104 * 100 % = 96 %, mientras que las operaciones de metadatos representan 4/104 * 100 % = 4 %.
En el escenario de lectura de archivos pequeños, como la lectura de un archivo de 1M, solo se requiere una llamada de lectura para leer datos de 1M cada vez. Las operaciones de metadatos correspondientes también tienen cuatro operaciones: abrir, cerrar, stat y revalidar. El número total de operaciones es 5, que también se puede calcular, y la proporción de operaciones de datos es 1/5 * 100% = 20%. La operación de metadatos representó 4/5 * 100% = 80%.
A través del análisis anterior, está claro que para archivos más pequeños, la proporción de operaciones de metadatos es mayor y el rendimiento de los metadatos se ha convertido en un cuello de botella que limita severamente el rendimiento de las operaciones. Para su optimización, necesitamos reducir la proporción de operaciones de metadatos para mejorar las operaciones.
solución técnica
Con base en la discusión anterior, aprendimos que existe un serio cuello de botella en el rendimiento de los metadatos cuando se trata de archivos pequeños. Esto se debe a que para cada archivo pequeño, el sistema necesita leer y procesar con frecuencia su información de metadatos correspondiente, incluidos abrir, cerrar, stat y revalidar, etc. Estas operaciones ocuparán una gran cantidad de recursos de red y disco. Porque necesitamos optimizar para estos problemas.
首先，为了支撑对元数据访问路径的低延迟和高 ops 能力，焱融分布式文件存储 YRCloudFile 采用的 io 框架可提供百万级的 iops 能力。由于元数据需要保证 posix 语义，所以性能上无法和普通读写 io 一样，但同样可以提供数十万的交互能力。
其次，依赖客户端缓存机制，焱融分布式文件存储 YRCloudFile 提供了基于内存缓存的元数据管理技术，在保证语义的前提下，能安全的命中缓存，减少跨网络和磁盘访问开销。
再次，我们实现的 lazy size，lazy close，batch commit，metadata readhead 机制，能同时保证在文件系统语义的前提下，将部分逻辑 offload 到客户端，这样的好处是能够很好的降低元数据服务的压力，并且集群的元数据性能得到很大的提升，包括在延迟和 ops 等方面。
综上，焱融分布式文件存储 YRCloudFile 通过一系列技术操作优化小文件的元数据性能，包括基于内存缓存的元数据管理、轻量级 open、延迟 close 以及批量 close 等。这些技术的应用，可以显著提高焱融分布式文件存储 YRCloudFile 在处理小文件时的性能表现，从而更好地满足用户的需求。
优化前后性能对比
接下来，我们将在具体的 vdbench 测试中来看下焱融分布式文件存储 YRCloudFile 的优化效果。集群配置多副本模式，其中 3 组 mds，3 组 oss，mds 和 oss 均由 nvme ssd 构建。vdbench 脚本为：
hd=default,vdbench=/root/vdbench50406,shell=ssh,user=root
hd=hd01,system=10.16.11.141
fsd=fsd1_01,anchor=/mnt/yrfs/vdbench/4k-01/,depth=1,width=5,files=1000,size=4k,openflags=o_direct
fwd=fwd1_01,fsd=fsd2_01,host=hd01,operation=read,fileio=random,fileselect=random
rd=randr_4k,fwd=fwd5_*,xfersize=4k,threads=64,fwdrate=max,format=restart,elapsed=30,interval=1,pause=1m
复制代码优化前
Miscellaneous statistics:
(These statistics do not include activity between the last reported interval and shutdown.)
READ_OPENS Files opened for read activity: 540,793 95,986/sec
FILE_BUSY File busy: 5,129 570/sec
FILE_CLOSES Close requests: 540,793 95,986/sec
复制代码优化后
Miscellaneous statistics:
(These statistics do not include activity between the last reported interval and shutdown.)
READ_OPENS Files opened for read activity: 4,589,603 653,742/sec
FILE_BUSY File busy: 56,129 1,870/sec
FILE_CLOSES Close requests: 4,589,603 653,742/sec
复制代码通过上述数据，可以看到焱融分布式文件存储 YRCloudFile 显著提高了在处理小文件时的性能表现，性能提高 6 倍以上，以上是基于大量的测试和评估所得出的结论。
写到最后
En este artículo, analizamos la optimización del almacenamiento de archivos distribuidos de Yanrong YRCloudFile en el escenario de archivos pequeños de solo lectura. Primero revisamos el proceso básico de lectura y escritura de archivos, analizamos los problemas existentes en los archivos pequeños y luego diseñamos una serie de soluciones de optimización para resolver el cuello de botella de rendimiento de los archivos pequeños de solo lectura en escenarios de entrenamiento de IA. La tecnología de optimización del almacenamiento de archivos distribuido de Yanrong YRCloudFile puede proporcionar servicios más rápidos, eficientes y confiables para aplicaciones comerciales, especialmente en escenarios de capacitación de IA, mejorando así la experiencia y la satisfacción del usuario.