Cuello de botella de E / S de Linux con motores de datos

Tengo una máquina de 24 núcleos con 94.6GiB RAM que ejecuta el servidor Ubuntu 10.04. La caja está experimentando un alto porcentaje de iowait, a diferencia de otro servidor que tenemos (4 núcleos) ejecutando los mismos tipos y cantidades de procesos. Ambas máquinas están conectadas a un servidor de archivos VNX Raid, la máquina de 24 núcleos a través de 4 tarjetas FC y la otra a través de tarjetas Ethernet de 2 gigabits. La máquina de 4 núcleos actualmente supera a la máquina de 24 núcleos, tiene un mayor uso de CPU y un menor porcentaje de iowait.

En 9 días de tiempo de actividad, el porcentaje promedio de iowait es del 16%, y es rutinariamente superior al 30%. La mayoría de las veces el uso de la CPU es muy bajo, alrededor del 5% (debido a la gran cantidad de iowait). Hay abundante memoria libre.

Una cosa que no entiendo es por qué todos los datos parecen estar pasando por el dispositivo sdc en lugar de pasar por los motores de datos directamente:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.11    0.39    0.75   16.01    0.00   76.74

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               0.00         0.00         0.00       1232          0
sdb               0.00         0.00         0.00       2960          0
sdc               1.53        43.71        44.54   36726612   37425026
dm-0              0.43        27.69         0.32   23269498     268696
dm-1              1.00         1.86         7.74    1566234    6500432
dm-2              0.96         1.72         5.97    1442482    5014376
dm-3              0.49         9.57         0.18    8040490     153272
dm-4              0.00         0.00         0.00       1794         24
dm-5              0.00         0.00         0.00        296          0

Otra pieza del rompecabezas es que las tareas con frecuencia pasan al modo de suspensión ininterrumpible (en la parte superior), probablemente también debido al atraco io.

¿Qué puedo mirar para ayudar a diagnosticar el problema? ¿Por qué todos los datos pasan por / dev / sdc? ¿Eso es normal?

ACTUALIZAR:

La conexión de red y la capacidad de lectura / escritura de VNX se han descartado como cuellos de botella. Podemos alcanzar velocidades de 800 MB / s con las 4 NIC unidas (round-robin). Las tarjetas de canal de fibra aún no se están utilizando. El VNX es capaz de manejar el IO (RAID6, discos de 30x2TB 7.2kRPM por grupo en dos grupos (60 discos en total), aproximadamente 60% de lectura).

Ignore arriba sobre dm y sdc, todos son discos internos y no son parte del problema.

Creemos que el problema podría estar relacionado con los montajes nfs o TCP (tenemos 5 montajes en 5 particiones en el VNX), pero no sabemos exactamente qué. ¿Algún consejo?

En primer lugar, si sus CPU (¡y maldición! Eso es mucho 24) comen datos más rápido de lo que puede proporcionar el almacenamiento de datos, entonces obtiene iowait. Es entonces cuando el kernel detiene un proceso durante un bloqueo io (una lectura demasiado lenta o una escritura de sincronización).
Por lo tanto, verifique que el almacenamiento pueda proporcionar un rendimiento suficiente para 24 núcleos.

Por ejemplo, supongamos que su almacenamiento puede proporcionar un rendimiento de 500 MB / s, que está conectado a través de una línea de 2 Gigabit Ethernet (enlace), la red ya limitará el rendimiento máximo a algo alrededor de 100-180 MB / s. Si su proceso consume datos a la velocidad de 50 MB / sy ejecuta 4 subprocesos en su máquina de 4 núcleos: 4 x 50 MB / s = 200 MB / s consumidos. Si la red puede soportar los 180 MB / s, entonces no tendrá mucha latencia y sus CPU se cargarán. La red aquí es un pequeño cuello de botella.
Ahora, si escala esto hasta 24 núcleos y 24 hilos, necesitaría 1200 MB / s, incluso si cambia el cableado para permitir dicho rendimiento, su sistema de almacenamiento no proporciona más de 500 MB / s, se convierte en un cuello de botella.

