Solución de problemas de rendimiento y aislamiento de cuellos de botella en Linux
Se aplica a: ✔️ Máquinas virtuales Linux
Problemas de rendimiento y cuellos de botella
Cuando se producen problemas de rendimiento en diferentes sistemas operativos y aplicaciones, cada caso requiere un enfoque único para solucionar problemas. La CPU, la memoria, las redes y la entrada/salida (E/S) son áreas clave en las que pueden producirse problemas. Cada una de estas áreas muestra síntomas diferentes (a veces simultáneamente) y requiere diagnósticos y soluciones diferentes.
Los problemas de rendimiento pueden deberse a una configuración incorrecta de la aplicación o la configuración. Un ejemplo sería una aplicación web que tiene una capa de almacenamiento en caché que no está configurada correctamente. Esta situación desencadena más solicitudes que vuelven al servidor de origen en lugar de ser atendidas desde una memoria caché.
En otro ejemplo, el registro de puesta al día de una base de datos MySQL o MariaDB se encuentra en el disco del sistema operativo (SO) o en un disco que no cumple los requisitos de la base de datos. En este escenario, es posible que vea menos transacciones por segundo (TPS) debido a la competencia de recursos y tiempos de respuesta mayores (latencia).
Si comprende completamente el problema, puede identificar mejor dónde buscar en la pila (CPU, memoria, redes, E/S). Para solucionar problemas de rendimiento, debe establecer una línea base que le permita comparar las métricas después de realizar cambios y evaluar si el rendimiento general ha mejorado.
La solución de problemas de rendimiento de una máquina virtual (VM) no es diferente de resolver un problema de rendimiento en un sistema físico. Se trata de determinar qué recurso o componente está causando un cuello de botella en el sistema.
Es importante comprender que siempre existen cuellos de botella. La solución de problemas de rendimiento consiste en comprender dónde se produce un cuello de botella y cómo moverlo a un recurso menos ofendido.
Esta guía le ayuda a detectar y resolver problemas de rendimiento en Azure Virtual Machines en el entorno linux.
Obtención de punteros de rendimiento
Puede obtener punteros de rendimiento que confirmen o denieguen si existe la restricción de recursos.
Dependiendo del recurso que se investigue, muchas herramientas pueden ayudarle a obtener datos que pertenecen a ese recurso. En la tabla siguiente se incluyen ejemplos de los recursos principales.
| Resource | Herramienta |
|---|---|
| CPU | top, htop, mpstat, , pidstat, vmstat |
| Disco | iostat, , iotop, vmstat |
| Red | ip, , vnstat, iperf3 |
| Memoria | free, , top, vmstat |
En las secciones siguientes se describen punteros y herramientas que puede usar para buscar los recursos principales.
Recurso de CPU
Se usa o no un determinado porcentaje de CPU. De forma similar, los procesos pasan tiempo en la CPU (como el uso del 80 por ciento usr ) o no (por ejemplo, el 80 por ciento de inactividad). La herramienta principal para confirmar que 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:
[root@rhel78 ~]$ 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 de dd proceso 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 indica 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 se carga tan cargado que los procesos comienzan a poner 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.
Recurso de disco (E/S)
Al investigar los problemas de rendimiento de E/S, los siguientes términos le ayudarán a comprender dónde se produce el problema.
| Término | Descripción |
|---|---|
| Tamaño de E/S | Cantidad de datos procesados por transacción, que normalmente se definen 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 de respaldo. |
| Tamaño del sector | Tamaño de cada uno de los sectores del disco. Este valor suele ser de 512 bytes. |
| E/S | Operaciones de salida de entrada 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 que superan una cantidad de tiempo específica. Este valor se define normalmente como megabytes por segundo (MB/s). |
E/S
Las operaciones de salida de entrada por segundo (IOPS) son una función del número de operaciones de entrada y salida (E/S) que se miden durante un tiempo determinado (en este caso, segundos). Las operaciones de E/S pueden ser lecturas o escrituras. Las eliminaciones o descartes también se pueden contar como una operación en el sistema de almacenamiento. Cada operación tiene una unidad de asignación que corresponde igualmente al tamaño de E/S.
Normalmente, el tamaño de E/S se define en el nivel de aplicación como la cantidad de datos escritos o leídos por transacción. Un tamaño de E/S usado habitualmente es 4K. Sin embargo, un tamaño de E/S más pequeño que contiene más subprocesos produce un valor de IOPS mayor. Dado que cada transacción se puede completar relativamente rápido (debido a su tamaño pequeño), una E/S más pequeña permite que se completen más transacciones en la misma cantidad de tiempo.
Por el contrario, supongamos que tiene el mismo número de subprocesos, pero usa una 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, para cada segundo, finalizan mil operaciones. 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.
Al conocer 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)
Se podría escribir una versión más fácil de ecuaciones de la siguiente manera:
IOPS * IOSize = IOSize/s (Throughput)
Capacidad de proceso
A diferencia de IOPS, el rendimiento es una función de la cantidad de datos a lo largo del tiempo. Esto significa que, durante cada segundo, se escribe o lee una determinada cantidad de datos. Esta velocidad se mide en <tiempo> de cantidad de datos>/<o megabytes por segundo (MB/s).
Si conoce los valores de rendimiento e IOSize, puede calcular IOPS dividiendo el rendimiento por IOSize. Debe normalizar las unidades a la menor subred. Por ejemplo, si IOSize se define en kilobytes (kb), se debe convertir el rendimiento.
El formato de ecuación se escribe de la siguiente manera:
Throughput / IOSize = IOPS
Para poner esta ecuación en contexto, considere el rendimiento de 10 MB/s en un tamaño de E/S 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 iostat en un comando sencillo. La sintaxis básica es la siguiente:
iostat <parameters> <time-to-refresh-in-seconds> <number-of-iterations> <block-devices>
Los parámetros dictan qué información iostat proporciona. Sin tener ningún parámetro de comando, iostat muestra los detalles básicos:
[host@rhel76 ~]$ 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 se proporcionan datos mínimos para cada dispositivo. Hay parámetros disponibles que ayudan a identificar problemas al proporcionar datos extendidos (como rendimiento, IOPS, tamaño de cola y latencia).
Ejecute iostat especificando desencadenadores:
sudo iostat -dxctm 1
Para expandir aún más los iostat resultados, use los parámetros siguientes.
| Parámetro | Action |
|---|---|
-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:
[host@rhel76 ~]$ 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. Los datos de iostat siempre deben capturarse y analizarse para 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.
Recurso de red
Las redes pueden experimentar dos cuellos de botella principales: ancho de banda bajo y latencia alta.
Puede usar vnstat 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
La latencia de red en dos sistemas diferentes se puede determinar mediante un comando sencillo ping en el Protocolo de mensajes de control de Internet (ICMP):
[root@rhel78 ~]# 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
Puede comprobar el ancho de banda de red mediante herramientas como iperf3. La iperf3 herramienta funciona en el modelo de servidor o cliente en el que se inicia la aplicación especificando la -s marca en el 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
root@ubnt:~# iperf3 -s ----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------Client
root@ubnt2:~# 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 |
Invierte el tráfico. De forma predeterminada, el cliente envía datos al servidor. |
--bidir |
Prueba tanto la carga como la descarga. |
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:
[root@rhel78 ~]# 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 se está ejecutando bajo), el kernel devuelve la memoria que se usa para la memoria 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 ejecutar .top En el texto siguiente se muestra la salida del top comando:
[root@rhel78 ~]# 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 la memoria residente. Esto 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:
[root@rhel78 ~]# 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 de eventos de eliminación de memoria insuficiente (OOM), 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
OOM se invoca después de que se consuman tanto LA RAM (memoria física) como SWAP (disco).
Nota
Puede usar el pidstat -r comando para ver las estadísticas de memoria por proceso.
Determinar si existe una restricción de recursos
Puede determinar si existe una restricción mediante los indicadores anteriores y conocer la configuración actual. La restricción se puede comparar con la configuración existente.
Este es un ejemplo de una restricción de disco:
Una máquina virtual de D2s_v3 es capaz de 48 MB/s de rendimiento sin almacenar en caché. 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 <un recurso> measurement1<>y la configuración actual del <recurso> es capaz de entregar solo <measurement2>, este requisito podría ser un factor de limitación.
Definición del recurso de limitación
Después de determinar que un recurso es el factor de limitación de la configuración actual, identifique cómo se puede cambiar y cómo afecta a la carga de trabajo. Hay situaciones en las que la limitación de recursos podría existir debido a una medida de ahorro de costos, pero la aplicación sigue siendo capaz de controlar el cuello de botella sin problemas.
Por ejemplo:
Si la aplicación requiere 128 GB (medida) de RAM (recurso) y la configuración actual de RAM (recurso) es capaz de entregar solo 64 GB (medida), este requisito podría ser un factor de limitación.
Ahora, puede definir el recurso de limitación y realizar acciones basadas en ese recurso. El mismo concepto se aplica a otros recursos.
Si se esperan estos recursos de limitación como medida de ahorro de costos, la aplicación debe solucionar los cuellos de botella. Sin embargo, si existen las mismas medidas de ahorro de costos y la aplicación no puede controlar fácilmente la falta de recursos, esta configuración podría causar problemas.
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 del diseño.
Por ejemplo, si la aplicación está limitada por el rendimiento del disco, 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.
Al obtener datos en los pasos anteriores, ahora puede realizar cambios en función de los datos reales y medibles. También puede comparar estos cambios con la línea base que ha medido previamente para comprobar que hay una diferencia tangible.
Considere el ejemplo siguiente:
Cuando obtuvo una línea base mientras se estaba ejecutando la aplicación, determinó que el sistema tenía una constante del 100 % de uso de CPU en una configuración de dos CPU. Ha observado un promedio de carga de 4. Esto significaba que el sistema estaba en cola las solicitudes. Un cambio en un sistema de 8 CPU redujo el uso de CPU al 25 por ciento y la media de carga se redujo a 2 cuando se aplicó la misma carga.
En este ejemplo, hay 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
Las migraciones de una configuración local a la informática en la nube pueden verse afectadas por varias diferencias de rendimiento.
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 se reduciría los tiempos de procesamiento y 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 se crea el equivalente en el 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 se define mediante el tipo y el tamaño del disco (excepto el disco Ultra, que proporciona flexibilidad con respecto al tamaño, las IOPS y el rendimiento). El tamaño del disco define los límites de IOPS y rendimiento.
La latencia es una métrica que depende del tipo de disco en lugar del tamaño del disco. La mayoría de las soluciones de almacenamiento locales son matrices de discos que tienen cachés drAM. Este tipo de caché proporciona 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/SSD 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
Se limita un disco si alcanza sus límites de IOPS o ancho de banda, ya que, de lo contrario, la latencia puede aumentar a 100 milisegundos o más.
La diferencia de latencia entre un entorno local (a menudo menor que un milisegundo) y ssd Premium (milisegundos de un solo dígito) se convierte en 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 ancho de banda de red se define directamente mediante el tamaño de las máquinas virtuales (VM). Algunos anchos de banda de red pueden superar los 40 Gbps. Asegúrese de seleccionar un tamaño que tenga suficiente ancho de banda para las necesidades de la aplicación. En la mayoría de los casos, el factor de limitación es los límites de rendimiento de la máquina virtual o el disco en lugar de la red.
Memoria
Seleccione un tamaño de máquina virtual que tenga suficiente RAM para lo que está configurado actualmente.
Diagnósticos de rendimiento (PerfInsights)
PerfInsights es la herramienta recomendada por el soporte técnico de Azure para problemas de rendimiento de las máquinas virtuales. Está diseñado para cubrir los procedimientos recomendados y las pestañas de análisis dedicados para cpu, memoria y E/S. Puede ejecutarlo 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.
Ejecución de PerfInsights
PerfInsights está disponible para los sistemas operativos Windows y 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
Cuando PerfInsights se instala a través de Azure Portal, el software instala una extensión en la máquina virtual. Los usuarios también pueden instalar PerfInsights como una extensión; para ello, vaya directamente a la hoja Extensiones de la máquina virtual y, a continuación, seleccione una opción de diagnóstico de rendimiento.
Opción 1 de Azure Portal
Examine la hoja de máquina virtual y seleccione la opción Diagnóstico de rendimiento. Se le pedirá que instale la opción (usa extensiones) en la máquina virtual para la que seleccionó.
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 el informe se ejecutó a través de Azure Portal o como ejecutable. Para cualquiera de las opciones, acceda a la carpeta de registro generada o (si está en Azure Portal) descargue localmente para su análisis.
Ejecución mediante Azure Portal
Abra el informe de PerfInsights. En la pestaña Resultados se registran los valores atípicos 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, vemos que se detectaron hallazgos de impacto medio relacionados con Storage y vemos las recomendaciones correspondientes. Si expande el evento Resultados , verá varios detalles clave.
Para más información sobre PerfInsights en el sistema operativo Linux, consulte Uso de PerfInsights Linux en Microsoft Azure.
Más información
Ponte en contacto con nosotros para obtener ayuda
Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.