perf top Linux: detectar puntos calientes de la CPU en el kernel

Con perf top En Linux puedo averiguar en cuestión de segundos qué funciones del kernel están consumiendo actualmente la mayor parte del tiempo de CPU y dónde se producen los cuellos de botella. En esta guía te muestro, mediante pasos claros, cómo detecto los puntos críticos en tiempo real, cómo interpreto correctamente los resultados y cómo deduzco a partir de ellos optimizaciones rápidas para el programador, la red y la memoria.

Puntos centrales

Considero que la vista en directo de perfecto Es ideal como punto de partida, ya que permite identificar de inmediato las tareas que más tiempo consumen. Los porcentajes que aparecen junto a cada símbolo me indican si el cuello de botella se encuentra en el Núcleo o si se encuentra en el espacio de usuario. A partir de patrones recurrentes, determino si predominan los bloqueos, las IRQ, la red o la memoria. A continuación, delimito el punto crítico con herramientas más avanzadas y compruebo los cambios directamente bajo carga. De este modo, voy mejorando paso a paso la CPU-Optimizar la utilización de recursos y reducir las latencias de forma sostenible.

• Puntos de acceso en directo identificar y priorizar
• Porcentajes interpretar correctamente según cada función
• Enfoque principal configurar: IRQ, bloqueos, memoria
• Flujo de trabajo: inicio → registro → informe
• Optimizaciones verificar de forma específica

¿Qué es Perf Top y para qué sirve?

Utilizo perf top, para ver al instante, mientras se ejecutan las tareas, qué símbolos consumen la mayor parte del tiempo de CPU. La herramienta accede a los contadores de rendimiento del hardware y me muestra, a intervalos cortos, una clasificación actualizada de las funciones que más recursos consumen. Según la revista Linux-Magazin, «perf» domina tanto el perfilado como el rastreo, lo que hace que la Vista en directo se integra a la perfección con análisis más detallados. En el proceso habitual, complemento la instantánea con «perf record» y «perf report» para examinar los gráficos de llamadas y las rutas exactas. Así respondo a la pregunta fundamental: ¿Dónde pasa el CPU ¿Justo en ese momento —en la pila de red, en el subsistema de memoria, en el programador o en un controlador?

Instalar e iniciar Perf Top

Tras la instalación mediante el paquete de distribución, ejecuto perfecto Por lo general, „top“ se ejecuta con permisos ampliados para que se puedan ver los símbolos del núcleo y los eventos del sistema. Basta con ejecutar «perf top» para obtener una primera vista en tiempo real e identificar las funciones más importantes. Si necesito centrarme en procesos concretos, añado el PID con la opción -p; para CPU específicas utilizo la opción -C con una lista o un rango. Defino los eventos con la opción -e, por ejemplo, ciclos de CPU, instrucciones o fallos de ramificación, dependiendo de la cuestión que quiera aclarar. Para obtener resultados reproducibles, inicio la medición durante una carga real, de modo que Puntos de acceso se vean claramente y no se pierdan entre el ruido de fondo.

Así es como leo correctamente la edición

En la lista, lo primero que evalúo es el Valores porcentuales por símbolo, ya que reflejan las proporciones relativas de tiempo. Unos porcentajes elevados en las funciones del sistema indican un cuello de botella en el núcleo, mientras que los símbolos dominantes del espacio de usuario suelen apuntar a la lógica de la aplicación. Si veo muchas rutinas del programador, pienso en un exceso de subprocesos activos, afinidades inadecuadas o prioridades inapropiadas. Si aparecen funciones de memoria en los primeros puestos, compruebo los patrones de asignación, los errores de página, la localidad NUMA y las cachés. En el caso de las rutas de red, analizo la distribución de IRQ, la configuración de Gro/TSO y el comportamiento de los controladores, ya que esos detalles son los que Latencia influir considerablemente en ello.

Causas habituales de los puntos críticos del núcleo

