Mejora del rendimiento de múltiples rutas SAS a JBOD en Linux

10

Estoy tratando de optimizar una configuración de almacenamiento en algún hardware de Sun con Linux. Cualquier pensamiento sería muy apreciado.

Tenemos el siguiente hardware:

  • Sun Blade X6270
  • 2 * controladores LSISAS1068E SAS
  • 2 * Sun J4400 JBOD con discos de 1 TB (24 discos por JBOD)
  • Fedora Core 12
  • 2.6.33 kernel de lanzamiento de FC13 (también probado con el último kernel 2.6.31 de FC12, los mismos resultados)

Aquí está la hoja de datos para el hardware SAS:

http://www.sun.com/storage/storage_networking/hba/sas/PCIe.pdf

Está utilizando PCI Express 1.0a, 8x carriles. Con un ancho de banda de 250 MB / seg por carril, deberíamos poder realizar 2000 MB / seg por controlador SAS.

Cada controlador puede hacer 3 Gb / seg por puerto y tiene dos PHY de 4 puertos. Conectamos ambos PHY de un controlador a un JBOD. Entonces, entre el JBOD y el controlador, tenemos 2 PHY * 4 puertos SAS * 3 Gb / seg = 24 Gb / seg de ancho de banda, que es más que el ancho de banda PCI Express.

Con el almacenamiento en caché de escritura habilitado y cuando se realizan grandes escrituras, cada disco puede soportar aproximadamente 80 MB / seg (cerca del inicio del disco). Con 24 discos, eso significa que deberíamos poder hacer 1920 MB / seg por JBOD.

multitrayecto {
  rr_min_io 100
  uid 0
  path_grouping_policy multibus
  manual de recuperación
  path_selector "round-robin 0"
  prioridades rr_weight
  alias somealias
  cola no_path_retry
  modo 0644
  gid 0
  wwid somewwid
}

Intenté valores de 50, 100, 1000 para rr_min_io, pero no parece haber mucha diferencia.

Junto con la variación de rr_min_io, intenté agregar un poco de retraso entre el inicio de los dd para evitar que todos escriban sobre el mismo PHY al mismo tiempo, pero esto no hizo ninguna diferencia, por lo que creo que las E / S se están distribuyendo correctamente.

Según / proc / interrupts, los controladores SAS están utilizando un esquema de interrupción "IR-IO-APIC-fasteoi". Por alguna razón, solo el núcleo # 0 en la máquina maneja estas interrupciones. Puedo mejorar ligeramente el rendimiento asignando un núcleo separado para manejar las interrupciones para cada controlador SAS:

echo 2> / proc / irq / 24 / smp_affinity
echo 4> / proc / irq / 26 / smp_affinity

El uso de dd para escribir en el disco genera "interrupciones de llamadas de función" (no tengo idea de cuáles son), que son manejadas por el núcleo # 4, por lo que también mantengo otros procesos fuera de este núcleo.

Ejecuto 48 dd (uno para cada disco), asignándolos a núcleos que no manejan interrupciones de esta manera:

conjunto de tareas -c somecore dd if = / dev / zero of = / dev / mapper / mpathx oflag = direct bs = 128M

oflag = direct evita que se involucre cualquier tipo de caché de búfer.

Ninguno de mis núcleos parece agotado. Los núcleos que se ocupan de las interrupciones están en su mayoría inactivos y todos los demás núcleos están esperando la E / S como cabría esperar.

