La guía panorámica para la optimización del rendimiento de Linux se encuentra en este artículo, se recomienda recopilarla ~

Optimización del rendimiento de Linux

Optimización del rendimiento

Actuación

La alta concurrencia y la respuesta rápida corresponden a los dos indicadores centrales de optimización del rendimiento: rendimiento y latencia.

imagen

Perspectiva de carga de aplicaciones: afecta directamente la experiencia del usuario del terminal del producto
Perspectiva de los recursos del sistema: uso de recursos, saturación, etc.

La esencia del problema de rendimiento es que los recursos del sistema han alcanzado el cuello de botella, pero el procesamiento de solicitudes no es lo suficientemente rápido para admitir más solicitudes. El análisis de rendimiento consiste en realidad en encontrar los cuellos de botella de la aplicación o sistema y tratar de evitarlos o aliviarlos.

Seleccionar métricas para evaluar el rendimiento de las aplicaciones y del sistema
Establecer objetivos de rendimiento para aplicaciones y sistemas.
Realizar evaluaciones comparativas de desempeño
Análisis de rendimiento para localizar cuellos de botella
Monitoreo y alertas del desempeño

Se deben seleccionar diferentes herramientas de análisis de desempeño para diferentes problemas de desempeño. Las siguientes son herramientas de rendimiento de Linux de uso común y se analizan los tipos correspondientes de problemas de rendimiento.

imagen

¿Cómo debemos entender el "promedio de carga"?

Carga promedio : el número promedio de procesos en los estados ejecutable e ininterrumpible del sistema por unidad de tiempo, es decir, el número promedio de procesos activos. No está directamente relacionado con el uso de la CPU como lo entendemos tradicionalmente.

El proceso ininterrumpible es un proceso que se encuentra en un proceso crítico en el estado del núcleo (como una respuesta de E/S común esperando un dispositivo). El estado ininterrumpible es en realidad un mecanismo de protección del sistema para procesos y dispositivos de hardware.

¿Cuál es el promedio de carga razonable?

En el entorno de producción real, se monitorea la carga promedio del sistema y la tendencia de cambio de carga se juzga en función de datos históricos. Cuando haya una tendencia ascendente evidente en la carga, realice análisis e investigaciones oportunos. Por supuesto, también puede establecer un umbral (por ejemplo, cuando la carga promedio es superior al 70% del número de CPU)

En el trabajo real, a menudo confundimos los conceptos de carga promedio y uso de CPU, de hecho, los dos no son completamente equivalentes:

Procesos que consumen mucha CPU y el uso intensivo de la CPU hará que la carga promedio aumente, y los dos son consistentes en este momento
Para procesos con uso intensivo de E/S, esperar E/S también hará que la carga promedio aumente. En este momento, el uso de la CPU no es necesariamente alto.
Una gran cantidad de procesos que esperan la programación de la CPU harán que la carga promedio aumente y el uso de la CPU también será relativamente alto.

Los promedios de carga elevados pueden ser el resultado de procesos que requieren un uso intensivo de la CPU o de E/S intensas. Para un análisis específico, puede combinar la herramienta mpstat/pidstat para ayudar a analizar el origen de la carga.

UPC

Cambio de contexto de CPU (Parte 1)

El cambio de contexto de la CPU consiste en guardar el contexto de la CPU (registros de la CPU y PC) de la tarea anterior, luego cargar el contexto de la nueva tarea en estos registros y contador del programa, y finalmente saltar a la ubicación señalada por el contador del programa para ejecutar el nuevo. tarea. Entre ellos, el contexto guardado se almacenará en el kernel del sistema y se cargará nuevamente cuando la tarea se reprograme para su ejecución para garantizar que el estado original de la tarea no se vea afectado.

Según el tipo de tarea, el cambio de contexto de la CPU se divide en:

Cambio de contexto de proceso
Cambio de contexto de hilo
interrumpir el cambio de contexto

Cambio de contexto de proceso

El proceso de Linux divide el espacio de ejecución del proceso en espacio del kernel y espacio del usuario según el nivel de autoridad. La transición del modo de usuario al modo kernel debe realizarse mediante llamadas al sistema.

Un proceso de llamada al sistema en realidad realiza dos cambios de contexto de CPU:

Primero se guarda la ubicación de las instrucciones en modo de usuario en el registro de la CPU, el registro de la CPU se actualiza a la ubicación de las instrucciones en modo kernel y salta al estado del kernel para ejecutar la tarea del kernel;
Una vez completada la llamada al sistema, los registros de la CPU restauran los datos del estado del usuario guardados originalmente y luego cambian al espacio del usuario para continuar ejecutando.

Durante el proceso de llamada al sistema, los recursos del modo de usuario del proceso, como la memoria virtual, no estarán involucrados y los procesos no se cambiarán. Es diferente del cambio de contexto de proceso en el sentido tradicional. Por lo tanto, las llamadas al sistema a menudo se denominan conmutadores de modo privilegiado.

Los procesos son administrados y programados por el kernel, y el cambio de contexto del proceso solo puede ocurrir en modo kernel. Por lo tanto, en comparación con las llamadas al sistema, antes de guardar el estado del kernel y los registros de la CPU del proceso actual, primero se deben guardar la memoria virtual y la pila del proceso. Después de cargar el estado del kernel del nuevo proceso, se deben actualizar la memoria virtual y la pila de usuarios del proceso.

El proceso solo necesita cambiar de contexto cuando está programado para ejecutarse en la CPU. Existen los siguientes escenarios: los intervalos de tiempo de la CPU se asignan a su vez, los recursos insuficientes del sistema hacen que el proceso se bloquee, el proceso se bloquea activamente a través de la función de suspensión y Los procesos de alta prioridad se adelantan al intervalo de tiempo. Cuando se produce una interrupción de hardware, el proceso en la CPU se suspende y en su lugar ejecuta el servicio de interrupción en el kernel.

Cambio de contexto de hilo

Hay dos tipos de cambio de contexto de hilo:

Los subprocesos delantero y trasero pertenecen al mismo proceso y el recurso de memoria virtual permanece sin cambios al cambiar, solo es necesario cambiar los datos privados, registros, etc. del subproceso;
Los subprocesos delantero y trasero pertenecen a procesos diferentes, lo que es lo mismo que el cambio de contexto del proceso.

El cambio de subprocesos en el mismo proceso consume menos recursos, lo que también es una ventaja de los subprocesos múltiples.

interrumpir el cambio de contexto

El cambio de contexto de interrupción no involucra el estado de usuario del proceso, por lo que el contexto de interrupción solo incluye el estado necesario para la ejecución del programa de servicio de interrupción del estado del kernel (registros de CPU, pila del kernel, parámetros de interrupción de hardware, etc.).

La prioridad del procesamiento de interrupciones es mayor que la del proceso, por lo que el cambio de contexto de interrupción y el cambio de contexto de proceso no ocurrirán al mismo tiempo.

Cambio de contexto de CPU (Parte 2)

Puede ver la situación general de cambio de contexto del sistema a través de vmstat

