Estoy intentando determinar la causa del bajo rendimiento de nfs entre dos máquinas virtuales Xen (cliente y servidor) que se ejecutan en el mismo host. Específicamente, la velocidad a la que puedo leer secuencialmente un archivo de 1 GB en el cliente es mucho menor de lo que se esperaría según la velocidad de conexión de red medida entre las dos máquinas virtuales y la velocidad medida de lectura del archivo directamente en el servidor. Las máquinas virtuales ejecutan Ubuntu 9.04 y el servidor utiliza el paquete nfs-kernel-server.
Según varios recursos de ajuste de NFS, cambiar la cantidad de subprocesos nfsd (en mi caso, subprocesos del kernel) puede afectar el rendimiento. Por lo general, este consejo se formula en términos de aumentar el número predeterminado de 8 en servidores muy utilizados. Lo que encuentro en mi configuración actual:
RPCNFSDCOUNT=8: (predeterminado): 13,5-30 segundos para procesar un archivo de 1 GB en el cliente, por lo que 35-80 MB/seg
RPCNFSDCOUNT=16: 18s para capturar el archivo 60MB/s
RPCNFSDCOUNT=1: 8-9 segundospara capturar el archivo (!!?!) 125MB/s
RPCNFSDCOUNT=2: 87s para capturar el archivo 12MB/s
Debo mencionar que el archivo que estoy exportando está en un RevoDrive SSD montado en el servidor usando el paso PCI de Xen; en el servidor puedo capturar el archivo en menos de segundos (> 250 MB/s). Estoy colocando cachés en el cliente antes de cada prueba.
Realmente no quiero dejar el servidor configurado con un solo subproceso, ya que supongo que no funcionará tan bien cuando hay varios clientes, pero es posible que no entienda bien cómo funciona. He repetido las pruebas varias veces (cambiando la configuración del servidor en el medio) y los resultados son bastante consistentes. Entonces mi pregunta es:¿Por qué el mejor rendimiento es con 1 hilo?
Algunas otras cosas que he intentado cambiar, con poco o ningún efecto:
aumentando los valores de /proc/sys/net/ipv4/ipfrag_low_thresh y /proc/sys/net/ipv4/ipfrag_high_thresh a 512K, 1M del valor predeterminado 192K,256K
aumentando el valor de /proc/sys/net/core/rmem_default y /proc/sys/net/core/rmem_max a 1M desde el valor predeterminado de 128K
montaje con opciones de cliente rsize=32768, wsize=32768
Por el resultado de sar -d, entiendo que los tamaños de lectura reales que van al dispositivo subyacente son bastante pequeños (<100 bytes), pero esto no causa un problema al leer el archivo localmente en el cliente.
RevoDrive en realidad expone dos dispositivos "SATA" /dev/sda y /dev/sdb, luego dmraid recoge un fakeRAID-0 rayado entre ellos que he montado en /mnt/ssd y luego montado en enlace en /export/ssd. Realicé pruebas locales en mi archivo usando ambas ubicaciones y observé el buen rendimiento mencionado anteriormente. Si las respuestas/comentarios solicitan más detalles, los agregaré.
Respuesta1
Cuando llega una solicitud de un cliente, se pasa a uno de los subprocesos y se pide al resto de los subprocesos que realicen operaciones de lectura anticipada. La forma más rápida de leer un archivo es hacer que un hilo lo haga secuencialmente... Entonces, para un archivo esto es excesivo y, en esencia, los hilos están haciendo más trabajo por sí mismos. Pero lo que es cierto para 1 cliente que lee 1 archivo no necesariamente será cierto cuando lo implemente en el mundo real, así que siga con la fórmula para basar el número de subprocesos y el número de lecturas anticipadas en las especificaciones de ancho de banda/CPU.