{"id":20778,"date":"2026-08-18T18:23:16","date_gmt":"2026-08-18T16:23:16","guid":{"rendered":"https:\/\/webhosting.de\/linux-scheduler-latenz-messen-und-optimieren-performance\/"},"modified":"2026-08-18T18:23:16","modified_gmt":"2026-08-18T16:23:16","slug":"medir-la-latencia-del-programador-de-linux-y-optimizar-el-rendimiento","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/linux-scheduler-latenz-messen-und-optimieren-performance\/","title":{"rendered":"Medir y optimizar la latencia del programador de Linux para mejorar el rendimiento del n\u00facleo"},"content":{"rendered":"<p>Mido la latencia del <strong>Programador de Linux<\/strong> de forma espec\u00edfica, analizo los valores at\u00edpicos y optimizo los par\u00e1metros hasta que las cargas de trabajo interactivas y en tiempo real respondan de forma fiable. De este modo, reduzco sistem\u00e1ticamente la latencia del programador y aumento el <strong>Rendimiento del n\u00facleo<\/strong> sin volar a ciegas.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>M\u00e9todos de medici\u00f3n<\/strong>: \u00abperf sched\u00bb, \u00abeBPF runqlat\u00bb, \u00abschedstat\u00bb y \u00abcyclictest\u00bb ofrecen una visi\u00f3n completa.<\/li>\n  <li><strong>En el peor de los casos<\/strong>: Los valores at\u00edpicos condicionan la experiencia del usuario y los plazos en tiempo real.<\/li>\n  <li><strong>Par\u00e1metros del CFS<\/strong>: \u00absched_latency_ns\u00bb y las ventanas de tiempo determinan los tiempos de respuesta.<\/li>\n  <li><strong>Pol\u00edticas<\/strong>: SCHED_FIFO\/RR\/DEADLINE dan prioridad a los subprocesos cr\u00edticos.<\/li>\n  <li><strong>Aislamiento<\/strong>: La asignaci\u00f3n fija de la CPU y el ajuste de las IRQ estabilizan las latencias.<\/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\/linux-performance-2349.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Qu\u00e9 significa la latencia del programador en el n\u00facleo<\/h2>\n\n<p>Defino la latencia del programador como el tiempo que transcurre entre el <strong>Despertar<\/strong> de una tarea y el momento en el que su c\u00f3digo se ejecuta tras el cambio de contexto. Una interrupci\u00f3n pone fin a una fase de espera de E\/S, el controlador marca el hilo como ejecutable, el programador realiza la selecci\u00f3n e inicia el cambio. En los sistemas interactivos, cada microsegundo cuenta, pero en el d\u00eda a d\u00eda lo que m\u00e1s influye es la <strong>En el peor de los casos<\/strong>-La latencia afecta a la percepci\u00f3n. Unos pocos cientos de milisegundos pueden arruinar el funcionamiento, aunque el valor medio parezca bueno. Precisamente por eso analizo toda la cadena en el n\u00facleo, pero me centro en el tramo comprendido entre el despertar y la entrada en la CPU.<\/p>\n\n<h2>Por qu\u00e9 es importante la latencia en el peor de los casos<\/h2>\n\n<p>No solo tengo en cuenta los valores medios, porque una media baja puede ocultar valores altos <strong>Consejos<\/strong> puede enmascarar. El audio se entrecorta cuando picos excepcionales agotan los b\u00faferes, y las operaciones burs\u00e1tiles pierden sincronizaci\u00f3n cuando se superan los plazos. Tanto para ordenadores de sobremesa como para servidores y aplicaciones en tiempo real, se aplica lo siguiente: unos pocos valores at\u00edpicos marcan la <strong>Capacidad de respuesta<\/strong> m\u00e1s que miles de buenas muestras. Por eso busco distribuciones estrechas y valores de jitter controlados. Solo cuando bajan los valores m\u00e1ximos se consigue un desarrollo fluido y predecible.<\/p>\n\n<h2>Medir la latencia del programador: herramientas y procedimiento<\/h2>\n\n<p>Empiezo con <strong>perfecto<\/strong> y registro los eventos del programador seg\u00fan la carga de trabajo: \u201eperf sched record\u201c recopila datos, \u201eperf sched latency\u201c los clasifica por tarea y \u201eperf sched timehist\u201c muestra los eventos con marcas de tiempo. De este modo, puedo ver el tiempo de espera desde el \u201esched-out\u201c hasta el \u201esched-in\u201c, el retraso entre la activaci\u00f3n y la ejecuci\u00f3n real, as\u00ed como el tiempo de ejecuci\u00f3n puro. Para un an\u00e1lisis detallado de la CPU, lo combino con esta gu\u00eda: <a href=\"https:\/\/webhosting.de\/es\/herramienta-perf-de-linux-analisis-de-cuellos-de-botella-de-la-cpu-optimizacion-carga-del-servidor-perfilado\/\">perf para cuellos de botella de la CPU<\/a>. Esta perspectiva permite detectar los cuellos de botella y determinar si la causa son los conflictos de acceso, las prioridades o los gastos generales.<\/p>\n\n<p>Con eBPF mido los tiempos de espera de ejecuci\u00f3n directamente en la <strong>Runqueue<\/strong>. El habitual \u201erunqlat\u201c genera histogramas en intervalos de nanosegundos, lo que me permite identificar zonas t\u00edpicas y picos excepcionales. Estas distribuciones reaccionan de forma apreciable al aislamiento de la CPU o a los cambios de pol\u00edtica y, por lo tanto, proporcionan pruebas fehacientes para las medidas de optimizaci\u00f3n. Repito las mediciones antes y despu\u00e9s de los cambios hasta que desaparecen los picos. Solo entonces considero que el resultado es satisfactorio.<\/p>\n\n<p>Para tareas individuales, consulto \u201e\/proc\/\/schedstat\u201c y comparo los porcentajes de tiempo de ejecuci\u00f3n de la CPU, <strong>Runqueue<\/strong>-Tiempo de espera y fases de suspensi\u00f3n. Al leer los datos a intervalos, se obtienen valores caracter\u00edsticos como el porcentaje de CPU, el porcentaje de latencia y el porcentaje de suspensi\u00f3n. As\u00ed puedo detectar r\u00e1pidamente si el proceso est\u00e1 compitiendo por tiempo de CPU o si est\u00e1 bloqueado por limitaciones de E\/S. Esta claridad evita optimizaciones err\u00f3neas que se centran en el aspecto equivocado. Como prueba adicional, utilizo cyclictest con alta prioridad para documentar el jitter y los valores m\u00e1ximos.<\/p>\n\n<h2>Leer e interpretar los valores medidos<\/h2>\n\n<p>En primer lugar, eval\u00fao los datos de medici\u00f3n desde un punto de vista cualitativo: \u00bfd\u00f3nde se concentran los tiempos de espera y qu\u00e9 hilos aparecen repetidamente con <strong>Picos<\/strong> . A continuaci\u00f3n, compruebo si se deben a l\u00edmites de la CPU, conflictos de pol\u00edticas o a tormentas de interrupciones. Mantengo el tiempo de muestreo lo suficientemente largo como para captar eventos poco frecuentes, pero lo suficientemente corto como para analizar los cambios de forma aislada. Los valores en el rango de los microsegundos son adecuados para el d\u00eda a d\u00eda, pero las cargas de trabajo en tiempo real exigen en algunos casos m\u00e1rgenes a\u00fan m\u00e1s ajustados. Lo fundamental sigue siendo que la latencia m\u00e1xima disminuya de forma fiable y que la fluctuaci\u00f3n se reduzca.<\/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\/linuxscheduler_9374.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Par\u00e1metros del programador de Linux que influyen en la latencia<\/h2>\n\n<p>En primer lugar, ajusto la latencia objetivo \u201esched_latency_ns\u201c, que determina en qu\u00e9 intervalo de tiempo se ejecutar\u00e1n todas las tareas listas para ejecutarse <strong>CPU<\/strong>-Ver el tiempo. En muchos procesos, el intervalo de tiempo por tarea se reduce; en otros pocos, aumenta, lo que garantiza la equidad, pero puede retrasar los tiempos de respuesta. Para aplicaciones interactivas, lo reduzco moderadamente para favorecer respuestas r\u00e1pidas, aunque vigilo la sobrecarga. El CFS distribuye los tiempos de forma equitativa, pero las cargas de trabajo con subprocesos cr\u00edticos se benefician de unas prioridades claras. Resumo aqu\u00ed los fundamentos de la programaci\u00f3n equitativa en el contexto del alojamiento web: <a href=\"https:\/\/webhosting.de\/es\/cfs-scheduler-programacion-equitativa-para-alojamiento-web\/\">Entender el programador CFS<\/a>.<\/p>\n\n<p>Adem\u00e1s de la latencia y los cuantos, influyen la granularidad de activaci\u00f3n y la l\u00f3gica de migraci\u00f3n en <strong>Consejos<\/strong>. Las migraciones demasiado agresivas destruyen la localidad de la cach\u00e9 y, de forma indirecta, alargan los tiempos de espera. Reduzco los desplazamientos innecesarios, fijo los hilos activos y mantengo los datos cerca de sus n\u00facleos. En entornos NUMA, esto es doblemente importante, ya que las distancias de memoria aumentan las latencias. El objetivo sigue siendo un campo de programaci\u00f3n estable y predecible.<\/p>\n\n<h2>Utilizar de forma inteligente las pol\u00edticas, las prioridades y los plazos<\/h2>\n\n<p>A los hilos cr\u00edticos les doy <strong>SCHED_FIFO<\/strong> o prioridad SCHED_RR, cuando la latencia es m\u00e1s importante que el rendimiento. Con SCHED_DEADLINE puedo asignar recursos con precisi\u00f3n en funci\u00f3n de per\u00edodos, tiempo de ejecuci\u00f3n y plazos, lo que garantiza el cumplimiento de los plazos estrictos. Utilizo estas pol\u00edticas con moderaci\u00f3n para que el sistema no se quede sin recursos. Calibro las prioridades hasta que solo pasen las rutas realmente esenciales. Aqu\u00ed encontrar\u00e1s una introducci\u00f3n pr\u00e1ctica a las prioridades: <a href=\"https:\/\/webhosting.de\/es\/servidor-programacion-de-procesos-prioridades-optimizacion-serverboost\/\">Prioridades del proceso<\/a>.<\/p>\n\n<p>Compruebo peri\u00f3dicamente si se producen conflictos entre pol\u00edticas, por ejemplo, cuando las tareas en segundo plano consumen m\u00e1s <strong>Prio<\/strong> que se reciben como hilos de interacci\u00f3n. Los par\u00e1metros de plazo tambi\u00e9n deben dimensionarse adecuadamente; de lo contrario, se producir\u00e1n nuevos atascos. Las pruebas con cargas de trabajo reales garantizan la elecci\u00f3n correcta. Documento cada cambio y realizo mediciones de seguimiento para que los efectos sean trazables. De este modo, evito efectos secundarios durante el funcionamiento.<\/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\/LinuxSchedulerOptimierung4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aislamiento de la CPU, \u00abpinning\u00bb y NUMA: estabilizar las latencias<\/h2>\n\n<p>Separo los hilos cr\u00edticos de la carga general aislando las CPU dedicadas y manteniendo alejados los servicios del sistema, donde la baja <strong>Latencia<\/strong> es necesario. El \u00abCPU-Pinning\u00bb mantiene las rutas m\u00e1s transitadas en n\u00facleos fijos y protege la localidad de la cach\u00e9. En configuraciones NUMA, asigno los hilos a bancos de memoria locales para evitar accesos innecesarios entre nodos. Estas medidas reducen notablemente los efectos de fluctuaci\u00f3n. La mejora se aprecia de inmediato en histogramas eBPF m\u00e1s estrechos.<\/p>\n\n<p>La distribuci\u00f3n de las IRQ forma parte de ello: desv\u00edo las interrupciones molestas de los n\u00facleos de latencia y, de este modo, aligero la carga <strong>Caliente<\/strong>-Hilos. MSI-X y las afinidades ayudan a ajustar con precisi\u00f3n la distribuci\u00f3n. Siempre que es posible, utilizo IRQ multihilo para que las ISR cedan el control m\u00e1s r\u00e1pidamente. Todo ello deja margen para la ejecuci\u00f3n en la que el tiempo es un factor cr\u00edtico. Las mediciones con \u00abperf\u00bb y \u00abcyclictest\u00bb confirman este efecto.<\/p>\n\n<h2>Optimizar las interrupciones, los controladores y la preeminencia<\/h2>\n\n<p>Traslado las partes que requieren un mayor esfuerzo de c\u00e1lculo del ISR a colas de trabajo posteriores, para que el programador funcione m\u00e1s r\u00e1pido <strong>cambiar<\/strong> puedo. Desgloso los tramos cr\u00edticos m\u00e1s largos del n\u00facleo para que se generen puntos de preempci\u00f3n con mayor frecuencia. Desactivo las funciones innecesarias del n\u00facleo y los controladores pesados cuando aumentan las latencias. Para aplicaciones en tiempo real estricto utilizo PREEMPT_RT; para cargas de servidor generalizadas, a menudo basta con PREEMPT si se configura adecuadamente. Lo importante es medir con precisi\u00f3n cada ajuste, en lugar de basarse en suposiciones.<\/p>\n\n<p>Compruebo si las resoluciones del temporizador y las opciones de tick se adaptan a la carga de trabajo, ya que los ticks poco precisos <strong>Jitter<\/strong> pueden potenciarse. A esto se suma la gesti\u00f3n de la energ\u00eda: los estados C profundos alargan los tiempos de reactivaci\u00f3n y pueden provocar picos de latencia. Con unos ajustes optimizados del regulador, consigo un equilibrio viable. Al final, lo que cuenta es la consistencia de los valores medidos, no el nombre de una opci\u00f3n. Es mejor optar por un enfoque estable que por ajustes individuales agresivos.<\/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_scheduler_performance1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pasos pr\u00e1cticos para el ajuste con valores de ejemplo<\/h2>\n\n<p>Empiezo con una medici\u00f3n de referencia y solo cambio un <strong>Par\u00e1metros<\/strong> por ronda, para registrar la causalidad. A continuaci\u00f3n, var\u00edo el valor de `sched_latency_ns` en peque\u00f1os incrementos, observo los valores m\u00e1ximos y el jitter, y documento los efectos. Si es necesario, fijo los hilos cr\u00edticos y reubico las IRQ, vuelvo a realizar mediciones y registro los picos. Cuando las pol\u00edticas lo permiten, cambio de forma selectiva a FIFO\/RR o DEADLINE. La siguiente tabla compara las opciones m\u00e1s habituales con sus efectos y efectos secundarios:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Opci\u00f3n\/Mec\u00e1nica<\/th>\n      <th>Efecto previsto sobre la latencia<\/th>\n      <th>Posibles efectos secundarios<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>sched_latency_ns<\/strong> bajar<\/td>\n      <td>Menor tiempo de espera hasta la CPU<\/td>\n      <td>Mayor sobrecarga de programaci\u00f3n<\/td>\n      <td>Peque\u00f1os pasos, medir el impacto<\/td>\n    <\/tr>\n    <tr>\n      <td>Ajustar la granularidad de la activaci\u00f3n<\/td>\n      <td>Recuperaci\u00f3n m\u00e1s r\u00e1pida tras el despertar<\/td>\n      <td>Preemptiones m\u00e1s frecuentes<\/td>\n      <td>Ajustar solo ligeramente<\/td>\n    <\/tr>\n    <tr>\n      <td>Fijaci\u00f3n\/aislamiento de la CPU<\/td>\n      <td>M\u00e1s estables <strong>Picos<\/strong> y menos fluctuaciones<\/td>\n      <td>Menor flexibilidad<\/td>\n      <td>Tener en cuenta las afinidades de IRQ<\/td>\n    <\/tr>\n    <tr>\n      <td>SCHED_FIFO\/RR<\/td>\n      <td>Dise\u00f1o preferido<\/td>\n      <td>Desplazamiento de otras tareas<\/td>\n      <td>Solo para rutas cr\u00edticas<\/td>\n    <\/tr>\n    <tr>\n      <td>PREEMPT_RT<\/td>\n      <td>Baja latencia en el peor de los casos<\/td>\n      <td>M\u00e1s cambios de contexto<\/td>\n      <td>Se necesitan controladores compatibles con RT<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Valido los cambios con \u00abperf timehist\u00bb y los histogramas de eBPF hasta que la <strong>Distribuci\u00f3n<\/strong> y el valor m\u00e1ximo se mantenga conservador. Si los efectos son contrarios, doy un paso atr\u00e1s y pruebo una combinaci\u00f3n alternativa. Cada entorno reacciona de forma ligeramente diferente, por lo que es importante experimentar con cuidado. Con pruebas de rendimiento consistentes, demuestro objetivamente los beneficios. As\u00ed se crea un proceso de ajuste repetible.<\/p>\n\n<h2>Contexto de alojamiento y servidores: c\u00f3mo reducir eficazmente la latencia<\/h2>\n\n<p>En el \u00e1mbito del alojamiento web, un ajuste preciso del programador reduce los tiempos de respuesta de las p\u00e1ginas web y <strong>DB<\/strong>-Solicitudes. Muchos procesos simult\u00e1neos se benefician cuando se reducen los tiempos de espera en la cola de ejecuci\u00f3n y desaparecen los picos de carga. Las pilas de contenedores y microservicios ganan en uniformidad en cuanto los servicios cr\u00edticos reciben prioridad y se les asigna una ubicaci\u00f3n cercana a la CPU. A la hora de seleccionar un proveedor, hay que prestar atenci\u00f3n a que cuente con kernels actualizados, una preeminencia adecuada y un control flexible de las IRQ y la CPU. Una menor latencia repercute directamente en la facturaci\u00f3n y en la experiencia del usuario.<\/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-performance-optimierung-4523.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Funciones modernas del n\u00facleo que influyen en la latencia<\/h2>\n\n<p>Los kernels actuales incorporan mecanismos que influyen directamente en los tiempos de respuesta. En las versiones m\u00e1s recientes, el CFS ha incorporado heur\u00edsticas m\u00e1s refinadas para las activaciones y los desplazamientos, que dan prioridad a las cargas interactivas. Atributos como un <strong>Preferencia de vigilia-latencia<\/strong> por hilo, ayuda a que las rutas importantes se ejecuten m\u00e1s r\u00e1pido sin abusar de las pol\u00edticas de RT. Adem\u00e1s, controla <strong>uclamp<\/strong> (limitaci\u00f3n de utilizaci\u00f3n) la utilizaci\u00f3n m\u00ednima y m\u00e1xima de la CPU, tal y como la establece el planificador, por tarea o cgroup. De este modo, impongo un l\u00edmite m\u00ednimo de potencia de c\u00e1lculo para los hilos en los que la latencia es cr\u00edtica, lo que influye en el regulador de frecuencia y en la asignaci\u00f3n a los n\u00facleos activos.<\/p>\n\n<p>Para los sistemas con pocos ticks, utilizo <strong>NOHZ_FULL<\/strong> en combinaci\u00f3n con CPU dedicadas a tareas de mantenimiento. Esto desv\u00eda las tareas peri\u00f3dicas del n\u00facleo de los n\u00facleos con latencia. Adem\u00e1s, alivio la carga de estos n\u00facleos mediante <code>rcu_nocbs<\/code>, para que las llamadas de retorno no les desestabilicen. Ambas medidas reducen las preemptiones en el momento menos oportuno y estabilizan los valores en el peor de los casos.<\/p>\n\n<p>Con <strong>PSI<\/strong> (Informaci\u00f3n sobre el bloqueo por presi\u00f3n) Mido la presi\u00f3n del sistema en la CPU, la memoria y las E\/S. Los indicadores en <code>\/proc\/pressure\/*<\/code> muestran si hay subprocesos bloqueados por falta de recursos. Si el PSI de la CPU aumenta al mismo tiempo que los tiempos de espera de la cola de ejecuci\u00f3n, esto es un claro indicio de una sobrecarga real o de un control de cuotas demasiado estricto.<\/p>\n\n<h2>Cgroups, contenedores y equidad: aislamiento sin sobrecarga<\/h2>\n\n<p>En entornos de contenedores, los cgroups son la clave para conseguir una latencia predecible. Yo utilizo <strong>peso.cpu<\/strong>, para regular la equidad relativa, y utilizo <strong>cpu.max<\/strong>, para limitar estrictamente los servicios en segundo plano que causan interferencias. A los servicios cr\u00edticos no se les asigna una cuota de CPU tan restrictiva, para que no <em>limitar<\/em> y se fragmentan en el tiempo. Para garantizar la proximidad a la CPU, separo los cpusets: un conjunto de n\u00facleos para la interacci\u00f3n y otro para el procesamiento por lotes. Este aislamiento tiene un efecto mayor que el simple ajuste del nivel \u00abnice\u00bb.<\/p>\n\n<p>En las plataformas con orquestaci\u00f3n, evito que varios pods con requisitos cr\u00edticos de latencia compartan el mismo n\u00facleo f\u00edsico. Reservo n\u00facleos <em>exclusivo<\/em> y asigno las IRQ correspondientes de forma coherente. Mido los cambios en la jerarqu\u00eda de cgroups con eBPF mediante filtros de cgroup, para poder ver los tiempos de espera en la cola de ejecuci\u00f3n de cada servicio. As\u00ed puedo determinar si la distribuci\u00f3n de la carga o las cuotas son la causa real de los picos.<\/p>\n\n<h2>Virtualizaci\u00f3n y SMT: detecci\u00f3n y atenuaci\u00f3n del ruido del host<\/h2>\n\n<p>En las m\u00e1quinas virtuales, presto atenci\u00f3n a <strong>Robar tiempo<\/strong>: Muestra cu\u00e1ndo el hipervisor resta tiempo de CPU al sistema invitado. Si perf detecta rutas adecuadas, pero la aplicaci\u00f3n va a tirones, a menudo el culpable es el \u00absteal time\u00bb. La soluci\u00f3n es <em>Asignaci\u00f3n fija de vCPU<\/em> en pCPU dedicadas, tasas de sobreasignaci\u00f3n reducidas y la separaci\u00f3n de los subprocesos de E\/S en n\u00facleos propios. Para mantener una latencia constante, tengo previsto que pCPU = vCPU; de lo contrario, el peor de los casos es pr\u00e1cticamente imposible de calcular.<\/p>\n\n<p>Con <strong>SMT<\/strong> (Hyper-Threading) comparto la configuraci\u00f3n de n\u00facleos con un n\u00facleo hermano. Por eso, dirijo las rutas de latencia hacia n\u00facleos cuyos hermanos est\u00e9n libres, o utilizo opciones de programaci\u00f3n de n\u00facleos que limitan las interferencias entre n\u00facleos. Cuando los objetivos son muy exigentes, desactivo SMT de forma selectiva para los n\u00facleos cr\u00edticos. La mejora se consigue gracias a una menor competencia en los puertos, las cach\u00e9s y las unidades de ejecuci\u00f3n.<\/p>\n\n<h2>Rutas de almacenamiento, E\/S y red: fuentes ocultas de latencia<\/h2>\n\n<p>La latencia del programador suele parecer un problema de la CPU, pero en realidad es <strong>Reclaim<\/strong> o <strong>Compactaci\u00f3n<\/strong>. La recuperaci\u00f3n directa detiene los subprocesos y genera picos prolongados. Mantengo los pools de p\u00e1ginas libres a un nivel lo suficientemente alto y elijo una <code>vm.swappiness<\/code>, para que los accesos a la memoria no se vean afectados por intercambios intensos. Calibro las \u00abTransparent Huge Pages\u00bb de forma conservadora: si el n\u00facleo colapsa las p\u00e1ginas grandes en un momento inoportuno, se producen pausas; con <em>madvise<\/em> Coloco los THP all\u00ed donde aportan rendimiento sin interferir en la interacci\u00f3n.<\/p>\n\n<p>Los intervalos de reescritura y de confirmaci\u00f3n del diario tambi\u00e9n influyen en las interacciones. Un l\u00edmite de datos sucios demasiado grande desplaza el trabajo a fases desfavorables; uno demasiado peque\u00f1o obliga a picos frecuentes de vaciado. Yo lo dimensiono en bytes en lugar de en porcentajes y distribuyo las escrituras, de modo que las fases de espera de la CPU no coincidan con los picos de E\/S.<\/p>\n\n<p>En la ruta de red, miro <strong>SoftIRQs<\/strong>, presupuestos NAPI y agrupaci\u00f3n de paquetes. Un GRO demasiado agresivo reduce la sobrecarga por paquete, pero puede alargar la latencia interactiva. Los RPS\/RFS distribuyen bien la carga, pero deben ajustarse a las afinidades de IRQ y CPU. El objetivo es que los paquetes se procesen all\u00ed donde se ejecuta el hilo de la aplicaci\u00f3n, y no tengan que recorrer primero varios n\u00facleos.<\/p>\n\n<h2>Equilibrar la limitaci\u00f3n de RT, los plazos y los mecanismos de protecci\u00f3n<\/h2>\n\n<p>El <strong>Limitaci\u00f3n de RT<\/strong> protege al sistema contra el \u00abhunger\u00bb, pero limita de forma efectiva la carga de RT a una parte del tiempo de CPU. Para obtener tiempos de respuesta deterministas, aumento <code>kernel.sched_rt_runtime_us<\/code> o desactivar el l\u00edmite en entornos cuidadosamente aislados. A continuaci\u00f3n, compruebo sistem\u00e1ticamente si los hilos que no son de RT siguen recibiendo suficientes ventanas. Igualmente importantes son las variables globales <strong>Fecha l\u00edmite<\/strong>-Cuotas: si se establecen con un margen demasiado ajustado, las tareas de DEADLINE no caben en sus ventanas a pesar de que los par\u00e1metros sean correctos. Compruebo la relaci\u00f3n entre <em>tiempo de ejecuci\u00f3n<\/em> a <em>per\u00edodo<\/em> y la suma de todas las reservas de DEADLINE por cada CPU.<\/p>\n\n<h2>Dise\u00f1o de la medici\u00f3n, protecci\u00f3n contra la regresi\u00f3n y funcionamiento<\/h2>\n\n<p>Separo estrictamente las fases de medici\u00f3n: calentamiento, referencia, variaci\u00f3n y verificaci\u00f3n. Las cach\u00e9s fr\u00edas falsean los resultados; mido las fases estabilizadas y las correlaciono con los datos de rendimiento y eBPF. Las comparaciones A\/B se realizan con cargas de trabajo id\u00e9nticas, la misma duraci\u00f3n y afinidades fijas. Elijo ventanas de muestreo lo suficientemente amplias como para que los picos poco frecuentes aparezcan estad\u00edsticamente, pero lo suficientemente peque\u00f1as como para evaluar de forma aislada cada paso de ajuste.<\/p>\n\n<p>Para el funcionamiento continuo, defino una <strong>SLO<\/strong> Para la latencia y la fluctuaci\u00f3n: aproximadamente el cuant\u00edl 99,9% por debajo de X microsegundos con una carga Y. La telemetr\u00eda procedente de PSI, las estad\u00edsticas de rendimiento y los histogramas eBPF sirven como sistema de vigilancia; si las m\u00e9tricas superan los umbrales, vuelvo a cambiar autom\u00e1ticamente a perfiles conservadores. Cada cambio se registra en un registro de cambios con la versi\u00f3n del n\u00facleo, los par\u00e1metros, los m\u00e9todos de medici\u00f3n, los datos brutos y la interpretaci\u00f3n. De este modo, el ajuste sigue siendo reproducible y es posible revertirlo en cualquier momento.<\/p>\n\n<ul>\n  <li>Crear una l\u00ednea de referencia: perf, eBPF, schedstat, cyclictest<\/li>\n  <li>Identificar el cuello de botella: CPU, IRQ, E\/S, memoria, pol\u00edtica<\/li>\n  <li>Un cambio por ronda: par\u00e1metros, fijaci\u00f3n, pol\u00edtica, aislamiento<\/li>\n  <li>Medici\u00f3n previa\/posterior: valor medio, cuantiles 99% y 99,9%, m\u00e1ximo<\/li>\n  <li>Pruebas de estabilidad: sesiones prolongadas, cargas de trabajo reales, picos de carga<\/li>\n  <li>Documentar y conservar: perfiles, valores l\u00edmite, plan de actuaci\u00f3n en caso de reincidencia<\/li>\n<\/ul>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Mido la latencia del programador con <strong>perfecto<\/strong>, eBPF, schedstat y cyclictest, antes de tocar nada. A continuaci\u00f3n, reduzco con cuidado la latencia objetivo, calibro las pol\u00edticas y a\u00edslo los subprocesos cr\u00edticos mediante pinning y afinidades de IRQ. Determino los controladores, la distribuci\u00f3n de las ISR y la preempci\u00f3n de tal manera que se reduzcan los picos en el peor de los casos y se minimice la fluctuaci\u00f3n. Justifico cada cambio con mediciones repetidas hasta que las curvas sean convincentes. As\u00ed es como aumento la <strong>N\u00facleo<\/strong>-Ofrece una capacidad de respuesta sostenible y proporciona resultados fiables para ordenadores de sobremesa, servidores y cargas de trabajo en tiempo real.<\/p>","protected":false},"excerpt":{"rendered":"<p>Gu\u00eda pr\u00e1ctica sobre c\u00f3mo medir y optimizar la latencia del programador de Linux para mejorar el rendimiento del n\u00facleo. Enfoque: la latencia del programador en Linux para una programaci\u00f3n precisa de la CPU y unos tiempos de respuesta estables del servidor.<\/p>","protected":false},"author":1,"featured_media":20771,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20778","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"179","_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":"Linux Scheduler","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":"20771","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20778","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=20778"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20778\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20771"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20778"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20778"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20778"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}