vmstat 5         #每隔5s输出一组数据procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 1  0      0 103388 145412 511056    0    0    18    60    1    1  2  1 96  0  0 0  0      0 103388 145412 511076    0    0     0     2  450 1176  1  1 99  0  0 0  0      0 103388 145412 511076    0    0     0     8  429 1135  1  1 98  0  0 0  0      0 103388 145412 511076    0    0     0     0  431 1132  1  1 98  0  0 0  0      0 103388 145412 511076    0    0     0    10  467 1195  1  1 98  0  0 1  0      0 103388 145412 511076    0    0     0     2  426 1139  1  0 99  0  0 4  0      0  95184 145412 511108    0    0     0    74  500 1228  4  1 94  0  0 0  0      0 103512 145416 511076    0    0     0   455  723 1573 12  3 83  2  0

cs (cambio de contexto) número de cambios de contexto por segundo
in (interrupción) Número de interrupciones por segundo
r (en ejecución o ejecutable) la longitud de la cola lista, la cantidad de procesos en ejecución y esperando por la CPU
b (Bloqueado) Número de procesos en estado de suspensión ininterrumpida

Para ver los detalles de cada proceso, debe usar pidstat para ver el cambio de contexto de cada proceso.

pidstat -w 514时51分16秒   UID       PID   cswch/s nvcswch/s  Command14时51分21秒     0         1      0.80      0.00  systemd14时51分21秒     0         6      1.40      0.00  ksoftirqd/014时51分21秒     0         9     32.67      0.00  rcu_sched14时51分21秒     0        11      0.40      0.00  watchdog/014时51分21秒     0        32      0.20      0.00  khugepaged14时51分21秒     0       271      0.20      0.00  jbd2/vda1-814时51分21秒     0      1332      0.20      0.00  argusagent14时51分21秒     0      5265     10.02      0.00  AliSecGuard14时51分21秒     0      7439      7.82      0.00  kworker/0:214时51分21秒     0      7906      0.20      0.00  pidstat14时51分21秒     0      8346      0.20      0.00  sshd14时51分21秒     0     20654      9.82      0.00  AliYunDun14时51分21秒     0     25766      0.20      0.00  kworker/u2:114时51分21秒     0     28603      1.00      0.00  python3

cswch Número de cambios de contexto voluntarios por segundo (cambios de contexto causados por el proceso que no puede obtener los recursos necesarios)
nvcswch Número de cambios de contexto involuntarios por segundo (programación forzada por el sistema, como rotación de intervalos de tiempo)

vmstat 1 1    #新终端观察上下文切换情况此时发现cs数据明显升高，同时观察其他指标：r列：远超系统CPU个数，说明存在大量CPU竞争us和sy列：sy列占比80%，说明CPU主要被内核占用in列：中断次数明显上升，说明中断处理也是潜在问题

Significa que hay demasiados procesos ejecutándose/esperando la CPU, lo que resulta en una gran cantidad de cambios de contexto, lo que conduce a un alto uso de la CPU del sistema.

pidstat -w -u 1  #查看到底哪个进程导致的问题

Se puede ver en los resultados que sysbench provoca un uso excesivo de la CPU, pero la cantidad total de contextos generados por pidstat no es alta. El análisis de sysbench simula el cambio de subprocesos, por lo que debe agregar el parámetro -t después de pidstat para ver los indicadores de subprocesos.

Además, si hay demasiadas interrupciones, podemos leerlas a través del archivo /proc/interrupts.

watch -d cat /proc/interrupts

Se descubre que el cambio más rápido en el número de veces es la interrupción de reprogramación (RES), que se utiliza para reactivar la CPU en el estado inactivo para programar la ejecución de una nueva tarea. El análisis todavía se debe al problema de programación de demasiadas tareas, lo cual es consistente con el análisis de cambio de contexto.

¿Qué debo hacer si el uso de CPU de una aplicación llega al 100%?

Como sistema operativo multitarea, Linux divide el tiempo de la CPU en intervalos de tiempo cortos y los asigna a cada tarea por turno a través del programador. Para mantener el tiempo de la CPU, Linux activa interrupciones de tiempo a través de frecuencias de latidos predefinidas y utiliza santiamén globales para registrar el número de latidos desde el inicio. Este valor es +1 una vez que ocurre una interrupción.

Uso de CPU, el porcentaje del tiempo total de CPU distinto del tiempo de inactividad. El uso de CPU se puede calcular a partir de los datos en /proc/stat. Porque el valor acumulado del número de latidos desde el inicio en /proc/stat se calcula como el uso promedio de la CPU desde el inicio, lo cual generalmente tiene poca importancia. Puedes calcular el uso promedio de CPU durante ese período tomando la diferencia entre dos valores tomados a intervalos de un período de tiempo. Las herramientas de análisis de rendimiento dan el uso promedio de la CPU durante un período de tiempo. Preste atención a la configuración del intervalo.

El uso de la CPU se puede ver a través de top o ps. Puede analizar los problemas de CPU del proceso a través de perf, que se basa en el muestreo de eventos de rendimiento. No solo puede analizar varios eventos del sistema y el rendimiento del kernel, sino que también puede usarse para analizar los problemas de rendimiento de aplicaciones específicas.

perf top / perf record / perf report (-g activa el muestreo de relaciones de llamadas)

sudo docker run --name nginx -p 10000:80 -itd feisky/nginxsudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm
ab -c 10 -n 100 http://XXX.XXX.XXX.XXX:10000/ #测试Nginx服务性能

Se descubre que en este momento se puede tolerar la cantidad de solicitudes por segundo y la cantidad de solicitudes de prueba aumenta de 100 a 10,000. Ejecute top en otra terminal para ver el uso de cada CPU. Se descubrió que varios procesos php-fpm en el sistema provocaron un aumento repentino en el uso de la CPU.

Luego use perf para analizar qué función en php-fpm causa el problema.

perf top -g -p XXXX #对某一个php-fpm进程进行分析

Se descubrió que sqrt y add_function ocupaban demasiada CPU. En este momento, verifiqué el código fuente y descubrí que el segmento del código de prueba no se eliminó en sqrt antes del lanzamiento, lo que provocó un bucle de un millón de veces. Después de eliminar el código inútil, se descubrió que la capacidad de carga de nginx mejoró significativamente.

El uso de CPU del sistema es elevado, ¿por qué no puedo encontrar aplicaciones con un uso elevado de CPU?

sudo docker run --name nginx -p 10000:80 -itd feisky/nginx:spsudo docker run --name phpfpm -itd --network container:nginx feisky/php-fpm:spab -c 100 -n 1000 http://XXX.XXX.XXX.XXX:10000/ #并发100个请求测试

En los resultados experimentales, el número de solicitudes por segundo aún no es alto. Después de reducir el número de solicitudes simultáneas a 5, la capacidad de carga de nginx sigue siendo muy baja.

En este momento, se utilizaron top y pidstat para encontrar que el uso de la CPU del sistema era demasiado alto, pero no se encontraron procesos con un uso elevado de la CPU.

Esta situación generalmente ocurre cuando perdemos alguna información durante el análisis, vuelva a ejecutar el comando superior y observe por un momento. Se descubrió que había demasiados procesos en estado de ejecución en la cola lista, excediendo nuestro número de solicitudes simultáneas en 5. Después de verificar cuidadosamente los datos del proceso en ejecución, descubrimos que tanto nginx como php-fpm estaban en estado de suspensión. pero había varios procesos de estrés que realmente se estaban ejecutando.

