Ir al contenido 
Muestro paso a paso cómo el análisis de esperas de E/S con iostat y vmstat hace visibles los cuellos de botella y qué métricas del servidor Linux cuentan para obtener tiempos de respuesta rápidos. Al hacerlo, establezco umbrales claros, interpreto patrones típicos y sugiero medidas concretas para optimizar E/S y CPU en.
Puntos centrales
- iostat y vmstat proporcionan una visión complementaria de la carga de la CPU y del almacenamiento.
- wa a través de 15-20% y %utilo a través de 80% muestran un cuello de botella de E/S.
- await y avgqu-sz explicar la latencia y las colas.
- mpstat detecta una distribución desigual de la carga entre los núcleos de la CPU.
- Sintonización oscila entre MySQL a los parámetros del núcleo y al almacenamiento.
¿Qué significa espera de E/S en servidores Linux?
En espera de E/S, la CPU espera sin hacer nada porque está esperando dispositivos de memoria o de red más lentos, lo que se conoce como wa-valor en herramientas como top o vmstat. Evalúo esta proporción como el tiempo en el que los hilos se bloquean y las peticiones se completan más tarde, lo que los usuarios experimentan directamente como lentitud. Los valores por encima de 10-20% suelen indicar una utilización completa. Almacenamiento-subsistema, por ejemplo cuando los discos duros, las matrices RAID o los montajes NFS se utilizan al máximo de su capacidad. En las configuraciones de alojamiento con bases de datos, las consultas no indexadas y los picos de escritura se suman a los tiempos de espera innecesarios en el Disco. Si quiere repasar los conceptos, puede encontrar las nociones básicas en Entender la espera de E/S, antes de ir a la consulta.
Inicio rápido: leer vmstat correctamente
Con vmstat, puedo comprobar lo más importante Linux-y reconocer patrones iniciales sin mucho esfuerzo. La llamada vmstat 1 10 proporciona diez instantáneas en las que presto especial atención a las columnas wa (I/O wait), bi/bo (block I/O) y si/so (swap). Para mí, valores altos de bo con wa aumentando simultáneamente indican muchos accesos de escritura bloqueantes, lo que a menudo indica límites de búfer o medios lentos. Si si/so permanece en cero, pero wa aumenta significativamente, la sospecha de puro Almacenamiento-limit. En hosts multinúcleo, combino vmstat con mpstat -P ALL 1, porque la espera de E/S a menudo sólo afecta a núcleos individuales y por lo tanto parece más inofensiva en promedio de lo que realmente es.
Imagen fina de la CPU: us/sy/st, cola de ejecución y cambio de contexto
Con vmstat y mpstat leo algo más que wa: Alta usEn las secciones siguientes se muestra el trabajo de la aplicación "pesado desde el punto de vista informático", sy indica el trabajo del kernel/driver, por ejemplo con un uso intensivo de E/S. En los entornos virtualizados presto atención a st (Robo): Valores altos de st significan que la VM pierde tiempo de CPU, lo que infla artificialmente las latencias con un patrón idéntico de E/S. También comparo la cola de ejecución (r en vmstat) con el número de CPUs: Un r permanentemente más alto que el número de CPUs indica congestión en la CPU, no en el Almacenamiento. Muchos cambios de contexto (cs) en combinación con pequeñas escrituras síncronas son un indicador de patrones de E/S charlatanes. Así evito malinterpretar la escasez de CPU como un problema de E/S.
iostat en profundidad: métricas importantes
iostat -x 1 me da extendido Disco-métricas que describan claramente la latencia, la utilización y las colas. Comienzo la medición por picos de carga y correlaciono %util, await, svctm y avgqu-sz para distinguir causa y efecto. Si %util sube a 90-100%, mientras await y avgqu-sz también suben, veo una saturación de disco o un volumen limitado. Si await muestra valores altos con %util moderado, compruebo si hay interferencias del almacenamiento en caché, límites de la controladora o solicitudes individuales de gran tamaño. r/s y w/s aportan frecuencia, mientras que MB_read y MB_wrtn explican el volumen, lo que me proporciona valores comparativos importantes para configuraciones SSD dedicadas y NVMe.
NVMe, SATA y RAID: qué significan %util, await y queue depth
Hago una distinción estricta entre los tipos de medios: HDD mostrar mayor await-incluso con una señal moderada, porque dominan los movimientos de la cabeza. SSD/NVMe escalan bien con el paralelismo, por lo que una mayor avgqu-sz puede ser normal siempre que await se mantiene dentro de los límites. En NVMe con múltiples colas de envío/compleción, leo %util con más cautela: los dispositivos individuales ya pueden estar al límite a 60-70% si la aplicación no genera suficiente paralelismo o la profundidad de la cola (nr_requests, profundidad_cola) es demasiado pequeño. En el RAID Compruebo si la E/S aleatoria dispersa encuentra tamaños de franja demasiado pequeños; entonces await y %utilo de forma desigual en los discos miembros. Por lo tanto, miro iostat por dispositivo miembro, no sólo en el volumen compuesto, para hacer visibles los puntos calientes. En el caso de las capas con estructura de registro (p. ej., copia en escritura), espero latencias ligeramente superiores para las escrituras, pero lo compenso con ventanas de escritura ampliadas o procesamiento por lotes del lado de la aplicación.
Flujo de diagnóstico para tiempos de espera largos
Inicio cada análisis en paralelo con vmstat 1 e iostat -x 1 para poder ver los estados de la CPU y el estado de los dispositivos de forma sincrónica y asignarlos al tiempo. A continuación, utilizo mpstat -P ALL 1 para verificar si núcleos individuales están funcionando a un nivel inusualmente alto. wa lo que evita que se interpreten incorrectamente los valores medios. Si hay indicios de una causa, utilizo pidstat -d o iotop para ver exactamente qué PID está utilizando más recursos compartidos de E/S. En entornos de hospedaje con bases de datos, primero diferencio entre picos de lectura y escritura, ya que las estrategias de write-back y los patrones de fsync generan síntomas muy diferentes y, por lo tanto, se pueden utilizar para picos específicos. Medidas lo hacen posible. Para preguntas más profundas sobre almacenamiento, una visión general como la de Cuello de botella de E/S en el alojamiento, antes de retocar el kernel o el sistema de archivos.
Clara delimitación entre virtualización y contenedores
En VMs considero wa junto con st (Steal) y adicionalmente medir en el hipervisor, porque sólo allí los dispositivos reales y Cues son visibles. Las agregaciones de almacenamiento (thin provisioning, dedupe, snapshots) desplazan los picos de latencia hacia abajo en la pila - en la VM, esto tiene el siguiente efecto await salta, mientras que %util permanece discreto. En los contenedores limito o desacoplo E/S con las reglas de Cgroup (por ejemplo, límites de IOPS/rendimiento) para Vecinos ruidosos para domarlos. Documento los límites por servicio para que los valores medidos sean reproducibles y las alarmas conserven su contexto. Importante: Un alto wa en la máquina virtual pueden ser desencadenados por copias de seguridad, depuraciones o reconstrucciones de todo el host - correlaciono los tiempos con los trabajos del host antes de tocar la aplicación.
Límites, umbrales y próximos pasos
Utilizo unos umbrales claros para decidir si existe un cuello de botella real y qué medidas tomar para estabilizar notablemente el rendimiento. Tengo en cuenta el tipo de soporte, la carga de trabajo y los requisitos de latencia, porque las mismas cifras en HDD y NVMe tienen implicaciones diferentes. Utilizo la siguiente tabla como guía rápida que empleo en mis playbooks. Mido varias veces durante minutos y bajo carga para que los valores atípicos no generen falsas alarmas y pueda reconocer tendencias. Esto me sirve de base para tomar medidas específicas en lugar de sustituir el hardware por reflejo. Parámetros masivamente.
| Métricas | Umbral | interpretación | Próximos pasos |
|---|---|---|---|
| wa (vmstat) | > 15-20% | Tiempo de espera de E/S significativo | Compruebe iostat; encuentre la causa con pidstat/iotop; analice el almacenamiento en caché y las escrituras |
| %utilo (iostat) | > 80-90% | Dispositivo utilizado | correlacionar await/avgqu-sz; comprobar la profundidad de la cola, el programador, RAID y SSD/NVMe |
| await (ms) | > 10-20 ms SSD, > 30-50 ms HDD | Aumento de la latencia | Diferenciar entre aleatorio y secuencial; personalizar las opciones del sistema de archivos, writeback, journaling |
| avgqu-sz | > 1-2 persistente | La cola crece | Acelerar/aumentar el paralelismo; optimizar el patrón de E/S de la aplicación; comprobar los límites del controlador. |
| si/so (vmstat) | > 0 bajo carga | Cuello de botella en el almacenamiento | Aumento de RAM; ajuste de consultas/caché; comprobación de los límites de memoria/swappiness |
Causas en la pila: BD, sistema de archivos, virtualización
Con las bases de datos, a menudo veo uniones no indexadas, búferes demasiado pequeños y excesivas llamadas a fsync, ya que la actual Causas para valores await altos. Compruebo los planes de consulta, activo los registros de sentencias lentas y ajusto objetivamente tamaños como el buffer pool de InnoDB, los tamaños de los archivos de registro y los archivos abiertos. A nivel del sistema de archivos, me fijo en las opciones de montaje, los modos de diario y la alineación con la banda RAID, porque las combinaciones incorrectas hacen que los tiempos de espera se disparen. En las configuraciones virtualizadas, no me baso únicamente en las mediciones de la máquina virtual, sino que me fijo en el host, ya que es aquí donde se encuentran los dispositivos de bloque reales y los archivos abiertos. Cues se hacen visibles. Esto me permite separar claramente los efectos de la deduplicación, el thin provisioning o las máquinas virtuales vecinas de los patrones de aplicación.
Sistema de archivos y opciones de montaje en detalle
Evalúo los sistemas de archivos en función de la carga de trabajo: ext4 en modo ordenado o writeback minimiza las barreras a la intensidad de escritura, mientras que XFS puntúa con su diseño de registro para cargas de trabajo paralelas. Opciones como noatime o relatime reducir las escrituras de metadatos, lazytime mueve las actualizaciones de marcas de tiempo al writeback en paquetes. Para journaling, compruebo los intervalos de commit (por ejemplo, commit=) y compruebo si los force flushes (barreras) son exacerbados por las políticas de caché del controlador. En RAID presto atención a la alineación limpia a la banda (Parted/FDISK con 1MiB de inicio), de lo contrario await mediante Lectura-Modificación-Escritura incluso con patrones supuestamente secuenciales. Para las bases de datos, a menudo utilizo O_DIRECT o estrategias de vaciado directo del registro - pero sólo después de la medición, porque la caché del sistema de archivos puede reducir drásticamente la carga de lectura si el conjunto de trabajo cabe en ella.
Tuning: del núcleo a la aplicación
Empiezo con victorias sencillas, por ejemplo indexación de consultas, escritura por lotes y configuración sensata de agrupación de conexiones, antes de empezar a nivel de sistema. Para la recuperación de escritura, ajusto vm.dirty_background_ratio, vm.dirty_ratio y vm.dirty_expire_centisecs de forma controlada para que el sistema escriba de forma contigua y genere menos bloqueos sin atascar la memoria. En los dispositivos de bloque, compruebo el programador de E/S, la profundidad de la cola y la lectura anticipada, ya que estos parámetros determinan directamente la latencia y el rendimiento. En las controladoras RAID, ajusto el tamaño de las bandas y la política de caché, mientras que en SSD/NVMe para firmware, TRIM y ajustes de sobreaprovisionamiento consistentes. Después de cada cambio, verifico con vmstat e iostat durante varios minutos si await cae y %util permanece estable antes de dar el siguiente paso.
Interrupciones, NUMA y afinidades
Superviso la carga IRQ y la topología NUMA porque ambas tienen un efecto notable en las latencias. NVMe-Enlazo las interrupciones a las CPU del dominio NUMA del controlador mediante afinidad para que las rutas de datos sigan siendo cortas. Si la tormenta IRQ se está ejecutando en un núcleo, veo alta sy y el resto de CPUs parecen estar inactivas; mpstat expone esto. Sólo permito irqbalance si la distribución coincide con el hardware - de lo contrario establezco afinidades específicas. También compruebo si la aplicación y su E/S trabajan en la misma zona NUMA (ubicación de almacenamiento), ya que los accesos entre sockets provocan tiempos de espera en await puede enmascararse.
Automatizar y visualizar las mediciones
Para asegurarme de que reconozco las tendencias, automatizo las mediciones e integro iostat/vmstat en las herramientas de supervisión, que pueden mostrar datos históricos. Datos guardar. Establezco alarmas conservadoras, por ejemplo de wa > 15% en varios intervalos, combinadas con umbrales de await y %util para evitar falsas alarmas. Para las pantallas de métricas generales, utilizo cuadros de mando que yuxtaponen las métricas de CPU, almacenamiento, red y aplicación para que las correlaciones sean inmediatamente visibles. Si necesitas una introducción a las métricas, puedes encontrarlas en Métricas del servidor contexto compacto para el trabajo diario. Lo importante para mí es un proceso repetible: medir, formular una hipótesis, realizar el ajuste, volver a medir y finalizar los resultados. Resultados documento.
Pruebas de carga reproducibles con fio
Si carezco de una carga real o quiero verificar hipótesis, utilizo los de corta duración fio-pruebas. Simulo patrones representativos (por ejemplo, lectura aleatoria de 4k, escritura secuencial de 64k, perfiles mixtos 70/30) y varío iodepth, para fijar la ventana del punto óptimo entre await y el rendimiento. Separo estrictamente las rutas de prueba de los datos de producción y anoto las condiciones límite (sistema de archivos, opciones de montaje, programador, profundidad de cola) para poder clasificar los resultados correctamente. Tras la puesta a punto, se utilizan las mismas pruebas como comprobación de regresión; sólo cuando await y %utilo consistentemente se ven mejor, aplico cambios a la superficie.
Reconocer patrones de error: patrones típicos
Si observo alta wa con simultáneamente alta %utile y creciente avgqu-sz, todo habla a favor de la saturación en el Dispositivo, es decir, límites físicos reales. Los valores await altos con %util moderado tienden a indicar peculiaridades del controlador o de la caché, como barreras, write-through o descargas esporádicas. Valores de si/so crecientes junto con caídas en la caché indican claramente una falta de RAM, que infla artificialmente la E/S y aumenta los tiempos de espera. Si el disco sigue siendo discreto, pero la aplicación enmarca escrituras grandes y con mucha sincronización, cambio el trabajo a escritura asíncrona, pipelining o Lote-mecanismos. En configuraciones NFS o de almacenamiento en red, también compruebo la latencia, la MTU, las retransmisiones y el almacenamiento en caché del lado del servidor, porque el tiempo de red se enmascara directamente como latencia de E/S aquí.
NFS/iSCSI y almacenamiento distribuido
En NFS e iSCSI, diferencio entre dispositivo y ruta de red: iostat sólo muestra lo que ve la capa de bloque - también reconozco retransmisiones, latencias y problemas de ventana mediante métricas de red. Alto await con moderada %utilo en el dispositivo de bloque virtual es típico cuando la red se atasca o la caché del lado del servidor se enfría. Para NFS compruebo las opciones de montaje (rsize/wsize, proto, sync/async) y el lado del servidor (hilos, políticas de exportación, caché), para iSCSI los parámetros de sesión y cola. Planifico las ventanas de mantenimiento de los trabajos del servidor (scrubs, reconstrucciones, reequilibrios) para que no saturen el almacenamiento compartido en las horas punta y provoquen así la indisponibilidad del servidor. wa en todos los clientes.
Ejemplos prácticos: tres escenarios breves
Grupo de blogs con consejos para escribir
En prime time, los comentarios y la invalidación de caché aumentan, con lo que await y avgqu-sz en iostat aumentan significativamente, mientras que %util se mantiene en 95%. Aumento suavemente los parámetros de writeback, optimizo la invalidación de caché a nivel de ruta y aumento el búfer de registro de InnoDB para que haya menos escrituras de sincronización pequeñas. Después de esto, await cae de forma apreciable, los valores de bo siguen siendo altos, pero wa cae, lo que reduce inmediatamente los tiempos de respuesta. Al mismo tiempo, sustituyo los discos duros individuales por discos SSD para el diario, lo que además alivia el cuello de botella. El patrón muestra cómo Lote-Combina la escritura con un diario más rápido.
Tienda con picos de lectura e índices de búsqueda
Las promociones generan una gran carga de lectura, el r/s se dispara, la espera se mantiene moderada, pero la aplicación sigue reaccionando con lentitud a la navegación por los filtros. Reconozco muchas consultas sin búfer y sin índices adecuados que superan el conjunto de trabajo de la caché del sistema de archivos. Con la indexación selectiva y la reescritura de consultas, la r/s desciende, los aciertos se encuentran más a menudo en la caché e iostat confirma una menor MB_read con el mismo rendimiento. Al mismo tiempo, aumento ligeramente la lectura anticipada para servir los escaneos secuenciales de forma más eficiente, lo que reduce aún más las latencias. Así compruebo que Leer-patrones conducen a golpes de caché de nuevo.
VM host con „Vecino ruidoso“
En VMs individuales, top muestra alto wa, pero iostat en la VM sólo ve dispositivos virtuales con utilización engañosa. También mido en el hipervisor, veo dispositivos de bloque reales saturados e identifico una máquina virtual vecina con copias de seguridad agresivas como la causa. Los límites de ancho de banda y las ventanas de copia de seguridad modificadas estabilizan await y %util en todo el host. A continuación, vuelvo a medir en la máquina virtual y en el host para confirmar y evitar el efecto en ambos lados. Esto confirma que Dispositivos-las métricas siempre muestran la verdad en el anfitrión.
Lista de control para el próximo incidente
Primero inicio los registros y las mediciones para no perder ninguna señal, y mantengo vmstat 1 e iostat -x 1 en funcionamiento durante varios minutos. A continuación, establezco una correlación temporal entre los picos y los eventos de la aplicación y los temporizadores del sistema, antes de localizar los procesos individuales con pidstat -d y formular hipótesis. El siguiente paso es comprobar los accesos a la memoria, la swap y la caché para que la escasez de RAM no se reconozca erróneamente como un error. Disco-aparece el problema. Sólo cuando he aislado la causa, cambio exactamente una cosa, registro la configuración y evalúo el efecto en await, %util y wa. De este modo, mantengo la reproducibilidad del análisis, aprendo de cada incidente y reduzco el tiempo que transcurre hasta que aparece el problema. Solución claramente.
Malas interpretaciones y tropiezos frecuentes
No me engañan los picos aislados: Segundos aislados con wa son normales, sólo las mesetas persistentes indican un cuello de botella estructural. %utilo cercano a 100% sólo es crítico si await se activa al mismo tiempo; de lo contrario, el dispositivo simplemente está ocupado. En SSD/NVMe es un avgqu-sz A menudo es intencionado, para aprovechar el paralelismo interno; sólo acelero cuando no se alcanzan los objetivos de latencia. Compruebo el escalado de frecuencia de la CPU: un ahorro de energía agresivo puede aumentar los tiempos de respuesta y, por tanto, el rendimiento. wa parecen empeorar. Y separo TTFB de aplicación de la latencia de almacenamiento - red, handshakes TLS y servicios de aguas arriba pueden producir síntomas similares sin iostat „es “culpable".
Breve resumen para administradores
El análisis de esperas de E/S con iostat y vmstat funciona rápidamente si leo wa, await, %util y avgqu-sz juntos y los relaciono con el contexto de la carga de trabajo. Primero identifico si hay una saturación real del dispositivo o si los patrones de memoria y aplicación están impulsando la latencia, y luego selecciono la palanca adecuada. Los ajustes pequeños y específicos de las consultas, los parámetros de escritura, los programadores o la profundidad de las colas suelen tener el mayor efecto antes de que sea necesario realizar cambios costosos en el hardware. Medición, hipótesis, cambio y nueva medición siguen siendo mi secuencia fija para que las decisiones sigan siendo comprensibles y repetibles. Así es como mantengo Linux-el servidor responde mejor y garantiza una mejora notable Tiempos de respuesta bajo carga.