Muchos puntos conflictivos surgen porque muchos pequeños gastos se acumulan hasta convertirse en uno grande Carga se suman. A menudo, los cambios excesivos de contexto, la competencia por el bloqueo y las IRQ distribuidas de forma desigual aumentan el tiempo de CPU. Del mismo modo, las estructuras de memoria fragmentadas, el uso ineficiente de los slabs o el paginamiento constante consumen ciclos innecesarios. Si me llama la atención un controlador concreto, lo correlaciono con la carga de trabajo, el hardware y la versión para delimitar los efectos secundarios. En los sistemas multinúcleo, compruebo además el «false sharing», ya que, según la documentación del kernel, las líneas de caché compartidas pueden provocar rápidamente un costoso Sobrecarga pueden causar preocupación.

Análisis ilustrativo de un punto crítico

Si observo que, durante un periodo prolongado, hay un porcentaje elevado de tráfico relacionado con funciones de red, lo primero que hago es clasificar los tipos de carga: paquetes pequeños frente a paquetes grandes, TLS frente a texto sin cifrar, muchas conexiones frente a pocas sesiones de larga duración, para poder Causa delimitar. A continuación, profundizo con «perf record» y «perf report», activo los gráficos de llamadas (-g) y comparo las rutas a lo largo de varias ejecuciones. Si, por el contrario, el problema radica en la gestión de la memoria, compruebo el alocador, las Huge Pages, la configuración de THP y la afinidad NUMA, ya que en este ámbito pueden surgir rápidamente rutas innecesarias. A menudo interpreto los puntos críticos del programador como un indicio de que hay demasiados hilos ejecutables o de una asignación inadecuada a la CPU. Solo cambio uno a la vez Parámetros por cada ciclo, para poder atribuirle correctamente el efecto.

Lo mejor en entornos de alojamiento web

En entornos de alojamiento, a menudo veo cómo los pequeños costes del núcleo influyen en la Latencia de muchos servicios. Los contenedores, las máquinas virtuales y las instancias de bases de datos que se ejecutan en paralelo desplazan el perfil claramente hacia la red, el almacenamiento y el programador. Con «perf top» puedo detectar si los cuellos de botella se encuentran más bien en la gestión de IRQ, el procesamiento de SoftIRQ o en las rutas de bloqueo. A continuación, incluyo en el análisis la versión del kernel, la disposición NUMA, las afinidades de IRQ y las profundidades de cola, ya que estos factores interactúan entre sí. Quien desee profundizar más, encontrará en esta guía sobre Analizar los cuellos de botella de la CPU Otros puntos de partida prácticos que utilizo habitualmente en mi trabajo.

Guía práctica para el análisis

Empezaré con un escenario de carga reproducible, para que las mediciones sean comparables y Puntos de acceso aparecen de forma estable. A continuación, ejecuto «perf top» y anoto los símbolos dominantes a lo largo de varias actualizaciones. Con «perf record/report» sintetizo esta instantánea en una imagen clara de los gráficos de llamadas, para poder identificar la ruta hacia el punto que consume más recursos. A continuación, modifico de forma específica solo un aspecto, por ejemplo, una afinidad de IRQ o la profundidad de una cola, y vuelvo a realizar la medición. Solo cuando el efecto es evidente, paso al siguiente Paso analizo y documento las conclusiones para futuras ventanas de mantenimiento.

Cuándo conviene utilizar otras herramientas

Para obtener una visión histórica, gráficos de llamadas más detallados o cadenas de eventos específicas, recurro a perfecto record/report, ftrace o eBPF. Los puntos de seguimiento me ayudan a analizar rutas concretas, mientras que con los programas BPF obtengo métricas flexibles. Si quiero profundizar en las rutas del núcleo, me proporcionan Herramientas de análisis de eBPF Señales valiosas directamente en el lugar de los hechos. Para los problemas de caché y de uso compartido, perf-c2c y pahole resultan útiles en cuanto se identifica claramente el punto crítico. Así es como voy avanzando en el análisis desde la vista en tiempo real hasta la causa, sin perderme en detalles irrelevantes detalles perder.