El siguiente paso es utilizar pidstat para analizar estos procesos de estrés y descubrir que no hay resultados. Utilice la validación cruzada de ps aux para descubrir que el proceso aún no existe. La explicación no es un problema con la herramienta. Verifique la parte superior y descubra que el número de proceso del proceso de estrés ha cambiado, lo que puede deberse a las dos razones siguientes:

El proceso sigue fallando y reiniciándose (como un error de configuración/segfault, etc.) En este momento, el sistema de monitoreo puede reiniciar el proceso después de salir;
Causado por procesos de corta duración, es decir, comandos externos llamados a través de exec dentro de otras aplicaciones. Estos comandos generalmente solo se ejecutan por un corto tiempo y finalizan. Es difícil encontrarlos con una herramienta de intervalo largo como top.

Puede utilizar pstree para encontrar el proceso principal de estrés y descubrir la relación de llamada.

pstree | grep stress

Se descubre que el subproceso es llamado por php-fpm. En este momento, si verifica el código fuente, puede ver que cada solicitud llamará a un comando de estrés para simular la presión de E / S. El resultado mostrado por arriba antes fue un aumento en el uso de la CPU. Si realmente es causado por el comando de estrés requiere un análisis más detallado. Después de agregar el parámetro detallado = 1 a cada solicitud en el código, puede ver el resultado del comando de estrés. Después de interrumpir la prueba, los resultados del comando muestran que hay un error en la falla de creación del archivo debido a problemas de permiso cuando el estrés El comando se está ejecutando.

En este momento, todavía es solo una suposición y el siguiente paso es continuar analizándolo a través de la herramienta de rendimiento. El informe de rendimiento muestra que el estrés consume mucha CPU cuando es cierto y se puede solucionar solucionando el problema de permisos para optimizarlo.

¿Qué debo hacer si hay una gran cantidad de procesos ininterrumpibles y procesos zombies en el sistema?

estado del proceso

R En ejecución/Ejecutable, que indica que el proceso está en la cola listo de la CPU, ejecutándose o esperando para ejecutarse;
D Disk Sleep, estado de suspensión ininterrumpible, que generalmente indica que el proceso está interactuando con el hardware y no se le permite interrumpirlo. por otros procesos durante la interacción;
Z Zombie, proceso zombie, lo que significa que el proceso realmente ha finalizado, pero el proceso padre no ha reclamado sus recursos;
S Interruptible Sleep, que puede interrumpir el estado de suspensión, significa que el proceso está suspendido por el sistema porque está esperando un evento. Cuando ocurre el evento de espera, se suspenderá. Se despierta y entra en el estado R;
I inactivo, estado inactivo, utilizado en subprocesos del kernel que no pueden interrumpir el sueño. Este estado no hará que la carga promedio aumente;
T Stop/Traced, indica que el proceso está suspendido o rastreado (SIGSTOP/SIGCONT, depuración de GDB);
X Dead, el proceso ha muerto y no se verá en top/ps.

En el caso de los estados ininterrumpibles, generalmente finalizan en muy poco tiempo y pueden ignorarse. Sin embargo, si el sistema o el hardware fallan, el proceso puede permanecer en un estado ininterrumpido durante mucho tiempo, o incluso aparecer una gran cantidad de estados ininterrumpibles en el sistema. En este momento, debe prestar atención a si el rendimiento de E / S ocurren problemas.

Los procesos zombies generalmente son fáciles de encontrar en aplicaciones multiproceso. Cuando el proceso padre no tiene tiempo para procesar el estado del proceso hijo, el proceso hijo sale temprano y en este momento el proceso hijo se convierte en un proceso zombie. Una gran cantidad de procesos zombies consumirán el número de proceso PID, lo que provocará que no se puedan establecer nuevos procesos.

Problema de disco O_DIRECT

sudo docker run --privileged --name=app -itd feisky/app:iowaitps aux | grep '/app'

Se puede ver que hay varios procesos de aplicación ejecutándose en este momento y los estados son Ss+ y D+ respectivamente. La última s indica que el proceso es el proceso líder de una sesión y el signo + indica el grupo de procesos de primer plano.

El grupo de procesos representa un grupo de procesos interrelacionados y el proceso hijo es miembro del grupo donde se encuentra el proceso padre. Una sesión se refiere a uno o más grupos de procesos que comparten el mismo terminal de control.

Utilice top para verificar los recursos del sistema y descubra que: 1) la carga promedio aumenta gradualmente y la carga promedio alcanza la cantidad de CPU en 1 minuto, lo que indica que el sistema puede tener un cuello de botella en el rendimiento; 2) hay muchos procesos zombies y están aumentando; 3) El uso de CPU de nosotros y sys no es alto, pero iowait es relativamente alto; 4) El uso de CPU de cada proceso no es alto, pero hay dos procesos en estado D, posiblemente esperando IO.

El análisis de los datos actuales muestra que: un iowait excesivo hace que la carga promedio del sistema aumente, y el crecimiento continuo de los procesos zombies indica que un programa no puede limpiar correctamente los recursos del proceso secundario.

Utilice dstat para analizar, porque puede ver el uso de CPU y recursos de E/S al mismo tiempo, lo cual es conveniente para análisis comparativos.

dstat 1 10    #间隔1秒输出10组数据

Se puede ver que cuando aumenta wai (iowait), la solicitud de lectura del disco será muy grande, lo que indica que el aumento en iowait está relacionado con la solicitud de lectura del disco. A continuación, analice qué proceso está leyendo el disco.

Para el número de proceso en estado D visto por Top antes, use pidstat -d -p XXX para mostrar las estadísticas de E/S del proceso. Se encuentra que el proceso en el estado D no tiene operaciones de lectura o escritura. Cuando usé pidstat -d para verificar las estadísticas de E/S de todos los procesos, vi que el proceso de la aplicación estaba realizando operaciones de lectura de disco, leyendo 32 MB de datos por segundo. El proceso debe utilizar llamadas al sistema para acceder al disco en el estado del kernel. El siguiente objetivo es encontrar las llamadas al sistema del proceso de la aplicación.

sudo strace -p XXX #对app进程调用进行跟踪

El mensaje de error es que no hay permiso porque ya tiene permisos de root. Entonces, cuando se encuentre con esta situación, primero debe verificar si el estado del proceso es normal. El comando ps encuentra que el proceso ya se encuentra en el estado Z, es decir, un proceso zombie.

En este caso, herramientas como top pidstat no pueden brindar más información. En este momento, como en el quinto artículo, use perf record -dy perf report para analizar y ver la pila de llamadas del proceso de la aplicación.

Se puede ver que la aplicación de hecho está leyendo datos a través de llamadas al sistema sys_read() , y realiza operaciones de lectura directa desde new_sync_ready blkdev_direct_IOve el proceso. La solicitud es leer directamente desde el disco, sin almacenamiento en caché, lo que hace que iowait aumente.

Después del análisis capa por capa, la causa principal es la E/S directa del disco dentro de la aplicación. Luego ubique la ubicación del código específico para la optimización.

proceso zombie