Cpu0: 0.0% us, 1.0% sy, 0.0% ni, 91.2% id, 7.5% wa, 0.0% hi, 0.2% si, 0.0% st
CPU1: 0.0% us, 0.8% sy, 0.0% ni, 93.0% id, 0.2% wa, 0.0% hi, 6.0% si, 0.0% st
CPU2: 0.0% us, 0.6% sy, 0.0% ni, 94.4% id, 0.1% wa, 0.0% hi, 4.8% si, 0.0% st
Cpu3: 0.0% us, 7.5% sy, 0.0% ni, 36.3% id, 56.1% wa, 0.0% hi, 0.0% si, 0.0% st
Cpu4: 0.0% us, 1.3% sy, 0.0% ni, 85.7% id, 4.9% wa, 0.0% hi, 8.1% si, 0.0% st
Cpu5: 0.1% us, 5.5% sy, 0.0% ni, 36.2% id, 58.3% wa, 0.0% hi, 0.0% si, 0.0% st
CPU6: 0.0% us, 5.0% sy, 0.0% ni, 36.3% id, 58.7% wa, 0.0% hi, 0.0% si, 0.0% st
CPU7: 0.0% us, 5.1% sy, 0.0% ni, 36.3% id, 58.5% wa, 0.0% hi, 0.0% si, 0.0% st
CPU8: 0.1% us, 8.3% sy, 0.0% ni, 27.2% id, 64.4% wa, 0.0% hi, 0.0% si, 0.0% st
CPU9: 0.1% us, 7.9% sy, 0.0% ni, 36.2% id, 55.8% wa, 0.0% hi, 0.0% si, 0.0% st
CPU10: 0.0% us, 7.8% sy, 0.0% ni, 36.2% id, 56.0% wa, 0.0% hi, 0.0% si, 0.0% st
Cpu11: 0.0% us, 7.3% sy, 0.0% ni, 36.3% id, 56.4% wa, 0.0% hi, 0.0% si, 0.0% st
Cpu12: 0.0% us, 5.6% sy, 0.0% ni, 33.1% id, 61.2% wa, 0.0% hi, 0.0% si, 0.0% st
Cpu13: 0.1% us, 5.3% sy, 0.0% ni, 36.1% id, 58.5% wa, 0.0% hi, 0.0% si, 0.0% st
CPU14: 0.0% us, 4.9% sy, 0.0% ni, 36.4% id, 58.7% wa, 0.0% hi, 0.0% si, 0.0% st
Cpu15: 0.1% us, 5.4% sy, 0.0% ni, 36.5% id, 58.1% wa, 0.0% hi, 0.0% si, 0.0% st

Dado todo esto, el rendimiento reportado al ejecutar "dstat 10" está en el rango de 2200-2300 MB / seg.

Teniendo en cuenta las matemáticas anteriores, esperaría algo en el rango de 2 * 1920 ~ = 3600+ MB / seg.

¿Alguien tiene alguna idea de dónde fue mi ancho de banda perdido?

¡Gracias!

linux storage sun sas multipath
fuente
¿La caché de los controladores SAS LSI está configurada en escritura directa? (la reescritura será más lenta para grandes cargas de trabajo secuenciales). También es posible que desee probar con un bs más pequeño para dd, como bs = 1M.
Brian

Respuestas:

1

Buena pregunta bien preparada :)

Yo mismo soy un hombre de velocidad y alimentación y creo que estás en el dinero para ser honesto. Casi esperaba ver su rendimiento más bajo de lo que es, pero lo que creo que tiene allí es una acumulación de ineficiencias menores y esperadas. Por ejemplo, es muy difícil para un bus PCIe llegar al 100% todo el tiempo, mejor asumir una tasa general baja del 90%. Dado el jitter, esto causará que también signifique que los PHY no se alimentarán al 100% todo el tiempo, por lo que perderá un poco allí, lo mismo para el caché, los discos, las interrupciones sin carbón, la programación de E / S, etc. Básicamente Si la ineficiencia es menor, la ineficiencia es menor ... y así sucesivamente, termina siendo más del 5-10% de las ineficiencias esperadas por sí mismas. He visto este tipo de cosas con servidores HP DL hablando con sus cajas MSA SAS usando W2K3 y luego siendo NLB ' ed sobre múltiples NIC: frustrante pero comprensible, supongo. Ese es mi 2c de todos modos, lo siento, no es demasiado positivo.

Chopper3
fuente