{"id":20626,"date":"2026-08-14T08:35:54","date_gmt":"2026-08-14T06:35:54","guid":{"rendered":"https:\/\/webhosting.de\/perf-top-linux-hotspots-kernel-tools\/"},"modified":"2026-08-14T08:35:54","modified_gmt":"2026-08-14T06:35:54","slug":"perf-top-linux-hotspots-herramientas-del-kernel","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/perf-top-linux-hotspots-kernel-tools\/","title":{"rendered":"perf top Linux: detectar puntos calientes de la CPU en el kernel"},"content":{"rendered":"<p>Con <strong>perf top<\/strong> En Linux puedo averiguar en cuesti\u00f3n de segundos qu\u00e9 funciones del kernel est\u00e1n consumiendo actualmente la mayor parte del tiempo de CPU y d\u00f3nde se producen los cuellos de botella. En esta gu\u00eda te muestro, mediante pasos claros, c\u00f3mo detecto los puntos cr\u00edticos en tiempo real, c\u00f3mo interpreto correctamente los resultados y c\u00f3mo deduzco a partir de ellos optimizaciones r\u00e1pidas para el programador, la red y la memoria.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<p>Considero que la vista en directo de <strong>perfecto<\/strong> Es ideal como punto de partida, ya que permite identificar de inmediato las tareas que m\u00e1s tiempo consumen. Los porcentajes que aparecen junto a cada s\u00edmbolo me indican si el cuello de botella se encuentra en el <strong>N\u00facleo<\/strong> 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\u00f3n, delimito el punto cr\u00edtico con herramientas m\u00e1s avanzadas y compruebo los cambios directamente bajo carga. De este modo, voy mejorando paso a paso la <strong>CPU<\/strong>-Optimizar la utilizaci\u00f3n de recursos y reducir las latencias de forma sostenible.<\/p>\n<ul>\n  <li><strong>Puntos de acceso en directo<\/strong> identificar y priorizar<\/li>\n  <li><strong>Porcentajes<\/strong> interpretar correctamente seg\u00fan cada funci\u00f3n<\/li>\n  <li><strong>Enfoque principal<\/strong> configurar: IRQ, bloqueos, memoria<\/li>\n  <li><strong>Flujo de trabajo<\/strong>: inicio \u2192 registro \u2192 informe<\/li>\n  <li><strong>Optimizaciones<\/strong> verificar de forma espec\u00edfica<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpu-hotspots-linux-kernel-4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00bfQu\u00e9 es Perf Top y para qu\u00e9 sirve?<\/h2>\n\n<p>Utilizo <strong>perf top<\/strong>, para ver al instante, mientras se ejecutan las tareas, qu\u00e9 s\u00edmbolos 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\u00f3n actualizada de las funciones que m\u00e1s recursos consumen. Seg\u00fan la revista Linux-Magazin, \u00abperf\u00bb domina tanto el perfilado como el rastreo, lo que hace que la <strong>Vista en directo<\/strong> se integra a la perfecci\u00f3n con an\u00e1lisis m\u00e1s detallados. En el proceso habitual, complemento la instant\u00e1nea con \u00abperf record\u00bb y \u00abperf report\u00bb para examinar los gr\u00e1ficos de llamadas y las rutas exactas. As\u00ed respondo a la pregunta fundamental: \u00bfD\u00f3nde pasa el <strong>CPU<\/strong> \u00bfJusto en ese momento \u2014en la pila de red, en el subsistema de memoria, en el programador o en un controlador?<\/p>\n\n<h2>Instalar e iniciar Perf Top<\/h2>\n\n<p>Tras la instalaci\u00f3n mediante el paquete de distribuci\u00f3n, ejecuto <strong>perfecto<\/strong> Por lo general, \u201etop\u201c se ejecuta con permisos ampliados para que se puedan ver los s\u00edmbolos del n\u00facleo y los eventos del sistema. Basta con ejecutar \u00abperf top\u00bb para obtener una primera vista en tiempo real e identificar las funciones m\u00e1s importantes. Si necesito centrarme en procesos concretos, a\u00f1ado el <strong>PID<\/strong> con la opci\u00f3n -p; para CPU espec\u00edficas utilizo la opci\u00f3n -C con una lista o un rango. Defino los eventos con la opci\u00f3n -e, por ejemplo, ciclos de CPU, instrucciones o fallos de ramificaci\u00f3n, dependiendo de la cuesti\u00f3n que quiera aclarar. Para obtener resultados reproducibles, inicio la medici\u00f3n durante una carga real, de modo que <strong>Puntos de acceso<\/strong> se vean claramente y no se pierdan entre el ruido de fondo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpuhotspotslinux3746.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>As\u00ed es como leo correctamente la edici\u00f3n<\/h2>\n\n<p>En la lista, lo primero que eval\u00fao es el <strong>Valores porcentuales<\/strong> por s\u00edmbolo, ya que reflejan las proporciones relativas de tiempo. Unos porcentajes elevados en las funciones del sistema indican un cuello de botella en el n\u00facleo, mientras que los s\u00edmbolos dominantes del espacio de usuario suelen apuntar a la l\u00f3gica de la aplicaci\u00f3n. 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\u00f3n, los errores de p\u00e1gina, la localidad NUMA y las cach\u00e9s. En el caso de las rutas de red, analizo la distribuci\u00f3n de IRQ, la configuraci\u00f3n de Gro\/TSO y el comportamiento de los controladores, ya que esos detalles son los que <strong>Latencia<\/strong> influir considerablemente en ello.<\/p>\n\n<h2>Causas habituales de los puntos cr\u00edticos del n\u00facleo<\/h2>\n\n<p>Muchos puntos conflictivos surgen porque muchos peque\u00f1os gastos se acumulan hasta convertirse en uno grande <strong>Carga<\/strong> 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\u00f3n un controlador concreto, lo correlaciono con la carga de trabajo, el hardware y la versi\u00f3n para delimitar los efectos secundarios. En los sistemas multin\u00facleo, compruebo adem\u00e1s el \u00abfalse sharing\u00bb, ya que, seg\u00fan la documentaci\u00f3n del kernel, las l\u00edneas de cach\u00e9 compartidas pueden provocar r\u00e1pidamente un costoso <strong>Sobrecarga<\/strong> pueden causar preocupaci\u00f3n.<\/p>\n\n<h2>An\u00e1lisis ilustrativo de un punto cr\u00edtico<\/h2>\n\n<p>Si observo que, durante un periodo prolongado, hay un porcentaje elevado de tr\u00e1fico relacionado con funciones de red, lo primero que hago es clasificar los tipos de carga: paquetes peque\u00f1os frente a paquetes grandes, TLS frente a texto sin cifrar, muchas conexiones frente a pocas sesiones de larga duraci\u00f3n, para poder <strong>Causa<\/strong> delimitar. A continuaci\u00f3n, profundizo con \u00abperf record\u00bb y \u00abperf report\u00bb, activo los gr\u00e1ficos de llamadas (-g) y comparo las rutas a lo largo de varias ejecuciones. Si, por el contrario, el problema radica en la gesti\u00f3n de la memoria, compruebo el alocador, las Huge Pages, la configuraci\u00f3n de THP y la afinidad NUMA, ya que en este \u00e1mbito pueden surgir r\u00e1pidamente rutas innecesarias. A menudo interpreto los puntos cr\u00edticos del programador como un indicio de que hay demasiados hilos ejecutables o de una asignaci\u00f3n inadecuada a la CPU. Solo cambio uno a la vez <strong>Par\u00e1metros<\/strong> por cada ciclo, para poder atribuirle correctamente el efecto.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-cpu-hotspots-perf-top-7351.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lo mejor en entornos de alojamiento web<\/h2>\n\n<p>En entornos de alojamiento, a menudo veo c\u00f3mo los peque\u00f1os costes del n\u00facleo influyen en la <strong>Latencia<\/strong> de muchos servicios. Los contenedores, las m\u00e1quinas 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 \u00abperf top\u00bb puedo detectar si los cuellos de botella se encuentran m\u00e1s bien en la gesti\u00f3n de IRQ, el procesamiento de SoftIRQ o en las rutas de bloqueo. A continuaci\u00f3n, incluyo en el an\u00e1lisis la versi\u00f3n del kernel, la disposici\u00f3n NUMA, las afinidades de IRQ y las profundidades de cola, ya que estos factores interact\u00faan entre s\u00ed. Quien desee profundizar m\u00e1s, encontrar\u00e1 en esta gu\u00eda sobre <a href=\"https:\/\/webhosting.de\/es\/herramienta-perf-de-linux-analisis-de-cuellos-de-botella-de-la-cpu-optimizacion-carga-del-servidor-perfilado\/\">Analizar los cuellos de botella de la CPU<\/a> Otros puntos de partida pr\u00e1cticos que utilizo habitualmente en mi trabajo.<\/p>\n\n<h2>Gu\u00eda pr\u00e1ctica para el an\u00e1lisis<\/h2>\n\n<p>Empezar\u00e9 con un escenario de carga reproducible, para que las mediciones sean comparables y <strong>Puntos de acceso<\/strong> aparecen de forma estable. A continuaci\u00f3n, ejecuto \u00abperf top\u00bb y anoto los s\u00edmbolos dominantes a lo largo de varias actualizaciones. Con \u00abperf record\/report\u00bb sintetizo esta instant\u00e1nea en una imagen clara de los gr\u00e1ficos de llamadas, para poder identificar la ruta hacia el punto que consume m\u00e1s recursos. A continuaci\u00f3n, modifico de forma espec\u00edfica solo un aspecto, por ejemplo, una afinidad de IRQ o la profundidad de una cola, y vuelvo a realizar la medici\u00f3n. Solo cuando el efecto es evidente, paso al siguiente <strong>Paso<\/strong> analizo y documento las conclusiones para futuras ventanas de mantenimiento.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/TechOffice_Nacht_CPUs_3421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cu\u00e1ndo conviene utilizar otras herramientas<\/h2>\n\n<p>Para obtener una visi\u00f3n hist\u00f3rica, gr\u00e1ficos de llamadas m\u00e1s detallados o cadenas de eventos espec\u00edficas, recurro a <strong>perfecto<\/strong> record\/report, ftrace o eBPF. Los puntos de seguimiento me ayudan a analizar rutas concretas, mientras que con los programas BPF obtengo m\u00e9tricas flexibles. Si quiero profundizar en las rutas del n\u00facleo, me proporcionan <a href=\"https:\/\/webhosting.de\/es\/ebpf-herramientas-de-analisis-de-linux-supervision-de-servidores-informacion-detallada\/\">Herramientas de an\u00e1lisis de eBPF<\/a> Se\u00f1ales valiosas directamente en el lugar de los hechos. Para los problemas de cach\u00e9 y de uso compartido, perf-c2c y pahole resultan \u00fatiles en cuanto se identifica claramente el punto cr\u00edtico. As\u00ed es como voy avanzando en el an\u00e1lisis desde la vista en tiempo real hasta la causa, sin perderme en detalles irrelevantes <strong>detalles<\/strong> perder.<\/p>\n\n<h2>Opciones de muestreo y filtros en la pr\u00e1ctica<\/h2>\n\n<p>Me paso a la <strong>Muestreo<\/strong>-Estrategia adaptada a la situaci\u00f3n concreta, en lugar de medir todo de forma generalizada. En caso de picos espor\u00e1dicos, aumento la frecuencia de muestreo y acorto los intervalos de visualizaci\u00f3n 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\u00facleos m\u00e1s activos. Con -e controlo el evento, por ejemplo, \u00abcpu-cycles\u00bb para un perfilado amplio o \u00abcache-misses\u00bb si sospecho que hay un problema de cach\u00e9. Utilizo los gr\u00e1ficos de llamadas (-g) en cuanto he localizado aproximadamente un punto cr\u00edtico y la <strong>Causa<\/strong> que quiere encontrar en la pila.<\/p>\n\n<p>La siguiente tabla muestra interruptores pr\u00e1cticos que suelo combinar a menudo en mi d\u00eda a d\u00eda, as\u00ed como los usos t\u00edpicos de cada opci\u00f3n:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Opci\u00f3n<\/th>\n      <th>Efecto<\/th>\n      <th>Utilice<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>-p<\/strong> PID<\/td>\n      <td>Limita la medici\u00f3n a un proceso<\/td>\n      <td>Espec\u00edficas de la aplicaci\u00f3n <strong>Puntos de acceso<\/strong> delimitar<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-C<\/strong> Lista de CPU<\/td>\n      <td>Enfoque en \u00e1reas clave seleccionadas<\/td>\n      <td>Comprobar la distribuci\u00f3n de NUMA\/IRQ<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-e<\/strong> Evento<\/td>\n      <td>Selecciona un evento de hardware o de software<\/td>\n      <td>ciclos, instrucciones, fallos de cach\u00e9<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-g<\/strong><\/td>\n      <td>Activa el muestreo de Callgraph<\/td>\n      <td>Caminos caros en el <strong>Pila<\/strong> Reconocer<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>\u2013kernel\/\u2013user<\/strong><\/td>\n      <td>Filtra en el espacio del n\u00facleo o en el espacio de usuario<\/td>\n      <td>Separar la fuente del tiempo de CPU<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>\u2013ordenar<\/strong><\/td>\n      <td>Ordenado por s\u00edmbolo, DSO, dso:symbol<\/td>\n      <td>Legibilidad de la <strong>Clasificaci\u00f3n<\/strong> aumentar<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Siempre pruebo brevemente las configuraciones antes de iniciar mediciones m\u00e1s largas, para que la <strong>Pantalla<\/strong> se mantenga estable y no se produzcan efectos secundarios. Especialmente con frecuencias de muestreo elevadas, presto atenci\u00f3n a la sobrecarga para no sobrecargar el sistema innecesariamente. En el caso de los hosts de contenedores, compruebo adem\u00e1s si los l\u00edmites de los espacios de nombres y los cgroups restringen la visibilidad. Para obtener pruebas de rendimiento reproducibles, documento todos los par\u00e1metros, incluidas las versiones del n\u00facleo y de los controladores. Esta disciplina me ahorra mucho trabajo m\u00e1s adelante <strong>Tiempo<\/strong> a la hora de clasificar los cambios.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpuhotspots_kernel1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interpretaci\u00f3n de los subsistemas: red, memoria y programador<\/h2>\n\n<p>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\u00e1metros son los que <strong>Rendimiento<\/strong>-Modificar el equilibrio de latencia. Cuando observo comportamientos an\u00f3malos en las funciones de memoria, analizo los patrones de asignaci\u00f3n, las p\u00e1ginas enormes (Huge Pages), las estad\u00edsticas de slabs y las tasas de fallos de p\u00e1gina. A menudo relaciono la carga del programador con un n\u00famero excesivo de subprocesos, la falta de afinidad de la CPU o una priorizaci\u00f3n injusta. Para eventos espec\u00edficos del n\u00facleo, adem\u00e1s, establezco puntos de rastreo o utilizo <a href=\"https:\/\/webhosting.de\/es\/bpftrace-detectar-mas-rapidamente-los-problemas-del-servidor-de-alojamiento-y-realizar-un-diagnostico\/\">bpftrace en el alojamiento web<\/a>, para confirmar hip\u00f3tesis. As\u00ed, relaciono la observaci\u00f3n en directo desde \u00abperf top\u00bb con puntos de medici\u00f3n m\u00e1s profundos y llego m\u00e1s r\u00e1pido a la <strong>Causa<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-kernel-hotspots-7894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Requisitos y visibilidad de los s\u00edmbolos<\/h2>\n\n<p>De modo que <strong>perf top<\/strong> Al resolver todos los s\u00edmbolos relevantes del n\u00facleo, presto atenci\u00f3n a dos aspectos: los permisos adecuados y la informaci\u00f3n disponible sobre los s\u00edmbolos. En los sistemas de producci\u00f3n, <em>kernel.perf_event_paranoid<\/em> a menudo se establece en un valor alto. Para obtener una visi\u00f3n detallada del n\u00facleo, reduzco este valor temporalmente o trabajo como usuario \u00abroot\u00bb con los permisos necesarios (CAP_PERFMON\/CAP_SYS_ADMIN). Si las direcciones del n\u00facleo est\u00e1n enmascaradas (<em>kptr_restrict<\/em>), 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\u00f3n de depuraci\u00f3n correspondientes, para que \u00abperf top\u00bb muestre los nombres de las funciones en lugar de los desplazamientos. Esto reduce las conjeturas y acelera la b\u00fasqueda de la causa.<\/p>\n\n<h2>Porcentajes y dificultades del muestreo<\/h2>\n\n<p>Interpreto los porcentajes de la lista como <strong>porcentajes relativos<\/strong> de las muestras medidas, no como una carga de CPU exacta en el dominio del tiempo. Si selecciono varios eventos, puedo <strong>Multiplexaci\u00f3n<\/strong> aplicar: Perf distribuye los contadores a lo largo del tiempo y <em>normalizado<\/em> la visualizaci\u00f3n. Para obtener una imagen clara, primero mido de forma general con ciclos de CPU o instrucciones, y luego a\u00f1ado eventos especiales. Los picos moment\u00e1neos los detecto con una frecuencia m\u00e1s alta (-F) e intervalos m\u00e1s cortos; en sistemas con poca actividad, basta con la frecuencia est\u00e1ndar. Adem\u00e1s, tengo en cuenta que <strong>Ocioso<\/strong>-Las fases y los cambios de frecuencia (turbo, regulador) pueden distorsionar la percepci\u00f3n. Por eso, para realizar mediciones comparativas, unifico los ajustes de cadencia y energ\u00eda.<\/p>\n\n<h2>Los gr\u00e1ficos de llamadas en profundidad<\/h2>\n\n<p>Cuando identifico un punto cr\u00edtico, aumento la precisi\u00f3n del an\u00e1lisis mediante gr\u00e1ficos de llamadas. Con <strong>-g<\/strong> y, con un m\u00e9todo de desenrollado adecuado, consigo la ruta hasta el punto costoso. Los punteros de trama o el desenrollado DWARF me proporcionan pilas estables; cuando est\u00e1 disponible, utilizo el b\u00fafer de retorno asistido por hardware (LBR) para obtener cadenas muy precisas. Aumento los b\u00faferes mmap solo lo necesario para mantener baja la sobrecarga. Si la pila muestra muchas funciones auxiliares, presto atenci\u00f3n a <strong>incluido<\/strong> vs. <strong>exclusivo<\/strong> Costes: lo decisivo es si la funci\u00f3n en s\u00ed misma es costosa o si solo predomina como v\u00eda de tr\u00e1nsito. Esta distinci\u00f3n a menudo me ahorra horas a la hora de investigar las causas.<\/p>\n\n<h2>Trabajar en contenedores y m\u00e1quinas virtuales<\/h2>\n\n<p>En entornos de contenedores, compruebo si mi vista de <strong>cgroups<\/strong> y que los espacios de nombres sean correctos. Centro las mediciones en los PID y las CPU relevantes, para que los \u00abvecinos ruidosos\u00bb no distorsionen el panorama. En el caso de las m\u00e1quinas virtuales, compruebo si la PMU virtual est\u00e1 habilitada; de lo contrario, me faltan eventos de hardware precisos y solo veo se\u00f1ales de software. A menudo reconozco los hosts KVM por los s\u00edmbolos que aparecen alrededor de <em>kvm_vcpu<\/em> o <em>vmx<\/em>\/<em>svm<\/em>. En este tipo de situaciones, separo claramente los an\u00e1lisis del host y del invitado para no confundir causa y efecto.<\/p>\n\n<h2>Patrones reconocibles e hip\u00f3tesis r\u00e1pidas<\/h2>\n\n<p>En el d\u00eda a d\u00eda hay ciertos patrones que han demostrado su eficacia y que compruebo de inmediato:<\/p>\n<ul>\n  <li><strong>Competencia de Lock<\/strong>: Buceo <em>queued_spin_lock_slowpath<\/em> o <em>mutex_spin_on_owner<\/em> En este caso, las estructuras de datos son demasiado generales o las colas de trabajo est\u00e1n demasiado limitadas. Reduzco la contienda mediante el sharding, una granularidad de bloqueo m\u00e1s precisa o la modificaci\u00f3n del tama\u00f1o de los lotes.<\/li>\n  <li><strong>Impresi\u00f3n del planificador<\/strong>: Se acumulan <em>schedule()<\/em>, <em>pick_next_task_fair<\/em> o las rutas de activaci\u00f3n, ajusto el n\u00famero de subprocesos, las afinidades y las prioridades. A menudo basta con \u201ccalmar\u201d los subprocesos \u00abcharlatanes\u00bb o definir correctamente los ajustes de la CPU.<\/li>\n  <li><strong>SoftIRQ de red<\/strong>: Picos en <em>net_rx_action<\/em>, <em>napi_poll<\/em> O bien, las descargas de sumas de comprobaci\u00f3n indican una avalancha de paquetes o una distribuci\u00f3n sub\u00f3ptima de RSS e IRQ. Asigno las IRQ a los n\u00facleos adecuados y ajusto GRO\/TSO para obtener el perfil de rendimiento\/latencia deseado.<\/li>\n  <li><strong>Rutas de almacenamiento<\/strong>: Mucho tiempo en <em>do_page_fault<\/em>, <em>copy_user_*<\/em> O las funciones \u00abSlab\u00bb me permiten comprobar los patrones de asignaci\u00f3n, THP\/Huge Pages y la localidad NUMA. Una asignaci\u00f3n incorrecta supone aqu\u00ed una p\u00e9rdida de muchos ciclos que pasa desapercibida.<\/li>\n  <li><strong>RCU y temporizadores<\/strong>: Dominar <em>rcu_core<\/em> o las llamadas de retorno del temporizador, estoy replante\u00e1ndome las estrategias de sondeo y procesamiento por lotes de mis servicios para que el sistema funcione de forma m\u00e1s fluida.<\/li>\n<\/ul>\n\n<h2>Profundizar en la precisi\u00f3n de las mediciones y la reproducibilidad<\/h2>\n\n<p>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\u00facleos definidos y, opcionalmente, a\u00edslo 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\u00e1s arriesgados, establezco puntos de restauraci\u00f3n y vuelvo a realizar mediciones inmediatamente despu\u00e9s de la intervenci\u00f3n. De este modo, obtengo una <strong>Antes\/Despu\u00e9s<\/strong>-Una historia que a\u00fan puedo entender incluso meses despu\u00e9s.<\/p>\n\n<h2>Consejos pr\u00e1cticos: comandos que utilizo con frecuencia<\/h2>\n\n<p>Dependiendo de la pregunta, utilizo f\u00f3rmulas concisas:<\/p>\n<ul>\n  <li><strong>Ancho de escaneo bajo carga<\/strong>: perf top -e cpu-cycles \u2013kernel \u2013user<br\/>Una visi\u00f3n general r\u00e1pida para saber si es el n\u00facleo o el espacio de usuario el que lleva la voz cantante.<\/li>\n  <li><strong>Enfoque en los procesos con Callgraph<\/strong>: perf top -p PID -g \u2013kernel \u2013user<br\/>Mu\u00e9strame las rutas en tiempo real de la aplicaci\u00f3n en cuesti\u00f3n, sin ruido del sistema.<\/li>\n  <li><strong>Enfoque en la CPU<\/strong>: perf top -C 2-5 -e ciclos de CPU -g<br\/>Ayuda a resolver los puntos cr\u00edticos de NUMA o IRQ cuando solo unos pocos n\u00facleos se \u201csobrecalientan\u201d.<\/li>\n  <li><strong>Sospecha de almacenamiento<\/strong>: perf top -e cache-misses -e cycles -g \u2013kernel<br\/>Muestra las rutas de almacenamiento en relaci\u00f3n con los ciclos.<\/li>\n  <li><strong>Fijar los picos sueltos<\/strong>: perf top -F 999 -I 1000 -e ciclos<br\/>Una frecuencia m\u00e1s alta y unos intervalos de visualizaci\u00f3n m\u00e1s cortos permiten detectar picos breves.<\/li>\n<\/ul>\n\n<h2>Orientaciones interpretativas para subsistemas concretos<\/h2>\n\n<p>En <strong>Red<\/strong> Adem\u00e1s de NAPI y las rutas RX\/TX, tambi\u00e9n analizo los componentes TLS\/cripto, que pueden llegar a predominar cuando hay un gran volumen de handshakes. Compruebo si la t\u00e9cnica \u00abzero-copy\u00bb o la \u00abcoalescing\u00bb se aplican de forma adecuada y si los segmentos grandes (TSO\/GSO) superan mis l\u00edmites de latencia. En el <strong>Memoria<\/strong>-En este \u00e1mbito, me fijo en el THP: \u00bfme ayuda a reducir la carga o los eventos de divisi\u00f3n\/fusi\u00f3n provocan interferencias? En <strong>Almacenamiento<\/strong> lo interpreto <em>blk_mq<\/em>-S\u00edmbolos y rutas io_uring como indicaci\u00f3n de la profundidad de las colas y las estrategias de fusi\u00f3n. En el <strong>programador<\/strong> Vinculo las avalanchas de Wakeup con cadenas Lock o IO y equilibr\u00f3 las rutas mediante contrapresi\u00f3n en lugar de \u201cm\u00e1s subprocesos\u201d.<\/p>\n\n<h2>L\u00edmites de \u00abperf top\u00bb y cu\u00e1ndo cambio de estrategia<\/h2>\n\n<p>Porque <strong>perf top<\/strong> Al tratarse de un m\u00e9todo basado en el muestreo, me resulta m\u00e1s f\u00e1cil interpretar im\u00e1genes promediadas que eventos individuales. Para cadenas de ejecuci\u00f3n deterministas, recurro a Tracepoints, ftrace o eBPF con el fin de demostrar causalidades precisas. Si necesito una cuantificaci\u00f3n exacta (por ejemplo, instrucciones por solicitud), lo combino con <strong>estado perfecto<\/strong> o an\u00e1lisis sin conexi\u00f3n desde \u00abperf record\/report\u00bb. Si me encuentro con pilas poco claras (s\u00edmbolos que faltan, desenrollado err\u00f3neo), lo primero que hago es solucionar el problema de visibilidad; de lo contrario, ser\u00eda como andar a ciegas.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Con <strong>perf top<\/strong> Puedo detectar en tiempo real d\u00f3nde la CPU pierde tiempo en el kernel y qu\u00e9 s\u00edmbolos debo analizar primero. A partir de los porcentajes, los patrones recurrentes y la separaci\u00f3n entre el espacio del kernel y el espacio de usuario, deduzco los siguientes pasos a seguir. A continuaci\u00f3n, sintetizo los resultados con \u00abperf record\/report\u00bb, verifico los cambios bajo carga y documento mi cadena de mediciones. En entornos de alojamiento, este procedimiento resulta especialmente \u00fatil, ya que muchos servicios y contenedores se benefician mutuamente en cuanto las rutas del n\u00facleo funcionan de forma m\u00e1s eficiente. Quien interiorice este proceso ahorra d\u00edas de diagn\u00f3stico y reduce <strong>Latencias<\/strong> y consigue tiempos de respuesta notablemente m\u00e1s estables bajo carga real.<\/p>","protected":false},"excerpt":{"rendered":"<p>perf top Linux muestra en tiempo real los puntos cr\u00edticos de la CPU en el n\u00facleo. De este modo, se consigue un r\u00e1pido perfilado de la CPU y un an\u00e1lisis preciso de los cuellos de botella.<\/p>","protected":false},"author":1,"featured_media":20619,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-20626","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"149","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"perf top","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20619","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20626","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20626"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20626\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20619"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20626"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20626"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20626"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}