Después de la optimización anterior, iowait se ha reducido significativamente, pero la cantidad de procesos zombies sigue aumentando. Primero, ubique el proceso principal del proceso zombie y use pstree -aps XXX para imprimir el árbol de llamadas del proceso zombie y descubra que el proceso principal es el proceso de la aplicación.

Verifique el código de la aplicación para ver si el final del proceso secundario se maneja correctamente (si se llama a wait()/waitpid(), si hay una función de procesamiento de señal SIGCHILD registrada, etc.).

Cuando encuentre un aumento en iowait, primero use herramientas como dstat y pidstat para confirmar si hay un problema de E/S del disco y luego descubra qué procesos están causando la E/S. Si no puede usar strace para analizar directamente las llamadas a procesos , puedes utilizar la herramienta perf para analizarlo.

Para el problema zombie, use pstree para encontrar el proceso principal y luego mire el código fuente para verificar la lógica de procesamiento para el final del proceso secundario.

Indicadores de rendimiento de la CPU

uso de CPU
- Uso de CPU del usuario, incluido el modo de usuario (usuario) y el modo de usuario de baja prioridad (agradable). Si este indicador es demasiado alto, indica que la aplicación está ocupada.
- Uso de la CPU del sistema, el porcentaje de tiempo que la CPU se ejecuta en modo kernel (excluyendo interrupciones). Un indicador alto indica que el kernel está ocupado.
- Uso de CPU en espera de E/S, iowait.Un indicador alto indica que el tiempo de interacción de E/S entre el sistema y el dispositivo de hardware es relativamente largo.
- Uso de CPU de interrupción suave/dura. Un indicador alto indica que se produce una gran cantidad de interrupciones en el sistema.
- robar CPU/CPU invitada, indica el porcentaje de CPU ocupada por la máquina virtual.
promedio de carga
- Idealmente, la carga promedio es igual al número de CPU lógicas, lo que indica que cada CPU está totalmente utilizada. Si es mayor, la carga del sistema es mayor.
Cambio de contexto de proceso
- Incluyendo el cambio voluntario cuando no se pueden obtener recursos y el cambio involuntario cuando el sistema fuerza la programación. El cambio de contexto en sí mismo es una función central para garantizar el funcionamiento normal de Linux. El cambio excesivo consumirá el tiempo de CPU del proceso de ejecución original en el registro, y el El kernel ocupará memoria virtual y otros datos para guardar y recuperar.
Tasa de aciertos de la caché de la CPU
- Con respecto a la reutilización de la caché de la CPU, cuanto mayor sea la tasa de aciertos, mejor será el rendimiento. L1/L2 se usa comúnmente en un solo núcleo y L3 se usa en varios núcleos.

Herramientas de rendimiento

Caso promedio de carga
- Primero use el tiempo de actividad para verificar el promedio de carga del sistema
- Después de determinar que la carga ha aumentado, use mpstat y pidstat para ver el uso de CPU de cada CPU y cada proceso respectivamente. Descubra el proceso que causa la carga promedio más alta.
Caso de cambio de contexto
- Primero use vmstat para verificar la cantidad de interrupciones y cambios de contexto del sistema.
- Luego use pidstat para observar el cambio de contexto voluntario e involuntario del proceso.
- Finalmente, observe el cambio de contexto del hilo a través de pidstat.
Caso de uso elevado de CPU de proceso
- Primero use top para verificar el uso de CPU del sistema y el proceso, y ubique el proceso
- Luego use perf top para observar la cadena de llamadas del proceso y ubicar la función específica
Casos de uso elevado de CPU del sistema
- Primero use top para verificar el uso de CPU del sistema y el proceso. Top/pidstat no puede encontrar procesos con alto uso de CPU.
- Revisar el resultado principal
- Comience con procesos que tengan un uso bajo de CPU pero que estén en estado En ejecución.
- registro/informe de rendimiento encontrado proceso a corto plazo (herramienta execsnoop)
Casos de procesos ininterrumpidos y zombies
- Primero use top para observar el aumento de iowait y encontrar una gran cantidad de procesos ininterrumpibles y zombies.
- strace no puede rastrear las llamadas al sistema de procesos
- El análisis de rendimiento de la cadena de llamadas encontró que la causa raíz proviene de la E/S directa del disco.
Caso de interrupción suave
- La parte superior observa un alto uso de CPU de interrupción suave del sistema.
- Consulte /proc/softirqs para encontrar varios softirqs con velocidades de cambio rápido.
- El comando sar descubrió que se trataba de un problema de paquetes de red.
- tcpdump descubre el tipo y origen de las tramas de red y determina la causa del ataque SYN FLOOD

Encuentre la herramienta adecuada en función de diferentes indicadores de rendimiento:

imagen

Primero ejecute varias herramientas que admitan muchos indicadores, como top/vmstat/pidstat. Según su resultado, puede determinar qué tipo de problema de rendimiento es. Después de localizar el proceso, utilice strace/perf para analizar la situación de llamada para un análisis más detallado. Si es una interrupción suave, use /proc/softirqs

imagen

optimización de CPU

Optimización de aplicaciones
- Optimización del compilador: habilite las opciones de optimización durante la fase de compilación, como gcc -O2
- Optimización de algoritmos
- Procesamiento asincrónico: evite que el programa se bloquee esperando un determinado recurso y mejore las capacidades de procesamiento concurrente del programa. (Reemplace el sondeo con notificación de evento)
- Multihilo en lugar de multiprocesamiento: reducir los costos de cambio de contexto
- Haga un buen uso del caché: acelere el procesamiento del programa
Optimización del sistema
- Vinculación de CPU: vincule el proceso a una o varias CPU para mejorar la tasa de aciertos de la caché de la CPU y reducir el cambio de contexto causado por la programación de la CPU.
- Exclusivo de CPU: mecanismo de afinidad de CPU para asignar procesos
- Ajuste de prioridad: use nice para reducir adecuadamente la prioridad de las aplicaciones no principales
- Establecer visualización de recursos para procesos: cgroups establece límites de uso para evitar que una aplicación agote los recursos del sistema debido a sus propios problemas.
- Optimización NUMA: la CPU accede a la memoria local tanto como sea posible
- Equilibrio de carga de interrupciones: irpbalance, equilibra automáticamente la carga del proceso de procesamiento de interrupciones en cada CPU
La diferencia y la comprensión de TPS, QPS y el rendimiento del sistema
- QPS（TPS）
- Número de concurrencias
- Tiempo de respuesta
- QPS (TPS) = número de concurrencias/tiempo de respuesta promedio
- El usuario solicita el servidor
- Procesamiento interno del servidor
- El QPS devuelto por el servidor al cliente
  es similar al TPS, pero una visita a una página forma un TPS, pero una solicitud de página puede incluir múltiples solicitudes al servidor, que pueden contarse en múltiples QPS.
- QPS (Consultas por segundo) es la tasa de consultas por segundo, la cantidad de consultas a las que un servidor puede responder por segundo.
- TPS (Transacciones por segundo) número de transacciones por segundo, resultado de las pruebas de software.
El rendimiento del sistema incluye varios parámetros importantes:

Memoria

Cómo funciona la memoria de Linux

mapa de memoria