Opciones de muestreo y filtros en la práctica

Me paso a la Muestreo-Estrategia adaptada a la situación concreta, en lugar de medir todo de forma generalizada. En caso de picos esporádicos, aumento la frecuencia de muestreo y acorto los intervalos de visualización para captar los picos fugaces. Para centrarme en un proceso, establezco -p en el PID correspondiente; para centrarme en la CPU, -C en los núcleos más activos. Con -e controlo el evento, por ejemplo, «cpu-cycles» para un perfilado amplio o «cache-misses» si sospecho que hay un problema de caché. Utilizo los gráficos de llamadas (-g) en cuanto he localizado aproximadamente un punto crítico y la Causa que quiere encontrar en la pila.

La siguiente tabla muestra interruptores prácticos que suelo combinar a menudo en mi día a día, así como los usos típicos de cada opción:

Opción	Efecto	Utilice
-p PID	Limita la medición a un proceso	Específicas de la aplicación Puntos de acceso delimitar
-C Lista de CPU	Enfoque en áreas clave seleccionadas	Comprobar la distribución de NUMA/IRQ
-e Evento	Selecciona un evento de hardware o de software	ciclos, instrucciones, fallos de caché
-g	Activa el muestreo de Callgraph	Caminos caros en el Pila Reconocer
–kernel/–user	Filtra en el espacio del núcleo o en el espacio de usuario	Separar la fuente del tiempo de CPU
–ordenar	Ordenado por símbolo, DSO, dso:symbol	Legibilidad de la Clasificación aumentar

Siempre pruebo brevemente las configuraciones antes de iniciar mediciones más largas, para que la Pantalla se mantenga estable y no se produzcan efectos secundarios. Especialmente con frecuencias de muestreo elevadas, presto atención a la sobrecarga para no sobrecargar el sistema innecesariamente. En el caso de los hosts de contenedores, compruebo además si los límites de los espacios de nombres y los cgroups restringen la visibilidad. Para obtener pruebas de rendimiento reproducibles, documento todos los parámetros, incluidas las versiones del núcleo y de los controladores. Esta disciplina me ahorra mucho trabajo más adelante Tiempo a la hora de clasificar los cambios.

Interpretación de los subsistemas: red, memoria y programador

Cuando las rutas de red aparecen en la parte superior, lo primero que compruebo son las afinidades de IRQ, el RSS (Receive-Side-Scaling) y las descargas como GRO/TSO, ya que estos parámetros son los que Rendimiento-Modificar el equilibrio de latencia. Cuando observo comportamientos anómalos en las funciones de memoria, analizo los patrones de asignación, las páginas enormes (Huge Pages), las estadísticas de slabs y las tasas de fallos de página. A menudo relaciono la carga del programador con un número excesivo de subprocesos, la falta de afinidad de la CPU o una priorización injusta. Para eventos específicos del núcleo, además, establezco puntos de rastreo o utilizo bpftrace en el alojamiento web, para confirmar hipótesis. Así, relaciono la observación en directo desde «perf top» con puntos de medición más profundos y llego más rápido a la Causa.

Requisitos y visibilidad de los símbolos

De modo que perf top Al resolver todos los símbolos relevantes del núcleo, presto atención a dos aspectos: los permisos adecuados y la información disponible sobre los símbolos. En los sistemas de producción, kernel.perf_event_paranoid a menudo se establece en un valor alto. Para obtener una visión detallada del núcleo, reduzco este valor temporalmente o trabajo como usuario «root» con los permisos necesarios (CAP_PERFMON/CAP_SYS_ADMIN). Si las direcciones del núcleo están enmascaradas (kptr_restrict), suelo ver los nombres de todos modos, pero no las direcciones brutas; eso me basta para establecer prioridades. Para el espacio de usuario, instalo los paquetes de información de depuración correspondientes, para que «perf top» muestre los nombres de las funciones en lugar de los desplazamientos. Esto reduce las conjeturas y acelera la búsqueda de la causa.

