Rendimiento lento de transferencia NFS de archivos pequeños

Estoy usando Openfiler 2.3 en un HP ML370 G5, Smart Array P400, discos SAS combinados usando RAID 1 + 0.

Configuré un recurso compartido NFS desde la partición ext3 usando la configuración basada en web de Openfiler, y logré montar el recurso compartido desde otro host. Ambos hosts están conectados mediante un enlace gigabit dedicado.

Punto de referencia simple usando dd:

 $ dd if=/dev/zero of=outfile bs=1000 count=2000000
 2000000+0 records in
 2000000+0 records out
 2000000000 bytes (2.0 GB) copied, 34.4737 s, 58.0 MB/s

Veo que puede lograr una velocidad de transferencia moderada (58.0 MB / s).

Pero si copio un directorio que contiene muchos archivos pequeños ( .phpy .jpg, alrededor de 1-4 kB por archivo) de tamaño total ~ 300 MB, el cpproceso finaliza en unos 10 minutos.

¿NFS no es adecuado para la transferencia de archivos pequeños como en el caso anterior? ¿O hay algunos parámetros que deben ajustarse?

Hay muchas razones por las cuales transferir muchos archivos pequeños siempre será más lento que transferir un solo archivo grande. Para una lectura, es más probable que los archivos estén dispersos por el disco, lo que requiere búsquedas en todo el lugar para obtenerlos. Como mencionó Evan, también hay metadatos involucrados en el caso de NFS (¡o cualquier otro sistema de archivos!) Lo que también complica las cosas.

Puede intentar aumentar sus parámetros rsizey wsizepara el montaje NFS y ver si eso ayudará un poco al rendimiento. Consulte también esta pregunta sobre cómo ajustar NFS para una latencia mínima, ya que tiene muchos consejos útiles que ayudarán en el caso de muchas transferencias de archivos pequeños.

No tengo mucha experiencia en NFS, pero mi experiencia con otros protocolos de red para compartir archivos dice que el rendimiento se ve afectado en el escenario de "muchos archivos pequeños" casi universalmente. Estás incurriendo en latencia de ida y vuelta, y en un gran grupo de archivos esa latencia se suma.

¿Has probado con un sistema de archivos diferente, como XFS? Resolvió todos mis problemas al hacer cantidades extremas de pequeñas transferencias de bloques iSCSI. No tengo idea de por qué.

Además, iSCSI / NFS generalmente está configurado para marcos de datos bastante grandes (tramas gigantes, etc.), podría lastimarlo si está copiando archivos pequeños uno por uno. Tal vez tar'ing y luego transferir te ayudarían.

Compruebe que está utilizando la conexión TCP ( mount -t nfs -o tcp host: / mount / target ). El rendimiento en los sistemas modernos no se verá afectado, pero las pequeñas E / S pueden mejorar significativamente si su red está cargada.

Y también deberías probar algún otro sistema de archivos; ext3 es básicamente el más lento de todos. Es sólido, bien conocido, pero es bastante inadecuado para un servidor de archivos. XFS es mucho mejor, y reiserfs también es mucho mejor en pequeñas E / S.

Si desea transferir un gran árbol de directorios de archivos pequeños a través de NFS, y puede iniciar sesión en el servidor, la mejor manera de hacerlo es crear un archivo tar que se extraiga automáticamente en el cliente, de la siguiente manera:

tar c mydirectory | ssh user @ host tar -xf - -C destdir

De esa manera, solo se transfiere un solo "archivo" a través de la red e inmediatamente tiene todos sus archivos en el host.

Solo para agregar a la respuesta de Evan, también tiene toda la sobrecarga de crear los metadatos (entradas de directorio, etc.) para cada archivo que está copiando.

Una solución similar a la respuesta de Chris sería sincronizar sus archivos con los clientes periódicamente. Si desea realizar cambios bidireccionales, también puede usar unísono.

El problema es que su syncrecurso compartido se exporta con la opción (el valor predeterminado). Use asyncpara acelerar las escrituras considerablemente. Ver nfs.sourceforge.net/nfs-howto/ar01s05.html