La memoria principal utilizada por la mayoría de las computadoras es la memoria dinámica de acceso aleatorio (DRAM), y solo el núcleo puede acceder directamente a la memoria física. El kernel de Linux proporciona a cada proceso un espacio de direcciones virtuales independiente, y este espacio de direcciones es continuo. De esta forma, el proceso puede acceder fácilmente a la memoria (memoria virtual).

El interior del espacio de direcciones virtuales se divide en dos partes: espacio del kernel y espacio del usuario. El rango del espacio de direcciones de procesadores con diferentes longitudes de palabras es diferente. El espacio del kernel del sistema de 32 bits ocupa 1G y el espacio del usuario ocupa 3G. El espacio del kernel y el espacio de usuario de los sistemas de 64 bits son 128T y ocupan la parte más alta y más baja del espacio de memoria respectivamente, y la parte media no está definida.

No a toda la memoria virtual se le asigna memoria física, solo la que realmente se utiliza. La memoria física asignada se gestiona mediante mapeo de memoria. Para completar el mapeo de memoria, el kernel mantiene una tabla de páginas para cada proceso para registrar la relación de mapeo entre direcciones virtuales y direcciones físicas. En realidad, la tabla de páginas se almacena en la unidad de administración de memoria MMU de la CPU, y el procesador puede encontrar directamente la memoria a la que se accede a través del hardware.

Cuando la dirección virtual a la que accede el proceso no se puede encontrar en la tabla de páginas, el sistema generará una excepción de falla de página, ingresará al espacio del kernel para asignar memoria física, actualizará la tabla de páginas del proceso y luego regresará al espacio del usuario para reanudar el funcionamiento del proceso.

La MMU gestiona la memoria en unidades de páginas, con un tamaño de página de 4 KB. Para resolver el problema de demasiadas entradas en la tabla de páginas, Linux proporciona tablas de páginas de varios niveles y mecanismos HugePage.

Distribución del espacio de memoria virtual.

La memoria del espacio de usuario se divide en cinco segmentos de memoria diferentes, de menor a mayor:

Código de sección de solo lectura y constantes, etc.
Variables globales del segmento de datos , etc.
La memoria asignada dinámicamente por el montón comienza desde la dirección baja y crece hacia arriba.
Biblioteca dinámica de mapeo de archivos , memoria compartida, etc., comenzando desde una dirección alta y creciendo hacia abajo
La pila incluye variables locales y el contexto de llamadas a funciones, etc. El tamaño de la pila es fijo. Normalmente 8 MB

Asignación de memoria y reciclaje.

distribuir

Hay dos formas de implementar malloc correspondiente a llamadas al sistema:

brk() apunta a pequeños bloques de memoria (<128K) y los asigna moviendo la posición superior del montón.

La memoria no se devuelve inmediatamente después de su liberación, sino que se almacena en caché.
Para bloques grandes de memoria (>128K), mmap() utiliza directamente la asignación de memoria para asignar, es decir, encuentra una asignación de memoria libre en el segmento de asignación de archivos.

El caché del primero puede reducir la aparición de excepciones de fallas de página y mejorar la eficiencia del acceso a la memoria. Sin embargo, dado que la memoria no se devuelve al sistema, la asignación/liberación frecuente de memoria provocará su fragmentación cuando la memoria esté ocupada.

Este último se devuelve directamente al sistema cuando se libera, por lo que se producirá una excepción de error de página cada vez que se realice mmap.

Cuando el trabajo de memoria está ocupado, la asignación frecuente de memoria provocará una gran cantidad de excepciones de fallas de página, lo que aumentará la carga de administración del kernel.

Las dos llamadas anteriores en realidad no asignan memoria. Estas memorias solo ingresan al kernel a través de excepciones de falla de página cuando se accede a ellas por primera vez y son asignadas por el kernel.

Reciclar

Cuando la memoria es escasa, el sistema la recupera de las siguientes maneras:

Reciclaje de caché: el algoritmo LRU recupera las páginas de memoria utilizadas menos recientemente;
Recicle la memoria a la que se accede con poca frecuencia: escriba la memoria utilizada con poca frecuencia en el disco a través de la partición de intercambio
Elimine el proceso: mecanismo de protección del kernel OOM (cuanto mayor sea la memoria consumida por el proceso, mayor será el oom_score, más CPU ocupará y menor será el oom_score. Puede ajustar manualmente oom_adj a través de /proc)

echo -16 > /proc/$(pidof XXX)/oom_adj

Cómo comprobar el uso de la memoria

Gratis para ver el uso de memoria de todo el sistema.

top/ps para ver el uso de memoria de un proceso

Tamaño de la memoria virtual VIRT del proceso.
RES El tamaño de la memoria residente, es decir, el tamaño de la memoria física realmente utilizada por el proceso, excluyendo la memoria de intercambio y compartida.
Tamaño de memoria compartida SHR, memoria compartida con otros procesos, bibliotecas de enlaces dinámicos cargadas y segmentos de código de programa
%MEM El porcentaje de memoria física utilizada por el proceso respecto de la memoria total del sistema.

¿Cómo entender el búfer y el caché en la memoria?

El búfer es un caché de datos del disco y el caché es un caché de datos de archivos. Se utilizan tanto en solicitudes de lectura como en solicitudes de escritura.

Cómo utilizar la caché del sistema para optimizar la eficiencia de ejecución del programa

Tasa de aciertos de caché

La tasa de aciertos de la caché se refiere a la cantidad de solicitudes para obtener datos directamente a través de la caché, lo que representa el porcentaje de todas las solicitudes. Cuanto mayor sea la tasa de aciertos, mayores serán los beneficios que aporta la memoria caché y mejor será el rendimiento de la aplicación.

Después de instalar el paquete bcc, puede usar cachestat y cachetop para monitorear las lecturas y escrituras de caché.

Después de instalar pcstat, puede ver el tamaño de caché y la proporción de caché de los archivos en la memoria.

#首先安装Goexport GOPATH=~/goexport PATH=~/go/bin:$PATHgo get golang.org/x/sys/unixgo ge github.com/tobert/pcstat/pcstat

aceleración de caché dd

dd if=/dev/sda1 of=file bs=1M count=512 #生产一个512MB的临时文件echo 3 > /proc/sys/vm/drop_caches #清理缓存pcstat file #确定刚才生成文件不在系统缓存中，此时cached和percent都是0cachetop 5dd if=file of=/dev/null bs=1M #测试文件读取速度#此时文件读取性能为30+MB/s，查看cachetop结果发现并不是所有的读都落在磁盘上，读缓存命中率只有50%。dd if=file of=/dev/null bs=1M #重复上述读文件测试#此时文件读取性能为4+GB/s，读缓存命中率为100%pcstat file #查看文件file的缓存情况，100%全部缓存

La opción O_DIRECT omite el caché

cachetop 5sudo docker run --privileged --name=app -itd feisky/app:io-directsudo docker logs app #确认案例启动成功#实验结果表明每读32MB数据都要花0.9s，且cachetop输出中显示1024次缓存全部命中

