Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a: ✔️ Máquinas virtuales Linux
Resumen
Identificación y resolución de problemas de rendimiento de CPU, memoria, y entrada y salida de disco, así como la identificación de cuellos de botella en máquinas virtuales Linux en Azure.
Problemas de rendimiento y cuellos de botella
Los problemas de rendimiento pueden producirse en diferentes sistemas operativos y aplicaciones. Cada escenario requiere un enfoque de solución de problemas específico. En las máquinas virtuales Linux, los problemas de rendimiento suelen aparecer en una o varias áreas de recursos principales: CPU, memoria, redes y entrada/salida (E/S). Cada recurso presenta síntomas distintos, a menudo superpuestos, y requiere diferentes métodos de diagnóstico y estrategias de corrección.
En muchos casos, los problemas de aplicación o configuración provocan una degradación del rendimiento, no la propia plataforma. Por ejemplo, una aplicación web con una capa de almacenamiento en caché mal configurada podría enrutar solicitudes excesivas al servidor de origen en lugar de atenderlas desde la memoria caché. Esta configuración incorrecta aumenta los tiempos de carga y respuesta de la CPU. Del mismo modo, la selección de ubicación del almacenamiento puede afectar a las cargas de trabajo de base de datos. Si el registro de puesta al día de una base de datos MySQL o MariaDB reside en el disco del sistema operativo o en el almacenamiento que no cumple los requisitos de rendimiento de la base de datos, la contención de E/S puede provocar una mayor latencia y transacciones reducidas por segundo (TPS).
La solución de problemas eficaz comienza con comprender el problema e identificar dónde existe el cuello de botella en la pila, ya sea CPU, memoria, red o E/S. Establecer una línea de base de rendimiento es fundamental, ya que permite comparar las métricas antes y después de los cambios y determinar si esos cambios dan lugar a una mejora medible.
La solución de problemas de rendimiento en una máquina virtual es fundamentalmente la misma que en un sistema físico: el objetivo es determinar qué recurso limita el rendimiento general. Los cuellos de botella siempre existen en cualquier sistema. La solución de problemas de rendimiento es el proceso de identificar el cuello de botella actual y, cuando sea posible, cambiarlo a un recurso menos restrictivo.
Esta guía le ayuda a identificar y resolver problemas de rendimiento en máquinas virtuales de Azure basadas en Linux por centrarse en aislar cuellos de botella y aplicar diagnósticos específicos.
Identificación del cuello de botella probable
Comience a solucionar problemas mediante la observación del comportamiento del sistema y las relaciones de métricas, no el uso de recursos individuales de forma aislada. Los cuellos de botella de rendimiento a menudo aparecen indirectamente y el recurso limitado no siempre es el más obvio.
En la tabla siguiente se asignan observaciones comunes y patrones de métricas al recurso más probable que investigue primero.
| Observación o señal | Es probable que el cuello de botella se investigue | Justificación |
|---|---|---|
| Promedio de carga alta con un uso bajo de CPU | Disco (E/S) | Los procesos se bloquean en espera de E/S en lugar de ejecutarse en la CPU |
| Uso elevado de CPU con un promedio de carga baja | Diseño de aplicaciones o carga de trabajo de un solo subproceso | La CPU está ocupada, pero no está saturada entre núcleos disponibles |
| Aumento de la latencia de solicitudes bajo carga, CPU no saturada | Disco o red | La latencia a menudo aumenta antes de que se alcancen los límites de uso. |
| Fluctuaciones de uso de CPU agudas con una carga de trabajo estable | Control de rendimiento de CPU o límites de ráfagas | La disponibilidad de la CPU puede variar debido a restricciones de plataforma |
| Latencia de E/S alta con un rendimiento bajo | Saturación o limitación de disco | Aumento de la latencia antes de alcanzar los límites de ancho de banda |
| Aumento gradual del uso de memoria a lo largo del tiempo | Pérdida de memoria o crecimiento de caché | La presión de memoria se desarrolla progresivamente en lugar de inmediatamente |
| Eventos fuera de memoria (OOMKilled) a pesar del espacio en disco disponible | Memoria | La disponibilidad del disco no mitiga el agotamiento de RAM |
| Métricas de disco aceptables, pero E/S de aplicación lenta | Patrón de E/S de aplicación | Las operaciones de E/S pequeñas o sincrónicas limitan el rendimiento. |
| Rendimiento de red por debajo de las expectativas | Límites de tamaño de máquina virtual o tarjeta de interfaz de red (NIC) | El ancho de banda de red está limitado por la SKU de máquina virtual |
| Degradación del rendimiento solo durante el uso máximo | Restricción de capacidad | Los límites de recursos solo se alcanzan con simultaneidad |
Después de identificar el patrón más relevante, continúe con la sección de recursos correspondiente para obtener diagnósticos y validación detallados.
Importante
Los cuellos de botella se identifican mediante relaciones entre métricas, no por valores de uso individuales. Interprete siempre los datos de CPU, memoria, disco y red juntos.
Recopilación de información de rendimiento
Use estas conclusiones de rendimiento para validar si existe un cuello de botella de recursos.
Las distintas herramientas recopilan datos de rendimiento en función del recurso que se está investigando. En la tabla siguiente se muestran herramientas de ejemplo para los recursos principales.
| Recurso | Herramienta |
|---|---|
| Unidad Central de Procesamiento (CPU) |
top, htop, mpstat, , pidstat, vmstat |
| Disco |
iostat, , iotop, vmstat |
| Red |
ip, , vnstat, iperf3 |
| Memoria |
free, , top, vmstat |
En las secciones siguientes se describen los datos de rendimiento y las herramientas que puede usar para la investigación.
Recurso de CPU
El uso de CPU representa el porcentaje de tiempo que el procesador ejecuta activamente el trabajo frente al resto de inactividad. De forma similar, los procesos pasan tiempo en la CPU (como el uso del 80 por ciento usr ) o no (como el 80 por ciento de inactividad). La herramienta principal para verificar el uso de la CPU es top.
La top herramienta se ejecuta en modo interactivo de forma predeterminada. Se actualiza cada segundo y muestra los procesos ordenados por uso de CPU:
top
top - 19:02:00 up 2:07, 2 users, load average: 1.04, 0.97, 0.96
Tasks: 191 total, 3 running, 188 sleeping, 0 stopped, 0 zombie
%Cpu(s): 29.2 us, 22.0 sy, 0.0 ni, 48.5 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 7990204 total, 6550032 free, 434112 used, 1006060 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7243640 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd
1680 root 20 0 410268 38596 5644 S 3.0 0.5 2:15.10 python
772 root 20 0 90568 3240 2316 R 0.3 0.0 0:08.11 rngd
1472 root 20 0 222764 6920 4112 S 0.3 0.1 0:00.55 rsyslogd
10395 theuser 20 0 162124 2300 1548 R 0.3 0.0 0:11.93 top
1 root 20 0 128404 6960 4148 S 0.0 0.1 0:04.97 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:00.56 ksoftirqd/0
7 root rt 0 0 0 0 S 0.0 0.0 0:00.07 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.0 0.0 0:06.00 rcu_sched
10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 lru-add-drain
11 root rt 0 0 0 0 S 0.0 0.0 0:00.05 watchdog/0
12 root rt 0 0 0 0 S 0.0 0.0 0:00.04 watchdog/1
13 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/1
14 root 20 0 0 0 0 S 0.0 0.0 0:00.21 ksoftirqd/1
16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
18 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
19 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khungtaskd
21 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kintegrityd
Ahora, examine la línea del proceso dd de esa salida:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22804 root 20 0 108096 616 516 R 99.7 0.0 1:05.71 dd
Puede ver que el dd proceso consume el 99,7 % de la CPU.
Nota:
Para mostrar el uso por CPU en la
topherramienta, seleccione 1.La
topherramienta muestra un uso total de más del 100 % si el proceso es multiproceso y abarca más de una CPU.
Otra referencia útil es la media de carga. El promedio de carga muestra una carga media del sistema en intervalos de 1 minuto, 5 minutos y 15 minutos. El valor muestra el nivel de carga del sistema. La interpretación de este valor depende del número de CPU disponibles. Por ejemplo, si el promedio de carga es 2 en un sistema de una CPU, el sistema está tan cargado que los procesos se acumulan en cola. Si hay un promedio de carga de 2 en un sistema de cuatro CPU, hay aproximadamente un 50 % de uso general de la CPU.
Nota:
Puede obtener rápidamente el recuento de CPU ejecutando el nproc comando .
En el ejemplo anterior, el promedio de carga es de 1,04. Se trata de un sistema de dos CPU, lo que significa que hay aproximadamente un 50 % de uso de CPU. Puede comprobar este resultado si observa el valor de CPU inactivo del 48,5 %. (En la salida del top comando, el valor de CPU inactivo se muestra antes de la id etiqueta).
Use el promedio de carga como información general rápida sobre cómo funciona el sistema.
Ejecute el comando para obtener el uptime promedio de carga.
Importante
El promedio de carga proporciona contexto para el uso de CPU. Una carga alta con un bajo tiempo de CPU inactiva indica saturación, mientras que una carga alta cuando la CPU está inactiva suele apuntar a cuellos de botella que no involucran a la CPU.
Recurso de disco (Entrada/Salida)
Los siguientes términos ayudan a explicar cómo identificar y comprender los contadores de rendimiento de E/S.
| Término | Descripción |
|---|---|
| Tamaño de E/S | Cantidad de datos procesados por transacción, normalmente definidos en bytes. |
| Subprocesos de E/S | Número de procesos que interactúan con el dispositivo de almacenamiento. Este valor depende de la aplicación. |
| Tamaño de bloque | Tamaño de E/S definido por el dispositivo de bloque subyacente. |
| Tamaño del sector | Tamaño de cada uno de los sectores del disco. Este valor suele ser de 512 bytes. |
| IOPS | Operaciones de entrada y salida por segundo. |
| Latency | El tiempo que tarda una operación de E/S en finalizar. Este valor se mide normalmente en milisegundos (ms). |
| Rendimiento | Función de la cantidad de datos transferidos durante un período de tiempo específico. Este valor se define normalmente como megabytes por segundo (MB/s). |
IOPS
Las operaciones de salida de entrada por segundo (IOPS) miden el número de operaciones de entrada y salida (E/S) durante un tiempo específico, normalmente segundos. Las operaciones de E/S incluyen lecturas y escrituras. El sistema también puede contar eliminaciones o descartes como operaciones en el sistema de almacenamiento. Cada operación tiene una unidad de asignación que coincide con el tamaño de E/S.
Las aplicaciones suelen definir el tamaño de E/S como la cantidad de datos escritos o leídos por transacción. Un tamaño de E/S común es 4K. Sin embargo, un tamaño de E/S más pequeño con más subprocesos da como resultado un valor de IOPS mayor. Dado que cada transacción finaliza rápidamente debido a su tamaño pequeño, un tamaño de E/S más pequeño permite que se completen más transacciones en la misma cantidad de tiempo.
Por otro lado, si usa el mismo número de subprocesos, pero elige un tamaño de E/S mayor, IOPS disminuye porque cada transacción tarda más tiempo en completarse. Sin embargo, aumenta el rendimiento.
Considere el ejemplo siguiente:
1000 IOPS significa que cada segundo, mil operaciones finalizan. Cada operación tarda aproximadamente un milisegundo. (Hay 1000 milisegundos en un segundo). En teoría, cada transacción tiene aproximadamente un milisegundo para finalizar o aproximadamente una latencia de 1 ms.
Si conoce el valor de IOSize y las IOPS, puede calcular el rendimiento multiplicando IOSize por IOPS.
Por ejemplo:
1000 IOPS en 4K IOSize = 4000 KB/s o 4 MB/s (3,9 MB/s para ser precisos)
1000 IOPS en 1M IOSize = 1000 MB/s o 1 GB/s (976 MB/s para ser precisos)
Puede escribir una versión más compatible con ecuaciones de la siguiente manera:
IOPS * IOSize = IOSize/s (Throughput)
Rendimiento
A diferencia de IOPS, el rendimiento es una función de la cantidad de datos a lo largo del tiempo. Esta medida significa que, durante cada segundo, se escribe o lee una determinada cantidad de datos. Esta velocidad se mide en <cantidad de datos por tiempo>/, o <megabytes por segundo (MB/s).>
Cuando conozca los valores de rendimiento y tamaño de E/S, puede calcular IOPS dividiendo el rendimiento por el tamaño de E/S. Debe normalizar ambos valores en la misma unidad de medida. Por ejemplo, si el tamaño de E/S se define en kilobytes (KB), debe convertir el rendimiento en KB antes de realizar el cálculo.
El formato de ecuación se escribe de la siguiente manera:
Throughput / IOSize = IOPS
Para poner esta ecuación en contexto, considere un rendimiento de 10 MB/s con un tamaño de I/O de 4K. Al escribir los valores en la ecuación, el resultado es 10,240/4=2,560 IOPS.
Nota:
10 MB es exactamente igual a 10 240 KB.
Latencia
La latencia es la medición de la cantidad media de tiempo que tarda cada operación en finalizar. Las IOPS y la latencia están relacionadas porque ambos conceptos son una función del tiempo. Por ejemplo, en 100 IOPS, cada operación tarda aproximadamente 10 ms en completarse. Pero la misma cantidad de datos se puede capturar incluso más rápido en IOPS inferiores. La latencia también se conoce como tiempo de búsqueda.
Descripción de la salida de iostat
Como parte del paquete sysstat, la iostat herramienta proporciona información sobre el rendimiento del disco y las métricas de uso.
iostat puede ayudar a identificar cuellos de botella relacionados con el subsistema de disco.
Puede ejecutar la iostat utilidad mediante un comando simple. La sintaxis básica se muestra de la siguiente manera:
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
Los parámetros dictan qué información iostat proporciona. Sin ningún parámetro de comando, iostat muestra los detalles básicos:
iostat
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76) 08/05/2019 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
41.06 0.00 30.47 21.00 0.00 7.47
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 182.77 5072.69 1066.64 226090 47540
sdd 2.04 42.56 22.98 1897 1024
sdb 12.61 229.23 96065.51 10217 4281640
sdc 2.56 46.16 22.98 2057 1024
md0 2.67 73.60 45.95 3280 2048
De forma predeterminada, iostat muestra los datos de todos los dispositivos de bloque existentes, aunque proporciona datos mínimos para cada dispositivo. Para ayudar a identificar problemas, use parámetros que proporcionen datos extendidos, como rendimiento, IOPS, tamaño de cola y latencia.
Ejecute iostat especificando desencadenadores:
iostat -dxctm 1
Para expandir aún más los iostat resultados, use los parámetros siguientes.
| Parámetro | Acción |
|---|---|
-d |
Muestra el informe de uso del dispositivo. |
-x |
Mostrar estadísticas extendidas. Este parámetro es importante porque proporciona IOPS, latencia y tamaños de cola. |
-c |
Muestra el informe de uso de CPU. |
-t |
Imprima la hora de cada informe que se muestra. Este parámetro es útil para ejecuciones largas. |
-m |
Mostrar estadísticas en megabytes por segundo, un formulario más legible. |
El número 1 del comando indica iostat que se actualice cada segundo. Para detener la actualización, seleccione Ctrl+C.
Si incluye los parámetros adicionales, la salida es similar al texto siguiente:
iostat -dxctm 1
Linux 3.10.0-957.21.3.el7.x86_64 (rhel76) 08/05/2019 _x86_64_ (1 CPU)
08/05/2019 07:03:36 PM
avg-cpu: %user %nice %system %iowait %steal %idle
3.09 0.00 2.28 1.50 0.00 93.14
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.02 0.52 9.66 2.46 0.31 0.10 70.79 0.27 23.97 6.68 91.77 2.94 3.56
sdd 0.00 0.00 0.12 0.00 0.00 0.00 64.20 0.00 6.15 6.01 12.50 4.44 0.05
sdb 0.00 22.90 0.47 0.45 0.01 5.74 12775.08 0.17 183.10 8.57 367.68 8.01 0.74
sdc 0.00 0.00 0.15 0.00 0.00 0.00 54.06 0.00 6.46 6.24 14.67 5.64 0.09
md0 0.00 0.00 0.15 0.01 0.00 0.00 89.55 0.00 0.00 0.00 0.00 0.00 0.00
Descripción de los valores
Las columnas principales de la iostat salida se muestran en la tabla siguiente.
| Columna | Descripción |
|---|---|
r/s |
Lecturas por segundo (IOPS) |
w/s |
Escrituras por segundo (IOPS) |
rMB/s |
Lectura de megabytes por segundo (rendimiento) |
wMB/s |
Escritura de megabytes por segundo (rendimiento) |
avgrq-sz |
Tamaño medio de E/S en sectores; multiplique este número por el tamaño del sector, que suele ser de 512 bytes, para obtener el tamaño de E/S en bytes (tamaño de E/S) |
avgqu-sz |
Tamaño medio de la cola (el número de operaciones de E/S en cola en espera de ser atendidas) |
await |
Promedio de tiempo en milisegundos para la E/S atendida por el dispositivo (latencia) |
r_await |
Promedio de tiempo de lectura en milisegundos para la E/S atendida por el dispositivo (latencia) |
w_await |
Promedio de tiempo de lectura en milisegundos para la E/S atendida por el dispositivo (latencia) |
Los datos presentados por iostat son informativos, pero la presencia de determinados datos en determinadas columnas no significa que haya un problema. Capture y analice siempre los datos de iostat para identificar posibles cuellos de botella. Una latencia alta podría indicar que el disco está alcanzando un punto de saturación.
Nota:
Puede usar el pidstat -d comando para ver las estadísticas de E/S por proceso.
Importante
Los valores individuales iostat no indican un problema por sí solo. Una alta latencia sostenida o una profundidad de cola bajo carga es un indicador más seguro de saturación del disco.
Recurso de red
Las redes pueden experimentar dos cuellos de botella principales: ancho de banda bajo y latencia alta.
Puede usar vmstat para capturar en vivo los detalles del ancho de banda. Sin embargo, vnstat no está disponible en todas las distribuciones. La herramienta ampliamente disponible iptraf-ng es otra opción para ver el tráfico de la interfaz en tiempo real.
Latencia de red
Puede determinar la latencia de red entre dos sistemas diferentes mediante el comando simple ping del Protocolo de mensajes de control de Internet (ICMP):
ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=5.33 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=5.29 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=5.24 ms
^C
--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 5.240/5.291/5.339/0.035 ms
Para detener la actividad de ping, seleccione Ctrl+C.
Ancho de banda de la red
Compruebe el ancho de banda de red mediante herramientas como iperf3. La iperf3 herramienta funciona en el modelo de servidor o cliente. Inicie la aplicación especificando la -s bandera del servidor. A continuación, los clientes se conectan al servidor especificando la dirección IP o el nombre de dominio completo (FQDN) del servidor junto con la -c marca . Los fragmentos de código siguientes muestran cómo usar la iperf3 herramienta en el servidor y el cliente.
Server
iperf3 -s----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------Client
iperf3 -c 10.1.0.4
Connecting to host 10.1.0.4, port 5201
[ 5] local 10.1.0.4 port 60134 connected to 10.1.0.4 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 5.78 GBytes 49.6 Gbits/sec 0 1.25 MBytes
[ 5] 1.00-2.00 sec 5.81 GBytes 49.9 Gbits/sec 0 1.25 MBytes
[ 5] 2.00-3.00 sec 5.72 GBytes 49.1 Gbits/sec 0 1.25 MBytes
[ 5] 3.00-4.00 sec 5.76 GBytes 49.5 Gbits/sec 0 1.25 MBytes
[ 5] 4.00-5.00 sec 5.72 GBytes 49.1 Gbits/sec 0 1.25 MBytes
[ 5] 5.00-6.00 sec 5.64 GBytes 48.5 Gbits/sec 0 1.25 MBytes
[ 5] 6.00-7.00 sec 5.74 GBytes 49.3 Gbits/sec 0 1.31 MBytes
[ 5] 7.00-8.00 sec 5.75 GBytes 49.4 Gbits/sec 0 1.31 MBytes
[ 5] 8.00-9.00 sec 5.75 GBytes 49.4 Gbits/sec 0 1.31 MBytes
[ 5] 9.00-10.00 sec 5.71 GBytes 49.1 Gbits/sec 0 1.31 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 57.4 GBytes 49.3 Gbits/sec 0 sender
[ 5] 0.00-10.04 sec 57.4 GBytes 49.1 Gbits/sec receiver
iperf Done.
En la tabla siguiente se muestran algunos parámetros comunes iperf3 para el cliente.
| Parámetro | Descripción |
|---|---|
-P |
Especifica el número de flujos de cliente paralelos que se van a ejecutar. |
-R |
Redirecciona el tráfico. De forma predeterminada, el cliente envía datos al servidor. |
--bidir |
Prueba tanto la carga como la descarga. |
Importante
El rendimiento de la red en Azure está limitado por tamaño de máquina virtual. Las limitaciones de rendimiento suelen provenir de límites de máquina virtual o disco en lugar de la propia red.
Recurso de memoria
La memoria es otro recurso de solución de problemas para comprobar porque las aplicaciones podrían usar o no una parte de la memoria. Puede usar herramientas como free y top para revisar el uso general de la memoria y determinar la cantidad de memoria que consumen varios procesos:
free -m
total used free shared buff/cache available
Mem: 7802 435 5250 9 2117 7051
Swap: 0 0 0
En los sistemas Linux, es habitual ver el uso de memoria del 99 %. En la free salida, hay una columna denominada buff/cache. El kernel de Linux usa memoria libre (sin usar) para almacenar en caché las solicitudes de E/S para mejorar los tiempos de respuesta. Este proceso se denomina caché de páginas. Durante la presión de memoria (escenarios en los que la memoria está baja), el kernel devuelve la memoria que se usa para el caché de páginas para que las aplicaciones puedan usar esa memoria.
En la free salida, la columna disponible indica la cantidad de memoria disponible para los procesos que se van a consumir. Este valor se calcula agregando las cantidades de memoria buff/caché y memoria libre.
Puede configurar el top comando para ordenar los procesos por uso de memoria. De forma predeterminada, top ordena por porcentaje de CPU (%). Para ordenar por uso de memoria (%), seleccione Mayús+M al ejecutartop. En el texto siguiente se muestra la salida del top comando:
top
top - 22:40:15 up 5:45, 2 users, load average: 0.08, 0.08, 0.06
Tasks: 194 total, 2 running, 192 sleeping, 0 stopped, 0 zombie
%Cpu(s): 12.3 us, 41.8 sy, 0.0 ni, 45.4 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 st
KiB Mem : 7990204 total, 155460 free, 5996980 used, 1837764 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1671420 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
45283 root 20 0 5655348 5.3g 512 R 99.7 69.4 0:03.71 tail
3124 omsagent 20 0 415316 54112 5556 S 0.0 0.7 0:30.16 omsagent
1680 root 20 0 413500 41552 5644 S 3.0 0.5 6:14.96 python
[...]
La RES columna indica memoria residente. Este valor representa el uso real del proceso. La top herramienta proporciona una salida similar a free en términos de kilobytes (KB).
El uso de memoria puede aumentar más de lo esperado si la aplicación experimenta pérdidas de memoria. En un escenario de pérdida de memoria, las aplicaciones no pueden liberar páginas de memoria que ya no se usen.
Este es otro comando que se usa para ver los procesos de consumo de memoria superior:
ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
En el texto siguiente se muestra la salida de ejemplo del comando:
ps -eo pid,comm,user,args,%cpu,%mem --sort=-%mem | head
PID COMMAND USER COMMAND %CPU %MEM
45922 tail root tail -f /dev/zero 82.7 61.6
[...]
Puede identificar la presión de memoria a partir de eventos de finalización por falta de memoria (OOM) Kill, como se muestra en la siguiente salida de ejemplo:
Jun 19 22:42:14 rhel78 kernel: Out of memory: Kill process 45465 (tail) score 902 or sacrifice child
Jun 19 22:42:14 rhel78 kernel: Killed process 45465 (tail), UID 0, total-vm:7582132kB, anon-rss:7420324kB, file-rss:0kB, shmem-rss:0kB
El sistema invoca el estado de falta de memoria (OOM) después de que se consume tanto la RAM (memoria física) como el SWAP (disco).
Nota:
Use el pidstat -r comando para ver las estadísticas de memoria por proceso.
Importante
El uso elevado de memoria es normal en Linux. La presión de memoria se indica mediante poca memoria disponible, actividad de intercambio o eventos OOMkilled, no mediante el uso de la memoria caché.
Determinar si existe una restricción de recursos
Puede identificar las restricciones de recursos mediante la correlación de indicadores con la configuración actual.
Este es un ejemplo de una restricción de disco:
Una máquina virtual D2s_v3 es capaz de un ancho de banda sin caché de 48 MB/s. En esta máquina virtual, se conecta un disco P30 que es capaz de 200 MB/s. La aplicación requiere un mínimo de 100 MB/s.
En este ejemplo, el recurso de limitación es el rendimiento de la máquina virtual general. El requisito de la aplicación frente a lo que puede proporcionar la configuración de disco o máquina virtual indica el recurso de restricción.
Si la aplicación requiere <measurement1><recurso> y la configuración actual para <el recurso> es capaz de entregar solo <measurement2>, este requisito podría ser un factor de restricción.
Definición del recurso de limitación
Después de identificar un cuello de botella de recursos en la configuración actual, evalúe los posibles cambios y evalúe el impacto en la carga de trabajo. En algunos casos, el cuello de botella existe como una opción de optimización de costos y la aplicación sigue funcionando dentro de los límites de rendimiento aceptables.
Por ejemplo, cuando una aplicación requiere 128 GB (medida) de RAM (recurso), pero la configuración actual solo proporciona 64 GB (recurso), la memoria se convierte en un cuello de botella para la carga de trabajo.
Después de identificar el recurso de cuello de botella, defina la restricción y realice las acciones adecuadas. Este enfoque se aplica a todos los recursos.
Algunos cuellos de botella resultan de configuraciones de ahorro de costos y son aceptables cuando la aplicación puede tolerarlos. Cuando la aplicación no puede tolerar los recursos reducidos, la configuración se vuelve problemática.
Realizar cambios en función de los datos obtenidos
El diseño para el rendimiento no se trata de resolver problemas, sino de comprender dónde puede producirse el siguiente cuello de botella y cómo solucionarlo. Los cuellos de botella siempre existen y solo se pueden mover a una ubicación diferente en el diseño.
Por ejemplo, si el rendimiento del disco limita la aplicación, puede aumentar el tamaño del disco para permitir más rendimiento. Sin embargo, la red se convierte en el siguiente cuello de botella. Dado que los recursos están limitados, no hay ninguna configuración ideal y debe solucionar problemas con regularidad.
Después de recopilar datos de los pasos anteriores, ajuste el sistema en función de los datos reales y medibles. Compare estos cambios con la línea base establecida anteriormente para comprobar una mejora medible.
Considere el ejemplo siguiente:
Una línea base mostró un uso de CPU del 100 % en un sistema de dos CPU con un promedio de carga de 4, lo que indica la puesta en cola de solicitudes. Después de redimensionar a ocho CPU, la misma tarea redujo el uso de la CPU al 25 por ciento y bajó el promedio de carga a 2.
En este ejemplo, verá una diferencia medible al comparar los resultados obtenidos con los recursos modificados. Antes del cambio, había una restricción de recursos clara. Pero después del cambio, hay suficientes recursos para aumentar la carga.
Migración desde el entorno local a la nube
Varias diferencias de rendimiento pueden afectar a las migraciones de una configuración local a la informática en la nube.
Unidad Central de Procesamiento (CPU)
En función de la arquitectura, una configuración local podría ejecutar CPU que tengan velocidades de reloj más altas y cachés más grandes. El resultado es la reducción de los tiempos de procesamiento y un aumento en las instrucciones por ciclo (IPC). Es importante comprender las diferencias en los modelos y métricas de CPU al trabajar en migraciones. En este caso, es posible que una relación uno a uno entre los recuentos de CPU no sea suficiente.
Por ejemplo:
En un sistema local que tiene cuatro CPU que se ejecutan a 3,7 GHz, hay un total de 14,8 GHz disponibles para su procesamiento. Si crea el equivalente en recuento de CPU mediante una máquina virtual de D4s_v3 respaldada por CPU de 2,1 GHz, la máquina virtual migrada tiene 8,1 GHz disponible para su procesamiento. Esto representa una disminución del 44 por ciento en el rendimiento.
Disco
El rendimiento del disco en Azure depende del tipo y el tamaño del disco, excepto el disco Ultra, que ofrece flexibilidad en tamaño, IOPS y rendimiento. El tamaño del disco establece los límites de IOPS y rendimiento.
La latencia depende del tipo de disco en lugar del tamaño del disco. La mayoría de las soluciones de almacenamiento locales usan matrices de discos con cachés DRAM. Este tipo de caché ofrece latencia de submilisegundos (aproximadamente 200 microsegundos) y un alto rendimiento de lectura y escritura (IOPS).
Las latencias medias de Azure se muestran en la tabla siguiente.
| Tipo de disco | Latencia |
|---|---|
| Disco Ultra/Unidad de Estado Sólido Premium v2 | μs de tres dígitos (microsegundos) |
| SSD Premium/SSD estándar | Ms de un solo dígito (milisegundos) |
| HDD estándar | Ms de dos dígitos (milisegundos) |
Nota:
Un disco se ve limitado si alcanza sus límites de IOPS o ancho de banda. De lo contrario, la latencia puede aumentar a 100 milisegundos o más.
La diferencia de latencia entre una configuración local (a menudo menor que un milisegundo) y SSD Premium (milisegundos de un solo dígito) puede ser un factor de limitación. Tenga en cuenta las diferencias de latencia entre las ofertas de almacenamiento y seleccione la oferta que mejor se adapte a los requisitos de la aplicación.
Red
La mayoría de las configuraciones de red locales usan vínculos de 10 Gbps. En Azure, el tamaño de las máquinas virtuales determina directamente el ancho de banda de red. Algunos anchos de banda de red pueden superar los 40 Gbps. Asegúrese de seleccionar un tamaño que proporcione suficiente ancho de banda para las necesidades de la aplicación. En la mayoría de los casos, los límites de rendimiento de la máquina virtual o el disco, en lugar de la red, son el factor de limitación.
Memoria
Seleccione un tamaño de máquina virtual que tenga suficiente RAM para lo que está configurado actualmente.
Diagnósticos de rendimiento (PerfInsights)
El soporte técnico de Azure recomienda PerfInsights para problemas de rendimiento de máquinas virtuales. Proporciona procedimientos recomendados y pestañas de análisis dedicadas para CPU, memoria y E/S. Puede ejecutarlo a petición a través de Azure Portal o desde la máquina virtual y, a continuación, compartir los datos con el equipo de soporte técnico de Azure.
Ejecutar el PerfInsights
PerfInsights está disponible para el sistema operativo Linux . Compruebe que la distribución de Linux está en la lista de distribuciones admitidas para Diagnósticos de rendimiento para Linux.
Ejecución y análisis de informes a través de Azure Portal
Al instalar PerfInsights a través de Azure Portal, el software instala una extensión en la máquina virtual. También puede instalar PerfInsights como una extensión si va directamente a Extensiones y, a continuación, selecciona una opción de diagnóstico de rendimiento.
Opción 1 de Azure Portal
Vaya a la hoja de máquina virtual y seleccione Diagnósticos de rendimiento. A continuación, instálelo en la máquina virtual de destino (usa extensiones).
Opción 2 de Azure Portal
Vaya a la pestaña Diagnosticar y solucionar problemas en la hoja de la máquina virtual y busque el vínculo Solucionar problemas en Problemas de rendimiento de la máquina virtual.
Qué buscar en el informe de PerfInsights
Después de ejecutar el informe perfInsights, la ubicación del contenido depende de si ejecuta el informe a través de Azure Portal o como ejecutable. Para cualquiera de las dos opciones, puede acceder a la carpeta de registro generada o (si está en Azure Portal) descargar localmente para su análisis.
Ejecutar desde el portal de Azure
Abra el informe PerfInsights. La pestaña Resultados registra cualquier valor atípico en términos de consumo de recursos. Si hay instancias de rendimiento lento debido al uso específico de recursos, la pestaña Resultados clasifica cada búsqueda como Impacto alto o Medio .
Por ejemplo, en el siguiente informe, verá que la herramienta detectó resultados de impacto medio relacionados con el almacenamiento y verá las recomendaciones correspondientes. Si expande el evento Hallazgos, verá varios detalles clave.
Para más información sobre PerfInsights en el sistema operativo Linux, consulte Uso de PerfInsights Linux en Microsoft Azure.