Porcentajes y dificultades del muestreo

Interpreto los porcentajes de la lista como porcentajes relativos de las muestras medidas, no como una carga de CPU exacta en el dominio del tiempo. Si selecciono varios eventos, puedo Multiplexación aplicar: Perf distribuye los contadores a lo largo del tiempo y normalizado la visualización. Para obtener una imagen clara, primero mido de forma general con ciclos de CPU o instrucciones, y luego añado eventos especiales. Los picos momentáneos los detecto con una frecuencia más alta (-F) e intervalos más cortos; en sistemas con poca actividad, basta con la frecuencia estándar. Además, tengo en cuenta que Ocioso-Las fases y los cambios de frecuencia (turbo, regulador) pueden distorsionar la percepción. Por eso, para realizar mediciones comparativas, unifico los ajustes de cadencia y energía.

Los gráficos de llamadas en profundidad

Cuando identifico un punto crítico, aumento la precisión del análisis mediante gráficos de llamadas. Con -g y, con un método de desenrollado adecuado, consigo la ruta hasta el punto costoso. Los punteros de trama o el desenrollado DWARF me proporcionan pilas estables; cuando está disponible, utilizo el búfer de retorno asistido por hardware (LBR) para obtener cadenas muy precisas. Aumento los búferes mmap solo lo necesario para mantener baja la sobrecarga. Si la pila muestra muchas funciones auxiliares, presto atención a incluido vs. exclusivo Costes: lo decisivo es si la función en sí misma es costosa o si solo predomina como vía de tránsito. Esta distinción a menudo me ahorra horas a la hora de investigar las causas.

Trabajar en contenedores y máquinas virtuales

En entornos de contenedores, compruebo si mi vista de cgroups y que los espacios de nombres sean correctos. Centro las mediciones en los PID y las CPU relevantes, para que los «vecinos ruidosos» no distorsionen el panorama. En el caso de las máquinas virtuales, compruebo si la PMU virtual está habilitada; de lo contrario, me faltan eventos de hardware precisos y solo veo señales de software. A menudo reconozco los hosts KVM por los símbolos que aparecen alrededor de kvm_vcpu o vmx/svm. En este tipo de situaciones, separo claramente los análisis del host y del invitado para no confundir causa y efecto.

Patrones reconocibles e hipótesis rápidas

En el día a día hay ciertos patrones que han demostrado su eficacia y que compruebo de inmediato:

• Competencia de Lock: Buceo queued_spin_lock_slowpath o mutex_spin_on_owner En este caso, las estructuras de datos son demasiado generales o las colas de trabajo están demasiado limitadas. Reduzco la contienda mediante el sharding, una granularidad de bloqueo más precisa o la modificación del tamaño de los lotes.
• Impresión del planificador: Se acumulan schedule(), pick_next_task_fair o las rutas de activación, ajusto el número de subprocesos, las afinidades y las prioridades. A menudo basta con “calmar” los subprocesos «charlatanes» o definir correctamente los ajustes de la CPU.
• SoftIRQ de red: Picos en net_rx_action, napi_poll O bien, las descargas de sumas de comprobación indican una avalancha de paquetes o una distribución subóptima de RSS e IRQ. Asigno las IRQ a los núcleos adecuados y ajusto GRO/TSO para obtener el perfil de rendimiento/latencia deseado.
• Rutas de almacenamiento: Mucho tiempo en do_page_fault, copy_user_* O las funciones «Slab» me permiten comprobar los patrones de asignación, THP/Huge Pages y la localidad NUMA. Una asignación incorrecta supone aquí una pérdida de muchos ciclos que pasa desapercibida.
• RCU y temporizadores: Dominar rcu_core o las llamadas de retorno del temporizador, estoy replanteándome las estrategias de sondeo y procesamiento por lotes de mis servicios para que el sistema funcione de forma más fluida.

Profundizar en la precisión de las mediciones y la reproducibilidad