Sin embargo, puedo decirlo sintiendo que si el caché llega, la velocidad de lectura no debería ser tan lenta: el número de lecturas es 1024, el tamaño de la página es 4K y se leen datos de 1024 * 4 KB en cinco segundos, que son 0,8 MB. por segundo, que es bastante diferente a los 32 MB del resultado. Muestra que el caché no se utiliza por completo en este caso y se sospecha que la llamada al sistema ha configurado el indicador de E/S directa para omitir el caché del sistema. A continuación, observe las llamadas al sistema.

strace -p $(pgrep app)#strace 结果可以看到openat打开磁盘分区/dev/sdb1，传入参数为O_RDONLY|O_DIRECT

Esto explica por qué leer 32 MB de datos es tan lento: leer y escribir directamente desde el disco debe ser mucho más lento que el almacenamiento en caché. Después de encontrar el problema, miramos el código fuente del caso y descubrimos que el indicador IO directo estaba especificado en indicadores. Elimine esta opción y vuelva a ejecutarla para verificar los cambios de rendimiento.

Pérdida de memoria, ¿cómo localizarla y solucionarla?

Para las aplicaciones, la asignación y el reciclaje de memoria dinámica es un módulo de función lógica central y complejo. Pueden ocurrir varios "accidentes" durante la gestión de la memoria:

La memoria asignada no se recuperó correctamente, lo que provocó fugas
Acceder a una dirección fuera de los límites de la memoria asignada hace que el programa se cierre de forma anormal.

Asignación de memoria y reciclaje.

La distribución de la memoria virtual de menor a mayor se divide en cinco partes: segmento de solo lectura, segmento de datos, montón, segmento de mapeo de memoria y pila. Entre ellos, los que pueden provocar pérdidas de memoria son:

Montón: asignado y administrado por la propia aplicación. A menos que el programa se cierre, el sistema no liberará automáticamente estas memorias del montón.
Segmento de mapeo de memoria: incluye bibliotecas de enlaces dinámicos y memoria compartida, donde el programa asigna y administra automáticamente la memoria compartida.

Las pérdidas de memoria son más dañinas: no solo la aplicación en sí no puede acceder a la memoria que se olvidó liberar, sino que el sistema no puede reasignarla a otras aplicaciones. Las pérdidas de memoria se acumulan e incluso pueden agotar la memoria del sistema.

Cómo detectar pérdidas de memoria

Preinstalación de systat, docker, bcc

sudo docker run --name=app -itd feisky/app:mem-leaksudo docker logs appvmstat 3

Se puede ver que lo gratuito disminuye continuamente y el búfer y el caché permanecen básicamente sin cambios. Esto indica que la memoria del sistema aumenta constantemente. Pero eso no significa que haya una pérdida de memoria. En este momento, puede utilizar la herramienta memleak para realizar un seguimiento de las solicitudes de asignación/liberación de memoria del sistema o proceso.

/usr/share/bcc/tools/memleak -a -p $(pidof app)

En el resultado de memleak, podemos ver que la aplicación asigna memoria constantemente y estas direcciones asignadas no se reclaman. A través de la pila de llamadas podemos ver que la memoria asignada por la función Fibonacci no ha sido liberada. Después de localizar el código fuente, vea el código fuente para corregirlo y agregar la función de liberación de memoria.

¿Por qué el Swap del sistema se vuelve alto?

Cuando los recursos de memoria del sistema son escasos, se pueden utilizar procesos de reciclaje de memoria y eliminación de OOM para resolver el problema. La memoria reciclable incluye:

El caché/búfer es un recurso reciclable, generalmente llamado página de archivos en la administración de archivos.
- Sincronice páginas sucias con el disco mediante fsync en la aplicación
- Déjelo en manos del sistema, y el hilo del núcleo pdflush es responsable de actualizar estas páginas sucias.
- Los datos (páginas sucias) que han sido modificados por la aplicación y que aún no se han escrito en el disco deben escribirse primero en el disco y luego se puede liberar la memoria.
La página de mapeo de archivos obtenida mediante el mapeo de memoria también se puede liberar y volver a leer desde el archivo la próxima vez que se acceda a él.

Para la memoria de montón asignada automáticamente por el programa, es decir, nuestras páginas anónimas en la administración de memoria, aunque esta memoria no se puede liberar directamente, Linux proporciona un mecanismo de intercambio para escribir en el disco la memoria a la que se accede con poca frecuencia para liberar la memoria. en la memoria.

Principio de intercambio

La esencia de Swap es utilizar una parte del espacio en disco o un archivo local como memoria, incluidos dos procesos de intercambio de entrada y salida:

Intercambiar: almacenar los datos de la memoria temporalmente no utilizados por el proceso en el disco y liberar la memoria
Intercambiar: cuando el proceso acceda a la memoria nuevamente, léalos del disco a la memoria

¿Cómo mide Linux si los recursos de memoria son escasos?

Recuperación directa de memoria Se solicitó un nuevo bloque grande de asignación de memoria, pero no quedaba suficiente memoria.

En este momento, el sistema recuperará parte de la memoria;
El subproceso del kernel kswapd0 recupera memoria periódicamente.

Para medir el uso de la memoria, se definen tres umbrales de páginas_min, páginas_bajas y páginas_altas, y se realizan operaciones de reciclaje de memoria en función de ellos.
- Memoria restante <pages_min, la memoria disponible para el proceso está agotada y solo el kernel puede asignar memoria
- páginas_min <memoria restante <páginas_baja, la presión de la memoria es alta, kswapd0 realiza el reciclaje de memoria hasta la memoria restante> páginas_alta
- páginas_bajas <memoria restante <páginas_altas, existe una cierta presión sobre la memoria, pero puede satisfacer nuevas solicitudes de memoria.
- Memoria restante > páginas_alta, lo que indica que hay más memoria restante y que no hay presión de memoria
  páginas_baja = páginas_min 5/4 páginas_alta = páginas_min 3/2

NUMA y SWAP

En muchos casos, al sistema le queda mucha memoria restante, pero el SWAP aún está elevado, esto se debe a la arquitectura NUMA del procesador.

Bajo la arquitectura NUMA, varios procesadores se dividen en diferentes nodos y cada nodo tiene su propio espacio de memoria local. Al analizar el uso de la memoria, cada nodo debe analizarse por separado.

numactl --hardware #查看处理器在Node的分布情况，以及每个Node的内存使用情况

Los tres umbrales de memoria se pueden ver a través de /proc/zoneinfo, que también incluye el número de páginas/páginas de archivos anónimas activas e inactivas.

Cuando un nodo se queda sin memoria, el sistema puede encontrar recursos libres de otros nodos o recuperar memoria de la memoria local. Ajuste a través de /proc/sys/vm/zone_raclaim_mode.

0 significa que puede encontrar recursos gratuitos de otros nodos o recuperar memoria localmente.
1, 2, 4 significa que solo se recicla la memoria local, 2 significa que los datos sucios se pueden devolver a la memoria y 4 significa que la memoria se puede reciclar mediante Swap.

intercambio

Durante el proceso de reciclaje real, Linux ajusta la actividad del uso de Swap de acuerdo con la opción /proc/sys/vm/swapiness, de 0 a 100. Cuanto mayor es el valor, más activamente se usa Swap, es decir, es más propenso a recicla páginas anónimas; cuanto menor sea el valor, más pasivo es. Swap, que prefiere reciclar páginas de archivos.