Cuando se trata de esperar, los cuellos de botella pueden estar en todas partes. No solo en las capas físicas, sino también en los buffers de espacio de kernel y software. Realmente depende de los patrones de uso. Pero como los cuellos de botella del software son mucho más difíciles de identificar, generalmente es preferible verificar el rendimiento teórico en el hardware antes de investigar las pilas de software.

Como se dijo, un iowait ocurre cuando un proceso hace una lectura y los datos tardan en llegar, o cuando hace una escritura de sincronización y el reconocimiento de modificación de datos toma su tiempo. Durante una escritura de sincronización, el proceso entra en modo de suspensión ininterrumpible para que los datos no se corrompan. Hay una herramienta muy útil para ver qué llamada hace que un proceso de colgar: latencytop. No es el único de su tipo, pero puedes intentarlo.

Nota: para su información, dm significa mapeador de dispositivos, no motores de datos.

En primer lugar, ¡santo infierno que es mucho hierro! :)

Desafortunadamente, dado que su configuración suena muy compleja, no creo que nadie pueda proporcionar un "¡Este es su problema!" respuesta, a menos que hayan hecho algo con una configuración extremadamente similar o idéntica y hayan encontrado el mismo problema. Entonces, mientras este texto está etiquetado por SU como una "Respuesta", probablemente debería considerarlo más como una "Sugerencia". Y no puedo ponerlo en los comentarios porque son demasiadas palabras. : S

Sin saber cómo se asigna su hardware a los dispositivos, es difícil decir por qué la E / S va a un lugar y no a otro. ¿Cómo se montan los dispositivos? ¿Están sus programas accediendo a los sd*dispositivos directamente, o todos sus sistemas de archivos están montados en los dmdispositivos y todos los accesos a los archivos ocurren por allí?

Otras cosas que tengo que preguntar:

• ¿Qué tipo de RAID es? Si está calculando bits de paridad con RAID5 o RAID6, con suerte se ocupará del hardware del servidor de incursión ... si no, los servidores de procesamiento lo están haciendo ... lo cual es subóptimo y puede causar latencia de E / S si hecho en software.

• Aisló una de las principales diferencias entre los dos servidores en su mensaje. Uno está usando el canal de fibra y el otro está usando Ethernet. El canal de fibra debería proporcionar una mejor latencia y ancho de banda, pero tal vez eso también sea un problema: si proporciona una gran cantidad de rendimiento, podría estar haciendo que el servidor RAID esté muy ocupado ... aumenta la latencia, lo que provoca mayores esperas de E / S.

Es casi como si pudiera tener un problema de hinchamiento de búfer con sus matrices de discos, ¿sabe? Los controladores RAID de hardware normalmente tienen una gran cantidad de caché integrada, ¿no? Entonces, a medida que la E / S en los medios se pone en cola y las cachés se llenan de páginas sucias, eventualmente todo está saturado (si el almacenamiento mecánico no puede mantenerse al día con la carga) y la latencia navega por el techo ... seguramente puede producir más carga con 24 núcleos + FC que con 4 núcleos + GbE :) Compruebe el servidor RAID y vea qué tan ocupados están los discos ... muchas de las "E / S" pueden ser simplemente paquetes de control, etc. I No estoy seguro de cómo funciona el FC, pero si se parece a TCP, verás retransmisiones si las latencias son demasiado altas.

Por ejemplo, si le haces una pregunta a alguien por teléfono y no responde por unos segundos, dices "¿Hola?" - los protocolos de red (y FC es solo un protocolo de red) hacen lo mismo, solo que en un tiempo más corto. Pero, por supuesto, ese extra "¿Hola?" es costoso en el contexto de las redes porque agrega aún más datos a una tubería ya congestionada.

Para terminar, un consejo general:

Al depurar problemas de latencia / espera de E / S / rendimiento, siempre mida . Mide en todas partes. Mida en el cable, mida lo que están haciendo los propios programas, mida al final del procesamiento, mida en el servidor RAID, etc. No lo mire solo desde una perspectiva: intente considerar cada componente individual del sistema que es responsable de procesar, leer o escribir cualquiera de los datos en la tubería. Desarme una transacción o una unidad de trabajo discreta y diseccione exactamente el camino que toma a través de su hardware, y mida en cada componente distinto para ver si hay cuellos de botella o lugares donde hay latencia indebida, etc. Un amigo mío llamó a esto "peeling" back the onion ", y he usado la frase desde entonces para referirme a la tarea de depurar un flujo de datos.

Una pequeña adición. Es posible que desee ver su ajuste de nivel de bloque y los programadores de E / S en este caso. No estoy tan familiarizado con Ubuntu, pero hay una buena cantidad de perillas de rendimiento de almacenamiento para ajustar. Esto definitivamente se aplica en el caso del almacenamiento SAN y las bases de datos.

• Eche un vistazo al planificador de E / S del sistema . CFQ es el predeterminado, pero noop y la fecha límite son opciones comunes para las cargas de trabajo de la base de datos.
• Consulte este enlace para conocer otros parámetros de ajuste que pueden ayudar.
• Usted menciona NFS y el almacenamiento en bloque. Si es un bloque, ¿qué sistema (s) de archivos está en uso? La espera de E / S suena como una situación de bloqueo de escritura desde aquí. ¿Están habilitadas las barreras de escritura? Vuelva a montar sus sistemas de archivos con nobarrier. ( Sugerencia para Ubuntu )

Algunos enlaces relevantes de fallas del servidor ...

Linux: ajuste del controlador RAID de hardware del mundo real (scsi y cciss)

Gracias a todos por las ideas y aportes. El problema estaba relacionado con una combinación de configuración de enlace de Ethernet no óptima, combinada con un módulo de E / S defectuoso en el VNX. La tasa de E / S ahora está cerca de donde la esperamos. Es interesante observar que las pruebas de escritura y lectura de archivos dd y los puntos de referencia de iozone no pudieron detectar esto, y pudieron leer y escribir casi tan rápido como se esperaba.

Lo editaré con más información pronto, pero primero me gustaría decir que no debes dejar que la salida dm- * de iostat te confunda. Device-mapper es un dispositivo passthru en el núcleo al igual que md * (md0, md1, etc.), por lo que realmente solo le importan sus dispositivos subyacentes. Todos los datos que pasan a sus discos pasan por dm / md en el camino, y los totales reales (bytes, segundos, etc.) son precisos, pero la utilidad es engañosa.

Además, esa es una gran cantidad de memoria. Las cosas divertidas comienzan a suceder tan alto (yo mismo ejecuto 2x64s y 2x96s), especialmente si tienes un proceso que ocupa más de la mitad del ram. Lea este artículo para más información . El artículo menciona MySQL, pero por favor, nota que es noMySQL específico. Cada proceso de software incurrirá en penalizaciones por la memoria de acceso de otro procesador físico; piense que 48 gb pertenecen a un proceso, 48 a otro. El proceso solo puede pertenecer a un proceso y para llegar a la memoria de otros procesos (después de que se hayan agotado los 48 GB), debe decidir almacenar algunos de sus 48 en swap o pagar un precio enorme para ir y venir del la memoria de otro proc. El artículo sugiere ejecutar un comando numactl para obligar al software a no intercambiarse y en su lugar pagar la penalidad. Personalmente he visto mejoras masivas de esto. En otras palabras, ¡compruebe si parte de su E / S va a intercambiarse! Use free -m (o similar) para esto. Si tiene mucha memoria libre, pero alguna cantidad de intercambio no trivial (digamos 10% más), este podría ser su problema.

Mirando esto desde la perspectiva del almacenamiento, ¿tiene una manera de medir la latencia scsi? El tiempo de espera del sistema operativo incluye un montón de cosas que están fuera del control del almacenamiento, pero cuando entro en mi caja de almacenamiento y veo una latencia de E / S a 2 ms, sé que independientemente de lo que el servidor obtenga internamente, los comandos scsi están siendo respondidos rápidamente, y puedo eliminar el almacenamiento como una variable.