{"id":20578,"date":"2026-08-12T13:59:33","date_gmt":"2026-08-12T11:59:33","guid":{"rendered":"https:\/\/webhosting.de\/cfs-scheduler-fair-scheduling-hosting\/"},"modified":"2026-08-12T13:59:33","modified_gmt":"2026-08-12T11:59:33","slug":"cfs-scheduler-programacion-equitativa-para-alojamiento-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/cfs-scheduler-fair-scheduling-hosting\/","title":{"rendered":"El programador del n\u00facleo CFS: c\u00f3mo entender la programaci\u00f3n equitativa en servidores de alojamiento"},"content":{"rendered":"<p>Voy a explicar c\u00f3mo funciona el <strong>SFC<\/strong> El programador de tareas de los servidores de alojamiento distribuye de forma equitativa el tiempo de CPU y mantiene los tiempos de respuesta dentro de los plazos previstos. Para ello, voy a mostrar concretamente c\u00f3mo <strong>vruntime<\/strong>, c\u00f3mo interact\u00faan las prioridades y los l\u00edmites del sistema, y qu\u00e9 ajustes son eficaces en entornos productivos.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<p>Para ofrecer una visi\u00f3n general clara, voy a resumir los aspectos m\u00e1s importantes antes de profundizar en el tema. El <strong>Por completo<\/strong> Fair Scheduler distribuye el tiempo de computaci\u00f3n de forma equitativa y prioriza las tareas seg\u00fan sea necesario. En los servidores de alojamiento, influye en la latencia, el rendimiento y la sensaci\u00f3n de estabilidad. Eval\u00fao par\u00e1metros pr\u00e1cticos de ajuste, cargas de trabajo t\u00edpicas y l\u00edmites razonables. Adem\u00e1s, muestro c\u00f3mo combino Cgroups, CPU-Quota y Affinity. De este modo, comprendo las causas de los tiempos de espera y reacciono de forma espec\u00edfica ante <strong>Cambio de contexto<\/strong>.<\/p>\n<p>Los siguientes puntos te ayudar\u00e1n a orientarte r\u00e1pidamente:<\/p>\n<ul>\n  <li><strong>Equidad<\/strong> Antes que el rendimiento m\u00e1ximo: una distribuci\u00f3n equitativa de la CPU en lugar del m\u00e1ximo rendimiento individual.<\/li>\n  <li><strong>vruntime<\/strong> controla el orden: las tareas con prioridad menor se procesan antes.<\/li>\n  <li><strong>Cgroups<\/strong> Presupuestos limitados: los servicios comparten los recursos de forma controlada.<\/li>\n  <li><strong>Latencia<\/strong> y granularidad: ajuste preciso de la respuesta y la eficiencia.<\/li>\n  <li><strong>Prioridad<\/strong> Y lo mejor: la ponderaci\u00f3n determina el orden de ejecuci\u00f3n.<\/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\/serverraum-fair-scheduling-8247.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>C\u00f3mo distribuye de forma equitativa el algoritmo CFS: vruntime, ponderaci\u00f3n y \u00e1rbol rojo-negro<\/h2>\n\n<p>Detr\u00e1s de la equidad se esconde la <strong>vruntime<\/strong>, es decir, un tiempo de ejecuci\u00f3n virtual que registra el consumo de cada tarea de forma ponderada. Cada tarea acumula \u201evruntime\u201c mientras se ejecuta, y la que haya acumulado menos tiene prioridad. El n\u00facleo coloca las tareas ejecutables en un \u00e1rbol rojo-negro y, de este modo, encuentra r\u00e1pidamente la tarea con el menor \u00abatraso\u00bb. As\u00ed me ahorro las franjas de tiempo fijas y reduzco la carga administrativa en la ruta normal. Lo importante sigue siendo la <strong>ponderaci\u00f3n<\/strong>, que ajusto mediante valores \u00abnice\u00bb y con los que controlo con precisi\u00f3n el orden de ejecuci\u00f3n.<\/p>\n\n<p>En los sistemas multin\u00facleo, CFS distribuye las tareas por cola de ejecuci\u00f3n de la CPU y equilibra la carga entre los n\u00facleos. Al hacerlo, observo c\u00f3mo la afinidad y la topolog\u00eda NUMA modifican los tiempos de ejecuci\u00f3n. Si los subprocesos permanecen en un mismo n\u00facleo, reducen las faltas de cach\u00e9 y pierden menos tiempo en la migraci\u00f3n. Si cambio de n\u00facleo con demasiada frecuencia, aumentan los costes derivados de los cambios de contexto y de las cach\u00e9s. Una asignaci\u00f3n adecuada de la CPU supone aqu\u00ed una mejora notable <strong>Acentos<\/strong>.<\/p>\n\n<h2>Equidad frente a rendimiento en los servidores de alojamiento<\/h2>\n\n<p>En los servidores con gran carga de trabajo, los servidores web, las bases de datos y los procesos de trabajo compiten por los mismos n\u00facleos, lo que pone de relieve la importancia de la equidad. El CFS garantiza una distribuci\u00f3n equitativa, pero cuando hay muchas tareas activas puede requerir <strong>Cambio de contexto<\/strong> generar. Si el n\u00famero de procesos en ejecuci\u00f3n aumenta considerablemente, la carga administrativa crece de forma apreciable. Por eso procuro mantener un nivel realista de paralelismo y mantengo el n\u00famero de subprocesos dentro de los l\u00edmites del perfil de E\/S o de CPU. Quien desee evaluar alternativas y complementos, encontrar\u00e1 m\u00e1s informaci\u00f3n en <a href=\"https:\/\/webhosting.de\/es\/linux-scheduler-cfs-alojamiento-alternativo-kernelperf-boost\/\">Alternativas al CFS<\/a>, para contextualizar las decisiones.<\/p>\n\n<p>Distribuir de forma equitativa no significa distribuir de manera ciega y uniforme. Los servicios cr\u00edticos deben responder de forma m\u00e1s fiable que las tareas en segundo plano en las horas punta. Para eso precisamente utilizo prioridades, cuotas y grupos de servicio. De este modo, la respuesta de la <strong>API<\/strong> de forma fluida, mientras que las cargas de trabajo por lotes siguen ejecut\u00e1ndose, aunque a menor rendimiento. Este equilibrio se nota en los hosts productivos <strong>m\u00e1s constante<\/strong>.<\/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\/meeting_scheduler_server_8972.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interacci\u00f3n entre cgroups, la cuota de CPU y la afinidad<\/h2>\n\n<p>Agrupo los servicios por cliente, contenedor o funci\u00f3n en <strong>Cgroups<\/strong>, para que cada grupo disponga de un presupuesto claro. Con las cuotas de CPU y las participaciones de CPU establezco l\u00edmites estrictos o ponderaciones relativas. De este modo evito que un vecino ruidoso sature la m\u00e1quina. Adem\u00e1s, si es necesario, asigno los subprocesos a los n\u00facleos mediante afinidad para aprovechar mejor las cach\u00e9s. Una buena introducci\u00f3n a <a href=\"https:\/\/webhosting.de\/es\/politicas-de-programacion-de-servidores-rendimiento-equitativo-optimizacion-del-alojamiento\/\">Pol\u00edticas de programaci\u00f3n<\/a> ayuda a estructurar las estrategias de forma clara.<\/p>\n\n<p>En el caso de las pilas web, separo el front-end, los trabajadores PHP y la base de datos en grupos con cuotas adecuadas. Los sistemas de cach\u00e9, como Redis o Memcached, reciben recursos de CPU suficientes para gestionar los picos de carga de forma \u00f3ptima. Las copias de seguridad y la compresi\u00f3n se ejecutan en segundo plano con cuotas m\u00e1s reducidas. En los nodos con carga heterog\u00e9nea, establezco cuotas por cliente, de modo que cada uno disponga de un tiempo de procesamiento previsible. Esta claridad facilita <strong>Planificaci\u00f3n de capacidades<\/strong> y reduce las sorpresas.<\/p>\n\n<h2>Par\u00e1metros importantes del n\u00facleo: latencia y granularidad<\/h2>\n\n<p>A la hora de realizar ajustes precisos, recurro sobre todo a los par\u00e1metros relacionados con <strong>Latencia<\/strong> y granularidad. Estos par\u00e1metros determinan la frecuencia con la que cambia el CFS y el tama\u00f1o de los intervalos de tiempo efectivos. Los valores de latencia m\u00e1s bajos mejoran la capacidad de respuesta, pero aumentan la sobrecarga. Los valores m\u00e1s altos ahorran tiempo de gesti\u00f3n, aunque pueden alargar las respuestas individuales. Voy probando diferentes perfiles, mido los resultados y los comparo con los picos de carga antes de planificar los siguientes pasos.<\/p>\n\n<p>La siguiente tabla muestra los conmutadores principales con su efecto y las indicaciones t\u00edpicas para entornos de alojamiento. Los valores son orientativos, no son reglas fijas. Siempre compruebo los cambios mediante pruebas de carga y supervisi\u00f3n. Cada plataforma reacciona de forma ligeramente diferente, sobre todo cuando hay muchos contenedores y m\u00e1quinas virtuales. Precisamente por eso documento meticulosamente los ajustes y los implemento de forma gradual, para <strong>Riesgos<\/strong> para bajar.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e1metros<\/th>\n      <th>Efecto<\/th>\n      <th>Nota sobre el alojamiento web<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>kernel.sched_latency_ns<\/td>\n      <td>Establece la duraci\u00f3n objetivo de un ciclo completo para todas las tareas<\/td>\n      <td>Acortar los valores peque\u00f1os <strong>Reacci\u00f3n<\/strong>, aumentan los costes de planificaci\u00f3n<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_min_granularity_ns<\/td>\n      <td>Tiempo de ejecuci\u00f3n m\u00ednimo por tarea dentro de la latencia<\/td>\n      <td>Un poco mayor en tareas que exigen mucho a la CPU, menor en el \u00abWeb-Mix\u00bb<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_wakeup_granularity_ns<\/td>\n      <td>Umbral a partir del cual las tareas que se est\u00e1n reactivando tienen prioridad<\/td>\n      <td>Cuanto m\u00e1s alta sea, menor ser\u00e1 la frecuencia de preempti\u00f3n; es eficaz contra el thrash.<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_migration_cost_ns<\/td>\n      <td>Coste de la migraci\u00f3n entre n\u00facleos<\/td>\n      <td>El aumento frena la migraci\u00f3n y favorece la cach\u00e9\u2011<strong>Hits<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_cfs_bandwidth_slice_us<\/td>\n      <td>Intervalo de tiempo para el control del ancho de banda de CFS mediante cuotas<\/td>\n      <td>Adaptar a la carga de trabajo y a la periodicidad de las cuotas<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_autogroup_enabled<\/td>\n      <td>Agrupa autom\u00e1ticamente las tareas interactivas<\/td>\n      <td>Realizar pruebas espec\u00edficas en servidores; el efecto depende de la carga<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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\/kernel-scheduler-cfs-hosting-7481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Clasificar correctamente los tipos de carga de trabajo<\/h2>\n\n<p>Distingo entre procesos que consumen muchos recursos de la CPU, que dependen de la memoria y en los que predomina la E\/S <strong>Cargas de trabajo<\/strong>. CFS destaca en tareas de servidor mixtas y en cargas cl\u00e1sicas de la CPU. En patrones que requieren un uso intensivo de la memoria, a menudo es el ancho de banda o la latencia del sistema de memoria lo que limita el rendimiento, y no el programador. En esos casos, resulta m\u00e1s \u00fatil mantener la localidad de la memoria y evitar el intercambio. En escenarios con un alto grado de paralelizaci\u00f3n, compruebo si los subprocesos aprovechan los n\u00facleos de forma adecuada o si se bloquean entre s\u00ed. Si reduzco el paralelismo innecesario, la sobrecarga disminuye y el rendimiento del equipo mejora notablemente. <strong>m\u00e1s l\u00edquido<\/strong>.<\/p>\n\n<p>Para las interfaces web, planifico el n\u00famero de subprocesos ligeramente por encima del n\u00famero de n\u00facleos, ya que muchas solicitudes esperan a la E\/S. Las bases de datos se benefician de un paralelismo bien planificado y de una afinidad adecuada. Agrupo los trabajos por lotes en franjas horarias en las que el tr\u00e1fico de usuarios es escaso. Mantengo las tareas de compresi\u00f3n o transcodificaci\u00f3n que consumen muchos recursos de la CPU en grupos separados, para que la interactividad no se vea afectada. Estos patrones evitan sorpresas y me permiten <strong>Controlar<\/strong> sobre las consecuencias de cada modificaci\u00f3n.<\/p>\n\n<h2>Entender las prioridades, los \u00abnice\u00bb y las ponderaciones<\/h2>\n\n<p>Utilizo valores \u00abnice\u00bb para la <strong>ponderaci\u00f3n<\/strong> establecer la prioridad de un proceso y, con ello, su proporci\u00f3n de tiempo de CPU. Los valores \u00abnice\u00bb m\u00e1s bajos indican mayor importancia, mientras que los valores \u00abnice\u00bb m\u00e1s altos limitan las tareas en segundo plano. De este modo, me aseguro de que los servicios centrales respondan de forma fiable, mientras que las tareas de mantenimiento pasan a un segundo plano. Adem\u00e1s, observo cu\u00e1ntas tareas de cada grupo est\u00e1n activas al mismo tiempo, ya que esto influye a\u00fan m\u00e1s en la distribuci\u00f3n. Una visi\u00f3n general de la clasificaci\u00f3n de las <a href=\"https:\/\/webhosting.de\/es\/servidor-cpu-scheduler-class-scheduling\/\">Clases de programador<\/a> Lo utilizo para diferenciar claramente CFS de las clases en tiempo real.<\/p>\n\n<p>Lo importante es ser coherente: documento las especificaciones y las mantengo iguales en todas las implementaciones. De lo contrario, las ponderaciones diferentes en cada etapa generan efectos dif\u00edciles de explicar. Si presto atenci\u00f3n a la coherencia, encuentro m\u00e1s r\u00e1pidamente las causas de los valores at\u00edpicos. Los pasos peque\u00f1os y comprensibles facilitan dar marcha atr\u00e1s en caso necesario. De este modo, el efecto de <strong>Prioridades<\/strong> transparente.<\/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\/fair_scheduling_server_2390.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Virtualizaci\u00f3n y contenedores: dos niveles de asignaci\u00f3n equitativa<\/h2>\n\n<p>En los hipervisores, las m\u00e1quinas virtuales compiten por las CPU del host, mientras que el CFS coordina los procesos en la instancia invitada. Establezco las vCPU de forma realista, en lugar de hacer promesas vac\u00edas que, ante la presi\u00f3n, <strong>robar<\/strong>. En los contenedores, utilizo las cuotas de CPU y los l\u00edmites de uso para que los picos de tr\u00e1fico de servicios concretos no afecten a todo el nodo. La combinaci\u00f3n de la asignaci\u00f3n de recursos del host y la equidad entre los invitados permite que las latencias sean predecibles. Solo con unos l\u00edmites claros se mantiene una experiencia de usuario agradable y <strong>Fiable<\/strong>.<\/p>\n\n<p>En los sistemas NUMA, tambi\u00e9n tengo en cuenta la localidad de la memoria. Cuando los contenedores se desplazan sin control entre sockets, aumentan las latencias de memoria y se reduce el rendimiento. Por eso, asigno los servicios sensibles a nodos concretos y me aseguro de que la asignaci\u00f3n de memoria sea la adecuada. Esta combinaci\u00f3n reduce los efectos secundarios y favorece unos tiempos de respuesta uniformes. El CFS sigue siendo el elemento central <strong>Instancia<\/strong> por cola de ejecuci\u00f3n de la CPU.<\/p>\n\n<h2>Seguimiento y ajuste gradual en la pr\u00e1ctica<\/h2>\n\n<p>Empiezo con la configuraci\u00f3n predeterminada; solo despu\u00e9s mido y realizo ajustes. Indicadores como la longitud de la cola de ejecuci\u00f3n, la tasa de cambios de contexto, la saturaci\u00f3n de la CPU y los porcentajes por Cgroup muestran d\u00f3nde se producen las fugas de rendimiento. Un elevado n\u00famero de cambios de contexto con una carga moderada de la CPU indica una granularidad excesiva. Las colas de ejecuci\u00f3n largas con latencias elevadas apuntan a un n\u00famero excesivo de subprocesos activos. Al final, lo que cuenta es si las acciones de los usuarios se reflejan m\u00e1s r\u00e1pidamente y si los gr\u00e1ficos muestran los resultados esperados. <strong>Tendencia<\/strong> espect\u00e1culo.<\/p>\n\n<p>Anoto cada ajuste indicando la fecha, el alcance y el objetivo. Las pruebas de carga antes y despu\u00e9s del cambio verifican la idea. Si un enfoque falla, revierto el cambio y pruebo otra combinaci\u00f3n. Conf\u00edo en los entornos de prueba independientes antes de intervenir en los sistemas productivos. Esta disciplina supone un coste m\u00ednimo y supone un gran ahorro m\u00e1s adelante. <strong>Tiempo<\/strong>.<\/p>\n\n<h2>Perfiles de rendimiento para el alojamiento web: escenarios pr\u00e1cticos<\/h2>\n\n<p>En una pila t\u00edpica de WordPress, asigno cuotas claras a Nginx\/Apache, PHP-FPM y Redis, y mantengo el n\u00famero de trabajadores de PHP ligeramente por encima del n\u00famero de n\u00facleos. La base de datos tiene prioridad sobre las exportaciones por lotes, para que el proceso de pago y la b\u00fasqueda sigan funcionando con fluidez. Traslado la transcodificaci\u00f3n de archivos multimedia a franjas horarias \u201etranquilas\u201c o establezco cuotas m\u00e1s estrictas. En los nodos de API, limito m\u00e1s los trabajos en segundo plano para reducir las latencias de cola. En todos los casos, compruebo si la <strong>Tiempo de respuesta<\/strong> m\u00e1s estable y el rendimiento se mantenga constante.<\/p>\n\n<p>En entornos compartidos, indico a los clientes los presupuestos en euros al mes y los traduzco en cuotas de CPU claras. La transparencia evita decepciones y facilita la venta adicional cuando aumentan los picos de carga. Estos datos respaldan estas conversaciones, no las corazonadas. S\u00e9 reconocer cu\u00e1ndo un cliente deber\u00eda aumentar sus vCPU o sus l\u00edmites. De este modo, los servidores se mantienen con una carga de trabajo equilibrada y el rendimiento general resulta <strong>constante<\/strong>.<\/p>\n\n<h2>Decisi\u00f3n de compra y elecci\u00f3n del alojamiento web<\/h2>\n\n<p>A la hora de evaluar ofertas, compruebo si el tiempo de CPU se distribuye de forma equitativa bajo carga y si el aislamiento funciona de manera consistente. Quien compare servicios de alojamiento, servidores o paquetes de WordPress debe fijarse en cuotas claras, Cgroups bien definidos y datos de monitorizaci\u00f3n fiables. Los testimonios y las pruebas de rendimiento muestran c\u00f3mo reaccionan las plataformas en horas punta. En las comparativas, webhoster.de suele aparecer como ganador cuando la equidad en el uso de la CPU y el aislamiento convencen de forma evidente. Lo eval\u00fao con objetividad y me aseguro de que el precio y <strong>Actuaci\u00f3n<\/strong> que se adapten al perfil de las propias cargas de trabajo.<\/p>\n\n<h2>Cgroup v2 en la pr\u00e1ctica: c\u00f3mo utilizar correctamente cpu.max y cpu.weight<\/h2>\n\n<p>En las distribuciones modernas, prefiero utilizar Cgroup v2. All\u00ed ajusto los presupuestos de CPU con <strong>cpu.max<\/strong> y <strong>peso.cpu<\/strong>. Con cpu.max establezco un l\u00edmite de tiempo estricto por periodo (por ejemplo, \u201e50 ms 100 ms\u201c para 50% de una CPU). Si no se introduce el segundo n\u00famero, se aplica el valor predeterminado del sistema. La <strong>ponderaci\u00f3n<\/strong> Lo controlo con cpu.weight (1\u201310000); as\u00ed distribuyo la capacidad restante de forma equitativa cuando hay varios grupos activos. Para cada servicio, documento si necesita l\u00edmites estrictos (por ejemplo, trabajos por lotes que consumen muchos recursos) o si, por el contrario, debe ponderarse de forma relativa (API, bases de datos). Gracias a unas ponderaciones coherentes por rol, los hosts siguen siendo planificables y <strong>justo<\/strong>.<\/p>\n\n<p>Lo importante es el equilibrio entre el peso y la cuota: una cuota muy ajustada protege a los vecinos, pero puede limitar el acceso demasiado pronto en caso de picos breves. Si basta con el peso por s\u00ed solo, dejo la cuota generosa o la elimino por completo. En horas de m\u00e1xima carga, conviene aplicar una ponderaci\u00f3n ligeramente mayor a la interactividad, mientras que el archivado y los informes se gestionan con una ponderaci\u00f3n moderada.<\/p>\n\n<h2>Control de ancho de banda CFS en detalle: per\u00edodo, cuota y limitaci\u00f3n de ancho de banda<\/h2>\n\n<p>El control de ancho de banda CFS limita el tiempo de CPU por Cgroup en un intervalo definido <strong>Per\u00edodo<\/strong>. Normalmente configuro \u00abperiod\u00bb y \u00abquota\u00bb (v1) o \u00abcpu.max\u00bb (v2). Si se agota el presupuesto, <strong>restringe<\/strong> CFS hasta el siguiente periodo. Es precisamente aqu\u00ed donde suelen aparecer picos en la curva de latencia. Evito los bordes bruscos ajustando el periodo y el <strong>Tama\u00f1o de la porci\u00f3n<\/strong> Ajustar (kernel.sched_cfs_bandwidth_slice_us) a la carga de trabajo: las rebanadas m\u00e1s peque\u00f1as distribuyen la ejecuci\u00f3n de forma m\u00e1s precisa, pero aumentan la sobrecarga. En el caso de servicios con picos de tr\u00e1fico muy intensos, elijo un periodo moderado (por ejemplo, entre 50 y 100 ms) y un presupuesto suficiente para que los picos t\u00edpicos de solicitudes se procesen sin limitaci\u00f3n de ancho de banda.<\/p>\n\n<p>Si observo que se producen frecuentes limitaciones de rendimiento a pesar de que la carga total de la CPU es baja, significa que el l\u00edmite es demasiado ajustado. Aumento el presupuesto en funci\u00f3n de la carga de trabajo o opto por una ponderaci\u00f3n en lugar de l\u00edmites estrictos. Si solo se producen cuellos de botella de corta duraci\u00f3n, distribuyo los picos de carga entre varios <strong>Trabajador<\/strong> con una actividad ligeramente escalonada, para que los periodos no se vac\u00eden al mismo tiempo.<\/p>\n\n<h2>Uso adecuado de SMT, afinidad de IRQ y aislamiento de n\u00facleos<\/h2>\n\n<p>En sistemas con <strong>SMT\/Hyper-Threading<\/strong> Tengo en cuenta que dos subprocesos comparten las unidades de ejecuci\u00f3n de un n\u00facleo. Para los front-ends en los que la latencia es cr\u00edtica, prefiero agrupar los subprocesos activos en n\u00facleos f\u00edsicos independientes, mientras que los trabajos en segundo plano ocupan los slots SMT adyacentes. Adem\u00e1s, configuro <strong>Afinidad de IRQ<\/strong> para las tarjetas de red y las colas NVMe a los conjuntos de CPU adecuados. De este modo, los softirqs se asignan cerca de los componentes que los consumen <strong>Hilos de trabajo<\/strong>, aumentan las aciertos de cach\u00e9 y disminuye la fluctuaci\u00f3n.<\/p>\n\n<p>Si necesito un aislamiento estricto, reservo unos pocos n\u00facleos mediante par\u00e1metros del kernel (por ejemplo, n\u00facleos aislados \u201elibres de tareas de mantenimiento\u201c). All\u00ed solo traslado los servicios dedicados y sus interrupciones, y mantengo alejados los hilos del sistema. Al hacerlo, realizo pruebas minuciosas para asegurarme de que los servicios del n\u00facleo no se vean privados de recursos. A menudo, basta con una afinidad clara, sin necesidad de aislamiento total, para lograr tiempos de respuesta estables.<\/p>\n\n<h2>Escalado de frecuencia: regulador y turbo para una latencia constante<\/h2>\n\n<p>El <strong>Frecuencia de la CPU<\/strong> Influye notablemente en las latencias de cola. Con el regulador \u201eschedutil\u201c, la frecuencia de reloj sigue de cerca la visi\u00f3n del programador sobre la carga de trabajo. Sin embargo, para las API en las que la latencia es cr\u00edtica, suelo recurrir al regulador \u201eperformance\u201c o aumento la frecuencia m\u00ednima para que los n\u00facleos no entren en estados P profundos. Utilizo el Turbo Boost de forma selectiva: acelera r\u00e1fagas cortas, pero puede activar el control de temperatura y reducir las frecuencias a continuaci\u00f3n. Mido los tiempos de respuesta con y sin Turbo y tomo una decisi\u00f3n para cada nodo. El objetivo es <strong>Constance<\/strong>, no valores m\u00e1ximos en condiciones de laboratorio.<\/p>\n\n<p>En nodos mixtos, combino lo siguiente: algunos n\u00facleos a una frecuencia fija para la interactividad y el resto de forma din\u00e1mica para el procesamiento por lotes. Es importante mantener una pol\u00edtica energ\u00e9tica coherente en el host, para que las pruebas sean reproducibles y el efecto del ajuste del CFS no quede enmascarado por la l\u00f3gica de ahorro energ\u00e9tico.<\/p>\n\n<h2>Profundizar en el diagn\u00f3stico: puntos de seguimiento, \u00abperf\u00bb y estad\u00edsticas de \u00absched\u00bb<\/h2>\n\n<p>Si los efectos siguen sin estar claros, voy un paso m\u00e1s all\u00e1. Con \u00abperf\u00bb y \u00abTracepoints\u00bb analizo <strong>Despertadores<\/strong>, cambios de contexto y tiempos de espera en la cola de ejecuci\u00f3n. Hallazgos como \u201emuchas preempciones poco despu\u00e9s del despertar\u201c indican que el valor de `wakeup_granularity` es demasiado bajo o que hay un paralelismo excesivo. \/proc\/schedstat y \/proc\/sched_debug muestran los tiempos de ejecuci\u00f3n, las tasas de migraci\u00f3n y la distribuci\u00f3n por CPU. Correlaciono estos valores con las cuotas de los grupos C y las m\u00e9tricas de las aplicaciones hasta que la <strong>Causa<\/strong> de una onda de latencia.<\/p>\n\n<p>El valor a\u00f1adido surge de la comparaci\u00f3n: pruebas iguales antes y despu\u00e9s de un cambio, patrones de carga id\u00e9nticos y intervalos de tiempo fijos. Solo entonces reeval\u00fao los resultados. Si las curvas de medici\u00f3n presentan ruido, reduzco el n\u00famero de variables (por ejemplo, frecuencia fija, n\u00famero constante de subprocesos) antes de ajustar otros par\u00e1metros.<\/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\/kernel_scheduler_cfs_8945.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Una visi\u00f3n general de las E\/S y la red: Softirqs, RPS\/RFS y el programador de bloques<\/h2>\n\n<p>La equidad de la CPU solo funciona si la ruta de datos est\u00e1 a la altura. Ordeno <strong>Softirqs<\/strong> (ksoftirqd) a las CPU de la aplicaci\u00f3n, para que los paquetes y el procesamiento coincidan espacialmente. Con colas de NIC distribuidas y la afinidad adecuada, alivio la carga en los puntos cr\u00edticos. Cuando el rendimiento de la red es elevado, los ajustes de RPS\/RFS y XPS ayudan a distribuir la carga de forma m\u00e1s amplia. En cuanto al almacenamiento, me aseguro de utilizar un programador de E\/S por bloques adecuado y de aplicar el control de E\/S mediante cgroups, para que los procesos con gran demanda de E\/S no reduzcan indirectamente el tiempo de CPU de los dem\u00e1s. De este modo, evito que la equidad a nivel de CPU se vea afectada por <strong>Atrasos<\/strong> se ve contrarrestado en la ruta de E\/S.<\/p>\n\n<p>Para cargas de trabajo con io_uring o con E\/S as\u00edncrona intensiva, asigno conjuntos o grupos de CPU espec\u00edficos para los hilos auxiliares de E\/S, de modo que no compitan por el mismo presupuesto con los hilos de trabajo del front-end.<\/p>\n\n<h2>Antipatrones y gu\u00edas pr\u00e1cticas contrastadas<\/h2>\n\n<p>En la pr\u00e1ctica, me encuentro con patrones recurrentes que arruinan los tiempos de respuesta. Los evito sistem\u00e1ticamente:<\/p>\n<ul>\n  <li>Demasiados <strong>Hilos<\/strong> En el caso de los servicios que dependen de la CPU: me mantengo cerca del n\u00famero de n\u00facleos y escalo horizontalmente, en lugar de iniciar cientos de trabajadores.<\/li>\n  <li>Demasiado estrecho <strong>Probabilidades<\/strong> con un per\u00edodo corto: esto provoca ondas de \u00abthrottle\u00bb. Es mejor: utilizar un poco m\u00e1s de presupuesto o de ponderaci\u00f3n.<\/li>\n  <li>Poco claras <strong>afinidad<\/strong>: Hilos migratorios que sacrifican la localidad de la cach\u00e9. Fijo de forma coherente las rutas calientes y sus interrupciones.<\/li>\n  <li>Mixtos <strong>Etapas<\/strong> con diferentes valores de \u00abnice\u00bb y \u00abpeso\u00bb: da lugar a sorpresas. Armonizo los valores predeterminados.<\/li>\n  <li>Autogroup activado de forma general: en los servidores compruebo su efecto de forma espec\u00edfica; las optimizaciones interactivas del escritorio no siempre son \u00fatiles en el centro de datos.<\/li>\n<\/ul>\n\n<p>Mis gu\u00edas de actuaci\u00f3n son pragm\u00e1ticas: primero se establece la visibilidad (m\u00e9tricas, trazas); despu\u00e9s, se aplican medidas generales (hilos, cgroups); y solo entonces se procede al ajuste fino (latencia, granularidad). Cada cambio es reversible y queda documentado. De este modo, el entorno sigue siendo manejable y <strong>previsible<\/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\/hosting-serverraum-7482.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brevemente resumido<\/h2>\n\n<p>El <strong>SFC<\/strong> El programador distribuye el tiempo de CPU de forma equitativa, mantiene un alto nivel de interactividad y sigue siendo la mejor base de partida para cargas de trabajo mixtas de alojamiento. Son fundamentales establecer l\u00edmites adecuados con Cgroups, un paralelismo realista y prioridades claras. Solo ajusto los valores de latencia y granularidad cuando las mediciones indican un cuello de botella. A continuaci\u00f3n, compruebo el efecto y, si el resultado no es satisfactorio, vuelvo a ajustar los par\u00e1metros. Con este enfoque pragm\u00e1tico, garantizo una <strong>Tiempos de respuesta<\/strong> y capacidades previsibles, sin sobrecargar la m\u00e1quina.<\/p>","protected":false},"excerpt":{"rendered":"<p>Explicaci\u00f3n del CFS Scheduler: programaci\u00f3n equitativa en el n\u00facleo de Linux para servidores de alojamiento, rendimiento y distribuci\u00f3n \u00f3ptima de la CPU.<\/p>","protected":false},"author":1,"featured_media":20571,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20578","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":"92","_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":"CFS 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":"20571","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20578","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=20578"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20578\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20571"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20578"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20578"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20578"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}