Nota: Esto solo ajusta el peso de la agresividad del intercambio. Incluso si se establece en 0, el intercambio seguirá ocurriendo cuando la memoria restante + la página del archivo sea menor que el umbral alto de la página.

Cómo localizar y analizar cuando aumenta el Swap

free #首先通过free查看swap使用情况，若swap=0表示未配置Swap#先创建并开启swapfallocate -l 8G /mnt/swapfilechmod 600 /mnt/swapfilemkswap /mnt/swapfileswapon /mnt/swapfile
free #再次执行free确保Swap配置成功
dd if=/dev/sda1 of=/dev/null bs=1G count=2048 #模拟大文件读取sar -r -S 1  #查看内存各个指标变化 -r内存 -S swap#根据结果可以看出，%memused在不断增长，剩余内存kbmemfress不断减少，缓冲区kbbuffers不断增大，由此可知剩余内存不断分配给了缓冲区#一段时间之后，剩余内存很小，而缓冲区占用了大部分内存。此时Swap使用之间增大，缓冲区和剩余内存只在小范围波动
停下sar命令cachetop5 #观察缓存#可以看到dd进程读写只有50%的命中率，未命中数为4w+页，说明正式dd进程导致缓冲区使用升高watch -d grep -A 15 ‘Normal’ /proc/zoneinfo #观察内存指标变化#发现升级内存在一个小范围不停的波动，低于页低阈值时会突然增大到一个大于页高阈值的值

Muestra que la fluctuación de la memoria restante y el búfer se debe al ciclo de reciclaje de memoria y reasignación de caché. A veces, el intercambio se usa más y, a veces, el búfer fluctúa más. En este momento, el valor de intercambio es 60, que es una configuración relativamente neutral. El sistema seleccionará el tipo de reciclaje apropiado según las condiciones operativas reales.

Cómo encontrar problemas de memoria del sistema de forma rápida y precisa

Métricas de rendimiento de la memoria

Métricas de memoria del sistema
Memoria usada/memoria restante
Memoria compartida (implementación de tmpfs)
Memoria disponible: incluida la memoria restante y la memoria recuperable
Caché: caché de página de archivos leídos en disco, parte recuperable en el asignador de losa
Búfer: almacenamiento temporal de bloques de disco sin procesar, caché de datos que se escribirán en el disco

Métricas de memoria de proceso

Memoria virtual: 5 más
Memoria residente: la memoria física realmente utilizada por el proceso, excluyendo la memoria de intercambio y compartida.
Memoria compartida: memoria compartida con otros procesos, así como bibliotecas de enlaces dinámicos y segmentos de código de programas.
Intercambiar memoria: intercambie memoria al disco a través de Intercambiar

Excepción de error de página

Se puede asignar directamente desde la memoria física, excepción de error de página secundaria
Se requiere intervención de E/S de disco (como Swap) y la falla de la página principal es anormal. En este momento, el acceso a la memoria será mucho más lento.

Herramientas de rendimiento de la memoria

Encuentre la herramienta adecuada en función de diferentes indicadores de rendimiento:

imagen

Indicadores de rendimiento incluidos en la herramienta de análisis de memoria:

imagen

Cómo analizar rápidamente los cuellos de botella en el rendimiento de la memoria

Por lo general, ejecute primero varias herramientas de rendimiento con una cobertura relativamente grande, como free, top, vmstat, pidstat, etc.

Primero use free y top para verificar el uso general de memoria del sistema
Luego use vmstat y pidstat para verificar la tendencia durante un período de tiempo para determinar el tipo de problema de memoria.
Finalmente, se realiza un análisis detallado, como análisis de asignación de memoria, análisis de caché/búfer, análisis de uso de memoria de procesos específicos, etc.

Ideas de optimización comunes:

Es mejor deshabilitar el intercambio. Si es necesario habilitarlo, intente reducir el valor del intercambio.
Reduzca la asignación dinámica de memoria, como el grupo de memoria, HugePage, etc.
Intente utilizar cachés y buffers para acceder a los datos. Por ejemplo, use la pila para declarar explícitamente el espacio de memoria para almacenar los datos que deben almacenarse en caché, o use el componente de caché externo de Redis para optimizar el acceso a los datos.
cgroups y otros métodos para limitar el uso de memoria del proceso para garantizar que la memoria del sistema no se agote por procesos anormales
/proc/pid/oom_adj ajusta el oom_score de la aplicación principal para garantizar que OOM no elimine la aplicación principal incluso si la memoria es escasa.

Explicación detallada del uso de vmstat

El comando vmstat es la herramienta de monitoreo de Linux/Unix más común y puede mostrar el valor de estado del servidor en un intervalo de tiempo determinado, incluido el uso de CPU del servidor, el uso de memoria, el estado de intercambio de memoria virtual y el estado de lectura y escritura de IO. Puede ver el uso de CPU, memoria y IO de toda la máquina, en lugar de solo ver el uso de CPU y memoria de cada proceso (los escenarios de uso son diferentes).

vmstat 2procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 1  0      0 1379064 282244 11537528    0    0     3   104    0    0  3  0 97  0  0 0  0      0 1372716 282244 11537544    0    0     0    24 4893 8947  1  0 98  0  0 0  0      0 1373404 282248 11537544    0    0     0    96 5105 9278  2  0 98  0  0 0  0      0 1374168 282248 11537556    0    0     0     0 5001 9208  1  0 99  0  0 0  0      0 1376948 282248 11537564    0    0     0    80 5176 9388  2  0 98  0  0 0  0      0 1379356 282256 11537580    0    0     0   202 5474 9519  2  0 98  0  0 1  0      0 1368376 282256 11543696    0    0     0     0 5894 8940 12  0 88  0  0 1  0      0 1371936 282256 11539240    0    0     0 10554 6176 9481 14  1 85  1  0 1  0      0 1366184 282260 11542292    0    0     0  7456 6102 9983  7  1 91  0  0 1  0      0 1353040 282260 11556176    0    0     0 16924 7233 9578 18  1 80  1  0 0  0      0 1359432 282260 11549124    0    0     0 12576 5495 9271  7  0 92  1  0 0  0      0 1361744 282264 11549132    0    0     0    58 8606 15079  4  2 95  0  0 1  0      0 1367120 282264 11549140    0    0     0     2 5716 9205  8  0 92  0  0 0  0      0 1346580 282264 11562644    0    0     0    70 6416 9944 12  0 88  0  0 0  0      0 1359164 282264 11550108    0    0     0  2922 4941 8969  3  0 97  0  0 1  0      0 1353992 282264 11557044    0    0     0     0 6023 8917 15  0 84  0  0
# 结果说明- r 表示运行队列(就是说多少个进程真的分配到CPU)，我测试的服务器目前CPU比较空闲，没什么程序在跑，当这个值超过了CPU数目，就会出现CPU瓶颈了。这个也和top的负载有关系，一般负载超过了3就比较高，超过了5就高，超过了10就不正常了，服务器的状态很危险。top的负载类似每秒的运行队列。如果运行队列过大，表示你的CPU很繁忙，一般会造成CPU使用率很高。
- b 表示阻塞的进程,这个不多说，进程阻塞，大家懂的。
- swpd 虚拟内存已使用的大小，如果大于0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器。
- free   空闲的物理内存的大小，我的机器内存总共8G，剩余3415M。
- buff   Linux/Unix系统是用来存储，目录里面有什么内容，权限等的缓存，我本机大概占用300多M
- cache cache直接用来记忆我们打开的文件,给文件做缓冲，我本机大概占用300多M(这里是Linux/Unix的聪明之处，把空闲的物理内存的一部分拿来做文件和目录的缓存，是为了提高 程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用。)
- si  每秒从磁盘读入虚拟内存的大小，如果这个值大于0，表示物理内存不够用或者内存泄露了，要查找耗内存进程解决掉。我的机器内存充裕，一切正常。
- so  每秒虚拟内存写入磁盘的大小，如果这个值大于0，同上。
- bi  块设备每秒接收的块数量，这里的块设备是指系统上所有的磁盘和其他块设备，默认块大小是1024byte，我本机上没什么IO操作，所以一直是0，但是我曾在处理拷贝大量数据(2-3T)的机器上看过可以达到140000/s，磁盘写入速度差不多140M每秒
- bo 块设备每秒发送的块数量，例如我们读取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO过于频繁，需要调整。
- in 每秒CPU的中断次数，包括时间中断
- cs 每秒上下文切换次数，例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。
- us 用户CPU时间，我曾经在一个做加密解密很频繁的服务器上，可以看到us接近100,r运行队列达到80(机器在做压力测试，性能表现不佳)。
- sy 系统CPU时间，如果太高，表示系统调用时间长，例如是IO操作频繁。
- id 空闲CPU时间，一般来说，id + us + sy = 100,一般我认为id是空闲CPU使用率，us是用户CPU使用率，sy是系统CPU使用率。
- wt 等待IO CPU时间