Para garantizar que las ejecuciones sean comparables, mantengo constantes los factores ambientales: el regulador de la CPU, los estados Turbo, las tareas en segundo plano e incluso la temperatura ambiente en el caso de nodos densos. Asigno las cargas de prueba a núcleos definidos y, opcionalmente, aíslo las CPU con mayor actividad para que las decisiones del programador se mantengan estables. Documento los cambios, incluyendo las versiones del kernel, los controladores y el firmware. En el caso de ajustes más arriesgados, establezco puntos de restauración y vuelvo a realizar mediciones inmediatamente después de la intervención. De este modo, obtengo una Antes/Después-Una historia que aún puedo entender incluso meses después.

Consejos prácticos: comandos que utilizo con frecuencia

Dependiendo de la pregunta, utilizo fórmulas concisas:

• Ancho de escaneo bajo carga: perf top -e cpu-cycles –kernel –user
  Una visión general rápida para saber si es el núcleo o el espacio de usuario el que lleva la voz cantante.
• Enfoque en los procesos con Callgraph: perf top -p PID -g –kernel –user
  Muéstrame las rutas en tiempo real de la aplicación en cuestión, sin ruido del sistema.
• Enfoque en la CPU: perf top -C 2-5 -e ciclos de CPU -g
  Ayuda a resolver los puntos críticos de NUMA o IRQ cuando solo unos pocos núcleos se “sobrecalientan”.
• Sospecha de almacenamiento: perf top -e cache-misses -e cycles -g –kernel
  Muestra las rutas de almacenamiento en relación con los ciclos.
• Fijar los picos sueltos: perf top -F 999 -I 1000 -e ciclos
  Una frecuencia más alta y unos intervalos de visualización más cortos permiten detectar picos breves.

Orientaciones interpretativas para subsistemas concretos

En Red Además de NAPI y las rutas RX/TX, también analizo los componentes TLS/cripto, que pueden llegar a predominar cuando hay un gran volumen de handshakes. Compruebo si la técnica «zero-copy» o la «coalescing» se aplican de forma adecuada y si los segmentos grandes (TSO/GSO) superan mis límites de latencia. En el Memoria-En este ámbito, me fijo en el THP: ¿me ayuda a reducir la carga o los eventos de división/fusión provocan interferencias? En Almacenamiento lo interpreto blk_mq-Símbolos y rutas io_uring como indicación de la profundidad de las colas y las estrategias de fusión. En el programador Vinculo las avalanchas de Wakeup con cadenas Lock o IO y equilibró las rutas mediante contrapresión en lugar de “más subprocesos”.

Límites de «perf top» y cuándo cambio de estrategia

Porque perf top Al tratarse de un método basado en el muestreo, me resulta más fácil interpretar imágenes promediadas que eventos individuales. Para cadenas de ejecución deterministas, recurro a Tracepoints, ftrace o eBPF con el fin de demostrar causalidades precisas. Si necesito una cuantificación exacta (por ejemplo, instrucciones por solicitud), lo combino con estado perfecto o análisis sin conexión desde «perf record/report». Si me encuentro con pilas poco claras (símbolos que faltan, desenrollado erróneo), lo primero que hago es solucionar el problema de visibilidad; de lo contrario, sería como andar a ciegas.

Brevemente resumido

Con perf top Puedo detectar en tiempo real dónde la CPU pierde tiempo en el kernel y qué símbolos debo analizar primero. A partir de los porcentajes, los patrones recurrentes y la separación entre el espacio del kernel y el espacio de usuario, deduzco los siguientes pasos a seguir. A continuación, sintetizo los resultados con «perf record/report», verifico los cambios bajo carga y documento mi cadena de mediciones. En entornos de alojamiento, este procedimiento resulta especialmente útil, ya que muchos servicios y contenedores se benefician mutuamente en cuanto las rutas del núcleo funcionan de forma más eficiente. Quien interiorice este proceso ahorra días de diagnóstico y reduce Latencias y consigue tiempos de respuesta notablemente más estables bajo carga real.