Explicación detallada del uso de pidstat

pidstat se utiliza principalmente para monitorear el uso de los recursos del sistema por parte de todos los procesos o de procesos específicos, como CPU, memoria, E/S del dispositivo, cambio de tareas, subprocesos, etc.

Instrucciones:

pidstat –d intervalo de tiempos cuenta el uso de IO de cada proceso
pidstat –u intervalo de tiempos cuenta las estadísticas de CPU de cada proceso
pidstat –r intervalos de tiempo Estadísticas de información de uso de memoria de cada proceso
pidstat -w intervalo de tiempos cuenta el cambio de contexto de cada proceso
p PID PID especificado

1. Estadísticas sobre el uso de IO

pidstat -d 1 10
03:02:02 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command03:02:03 PM     0       816      0.00    918.81      0.00  jbd2/vda1-803:02:03 PM     0      1007      0.00      3.96      0.00  AliYunDun03:02:03 PM   997      7326      0.00   1904.95    918.81  java03:02:03 PM   997      8539      0.00      3.96      0.00  java03:02:03 PM     0     16066      0.00     35.64      0.00  cmagent
03:02:03 PM   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command03:02:04 PM     0       816      0.00   1924.00      0.00  jbd2/vda1-803:02:04 PM   997      7326      0.00  11156.00   1888.00  java03:02:04 PM   997      8539      0.00      4.00      0.00  java

UID
PID
kB_rd/s: la cantidad de datos leídos del disco por el proceso por segundo KB unidad leída del disco cada segundo KB
kB_wr/s: la cantidad de datos escritos en el disco por el proceso por segundo en KB, unidad de escritura en el disco cada segundo KB
kB_ccwr/s: la cantidad de datos escritos en el disco por el proceso por segundo pero cancelados. Esto puede ocurrir cuando la tarea trunca alguna página caché sucia.
iodelay: retardo de E/S del bloque, medido en tics de reloj
Comando: nombre del proceso nombre de la tarea

2. Estadísticas de uso de CPU

# CPU de estadísticas

pidstat -u 1 1003:03:33 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command03:03:34 PM     0      2321    3.96    0.00    0.00    3.96     0  ansible03:03:34 PM     0      7110    0.00    0.99    0.00    0.99     4  pidstat03:03:34 PM   997      8539    0.99    0.00    0.00    0.99     5  java03:03:34 PM   984     15517    0.99    0.00    0.00    0.99     5  java03:03:34 PM     0     24406    0.99    0.00    0.00    0.99     5  java03:03:34 PM     0     32158    3.96    0.00    0.00    3.96     2  ansible

UID
PID
%usr: el porcentaje de CPU ocupada por el proceso en el espacio del usuario
% sistema: el porcentaje de CPU ocupada por el proceso en el espacio del kernel
% invitado: el porcentaje de CPU ocupado por el proceso en la máquina virtual
%espera: el porcentaje del proceso esperando para ejecutarse.
%CPU: El porcentaje de CPU ocupado por el proceso.
CPU: número de CPU del proceso de procesamiento
Comando: nombre del proceso

3. Estadísticas de uso de memoria.

# 统计内存pidstat -r 1 10Average:      UID       PID  minflt/s  majflt/s     VSZ    RSS   %MEM  CommandAverage:        0         1      0.20      0.00  191256   3064   0.01  systemdAverage:        0      1007      1.30      0.00  143256  22720   0.07  AliYunDunAverage:        0      6642      0.10      0.00 6301904 107680   0.33  javaAverage:      997      7326     10.89      0.00 13468904 8395848  26.04  javaAverage:        0      7795    348.15      0.00  108376   1233   0.00  pidstatAverage:      997      8539      0.50      0.00 8242256 2062228   6.40  javaAverage:      987      9518      0.20      0.00 6300944 1242924   3.85  javaAverage:        0     10280      3.70      0.00  807372   8344   0.03  aliyun-serviceAverage:      984     15517      0.40      0.00 6386464 1464572   4.54  javaAverage:        0     16066    236.46      0.00 2678332  71020   0.22  cmagentAverage:      995     20955      0.30      0.00 6312520 1408040   4.37  javaAverage:      995     20956      0.20      0.00 6093764 1505028   4.67  javaAverage:        0     23936      0.10      0.00 5302416 110804   0.34  javaAverage:        0     24406      0.70      0.00 10211672 2361304   7.32  javaAverage:        0     26870      1.40      0.00 1470212  36084   0.11  promtail

UID
PID
Minflt/s: el número de errores de página por segundo (errores de página menores), el número de errores de página generados al asignar una dirección de memoria virtual a una dirección de memoria física
Majflt/s: Fallos importantes de página por segundo. Cuando la dirección de memoria virtual se asigna a una dirección de memoria física, la página correspondiente está en intercambio.
Uso de memoria virtual VSZ: unidad de KB de memoria virtual utilizada por este proceso
RSS: Unidad KB de memoria física utilizada por este proceso
%MEM: uso de memoria
Comando: el nombre de la tarea de comando de este proceso.

4. Verifique el uso de procesos específicos.

pidstat -T ALL -r -p 20955 1 1003:12:16 PM   UID       PID  minflt/s  majflt/s     VSZ    RSS   %MEM  Command03:12:17 PM   995     20955      0.00      0.00 6312520 1408040   4.37  java
03:12:16 PM   UID       PID minflt-nr majflt-nr  Command03:12:17 PM   995     20955         0         0  java

Fuente: https://www.ctq6.cn/linux%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/