{"id":18553,"date":"2026-03-30T15:05:26","date_gmt":"2026-03-30T13:05:26","guid":{"rendered":"https:\/\/webhosting.de\/linux-scheduler-cfs-alternativen-hosting-kernelperf-boost\/"},"modified":"2026-03-30T15:05:26","modified_gmt":"2026-03-30T13:05:26","slug":"linux-scheduler-cfs-alojamiento-alternativo-kernelperf-boost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/linux-scheduler-cfs-alternativen-hosting-kernelperf-boost\/","title":{"rendered":"Programador CFS de Linux: Funcionalidad y alternativas en el alojamiento de servidores"},"content":{"rendered":"<p>El planificador CFS de Linux controla c\u00f3mo los n\u00facleos del servidor asignan su tiempo a los procesos y, por tanto, influye directamente en la latencia, el rendimiento y la equidad en el alojamiento de servidores. En esta gu\u00eda, explico c\u00f3mo funciona, las palancas de ajuste y alternativas \u00fatiles como ULE, BFS y EEVDF para <strong>Alojamiento<\/strong> con <strong>servidores web<\/strong>.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>Equidad<\/strong> y <strong>vruntime<\/strong> determinar qu\u00e9 tarea se queda con la CPU.<\/li>\n  <li><strong>Cgroups<\/strong> regular las cuotas y <strong>cpu.acciones<\/strong> para el aislamiento del cliente.<\/li>\n  <li><strong>Ajuste del n\u00facleo<\/strong> mediante sched_latency_ns y <strong>Granularidad<\/strong>.<\/li>\n  <li><strong>Alternativas<\/strong> como BFS, ULE, EEVDF para las <strong>Cargas de trabajo<\/strong>.<\/li>\n  <li><strong>Pr\u00e1ctica<\/strong>Afinidad del n\u00facleo, planificador de E\/S y <strong>Pruebas<\/strong> combinar.<\/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\/03\/linux-server-cfs-9357.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>C\u00f3mo funciona el SFC en el alojamiento cotidiano<\/h2>\n\n<p>Con el Programador Completamente Justo, un tiempo de ejecuci\u00f3n virtual decide qu\u00e9 tarea es la siguiente en ejecutarse, lo que resulta en un <strong>feria<\/strong> y predecible <strong>Asignaci\u00f3n<\/strong> se crea. Cada tarea recibe tiempo de CPU proporcional al valor nice, de modo que un valor nice bajo recibe m\u00e1s participaciones. En entornos de alojamiento, muchas peticiones web peque\u00f1as, cronjobs y copias de seguridad se reparten la CPU sin que un proceso lo ocupe todo. Las cargas de trabajo interactivas, como las peticiones de NGINX, se benefician de bloques de tiempo cortos y frecuentes, mientras que las tareas por lotes reciben bloques m\u00e1s largos. Esto significa que los tiempos de respuesta siguen siendo fiables para los usuarios, aunque muchos sitios est\u00e9n procesando peticiones en paralelo.<\/p>\n\n<p>Utilizo Cgroups para limitar clientes y servicios, porque cpu.shares y cpu.max garantizan la claridad. <strong>Acciones totales<\/strong> y duro <strong>L\u00edmites<\/strong>. Un valor por defecto de 1024 acciones para \u201cnormal\u201d y 512 para \u201cmenos importante\u201d distribuye los n\u00facleos de forma comprensible. Con cpu.max, por ejemplo, establezco 50ms en un periodo de 100ms, lo que corresponde efectivamente a 50% de cuota de CPU. Esta configuraci\u00f3n ofrece reservas predecibles para alojar cargas de trabajo con cargas variables. Puedo encontrar una explicaci\u00f3n compacta del principio en <a href=\"https:\/\/webhosting.de\/es\/cpu-scheduling-hosting-distribucion-equitativa-servidor-hosting-recursos-optimo\/\">distribuci\u00f3n equitativa de la CPU<\/a>.<\/p>\n\n<h2>La mec\u00e1nica del SFC explicada con claridad<\/h2>\n\n<p>En esencia, CFS gestiona todas las tareas listas para ejecutar en un \u00e1rbol rojo\/negro, ordenadas por <strong>vruntime<\/strong> y con eficiente <strong>Selecci\u00f3n<\/strong> del menor tiempo de ejecuci\u00f3n virtual. Esta tarea se ejecuta a continuaci\u00f3n y aumenta su vruntime en proporci\u00f3n al tiempo de CPU consumido y ponderado mediante el valor nice. Esto crea un equilibrio fluido sin colas duras, que ofrece resultados limpios, especialmente con cargas de trabajo mixtas. En los sistemas multin\u00facleo, el programador mueve las tareas entre las colas de ejecuci\u00f3n, pero presta atenci\u00f3n a la localizaci\u00f3n de la cach\u00e9 mediante la afinidad de n\u00facleos. De este modo, CFS combina el equilibrio de carga con el menor n\u00famero posible de migraciones costosas.<\/p>\n\n<p>Para el ajuste fino, par\u00e1metros como sched_latency_ns y sched_min_granularity_ns fijan el rumbo de la <strong>Latencia<\/strong> y <strong>Rendimiento<\/strong>. Los valores de latencia m\u00e1s peque\u00f1os favorecen los trabajos cortos e interactivos, mientras que los valores m\u00e1s grandes refuerzan los trabajos por lotes. En pruebas con herramientas como stress-ng y fio, compruebo el efecto sobre los tiempos de respuesta y la utilizaci\u00f3n de la CPU. A medida que aumenta el n\u00famero de tareas, tambi\u00e9n lo hace la sobrecarga administrativa del \u00e1rbol, que puede manifestarse en forma de picos de latencia. Sin embargo, las cuotas y l\u00edmites correctamente establecidos mantienen estos efectos bajo control en los entornos de alojamiento.<\/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\/03\/linux_scheduler_cfs_meeting_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Puntos fuertes del SFC en el alojamiento de servidores<\/h2>\n\n<p>La mayor fuerza reside en la <strong>Equidad<\/strong>, de manera uniforme y comprensible <strong>Recursos<\/strong> distribuidos. En los entornos compartidos, esto significa que ning\u00fan cliente desplaza permanentemente a otros, porque las cuotas y los recursos compartidos definen claramente las ponderaciones. Los servicios interactivos reciben tiempos de respuesta r\u00e1pidos, mientras que las copias de seguridad pueden ejecutarse sin prisas. La priorizaci\u00f3n mediante valores agradables completa este cuadro y me deja margen para la coordinaci\u00f3n en funci\u00f3n de la funci\u00f3n de un servicio. El equilibrio de carga entre todos los n\u00facleos me permite hacer un buen uso de la potencia de c\u00e1lculo disponible sin dar demasiado espacio a los momentos Jeff de los hilos individuales.<\/p>\n\n<p>En la pr\u00e1ctica, la fuerza de CFS se hace patente cuando se producen picos en el servidor web y llegan muchas peticiones cortas, ya que CFS asigna franjas horarias frecuentes a este tipo de tareas. Los Cgroups limpios ayudan a establecer l\u00edmites superiores duros por cliente o contenedor. Las mediciones de medias y percentiles muestran tiempos de respuesta fiables, lo que compensa en el d\u00eda a d\u00eda. Este enfoque es especialmente \u00fatil para pilas de aplicaciones con muchos componentes. Aqu\u00ed es precisamente donde la mezcla de equidad predecible y flexibilidad suficiente obtiene una puntuaci\u00f3n muy alta.<\/p>\n\n<h2>L\u00edmites y obst\u00e1culos t\u00edpicos<\/h2>\n\n<p>Con un n\u00famero extremadamente elevado de tareas simult\u00e1neas, la sobrecarga de las operaciones en \u00e1rbol aumenta, lo que no ocurre con <strong>Consejos<\/strong> el <strong>Latencia<\/strong> puede manejar. En configuraciones de alojamiento con muchas peticiones muy cortas, a veces se producen frecuentes cambios de contexto. Este comportamiento de \u201cthrashing\u201d reduce la eficiencia si los valores de granularidad se eligen incorrectamente. Menos trozos de tiempo, pero m\u00e1s largos, pueden ayudar, siempre que se mantenga la interactividad. CFS reacciona sensiblemente a cuotas incorrectas, por lo que compruebo constantemente los l\u00edmites con pruebas de carga.<\/p>\n\n<p>Incluso las cargas de trabajo compatibles con la afinidad sufren si las tareas saltan entre n\u00facleos con demasiada frecuencia. Un concepto de afinidad limpio mantiene las cach\u00e9s calientes y reduce los costes de migraci\u00f3n. Tambi\u00e9n me gusta vincular los trabajos por lotes ruidosos a sus propios n\u00facleos para que las peticiones web se ejecuten silenciosamente en sus n\u00facleos. Para los servicios de latencia cr\u00edtica, merece la pena establecer valores agradables bajos y una latencia bien ajustada. Al final, lo que cuenta es que las mediciones confirmen los par\u00e1metros seleccionados.<\/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\/03\/linux-scheduler-cfs-server-7012.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparaci\u00f3n de alternativas: ULE, BFS y EEVDF<\/h2>\n\n<p>Para cargas de trabajo especiales, busco alternativas con el fin de <strong>Latencia<\/strong> o <strong>Escala<\/strong> priorizan de forma diferente. ULE utiliza colas m\u00e1s sencillas y punt\u00faa con menos esfuerzo administrativo, BFS prioriza la capacidad de respuesta y brilla con pocas tareas, y EEVDF combina la distribuci\u00f3n equitativa con los plazos. EEVDF, en particular, promete tiempos de espera m\u00e1s cortos para las cargas interactivas porque el planificador presta m\u00e1s atenci\u00f3n a la \u201cfecha l\u00edmite m\u00e1s temprana permisible\u201d. Para campos de servidores muy grandes, lo que realmente cuenta al final es qu\u00e9 mezcla de eficiencia y planificabilidad gana realmente en tu propia pila. Una mirada estructurada a los puntos fuertes y d\u00e9biles y a los campos de aplicaci\u00f3n ayuda en la selecci\u00f3n.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>programador<\/th>\n      <th>Complejidad<\/th>\n      <th>Puntos fuertes en alojamiento<\/th>\n      <th>Puntos d\u00e9biles<\/th>\n      <th>Adecuado para<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>SFC<\/strong><\/td>\n      <td>Alta<\/td>\n      <td>Distribuci\u00f3n equitativa, <strong>Cgroups<\/strong><\/td>\n      <td>Picos de latencia<\/td>\n      <td>Alojamiento compartido, cargas mixtas<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>ULE<\/strong><\/td>\n      <td>Bajo<\/td>\n      <td>Se\u00f1ales sencillas, bajo <strong>Carga<\/strong><\/td>\n      <td>Menos aislamiento<\/td>\n      <td>M\u00e1quinas virtuales, modelos HPC<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>BFS<\/strong><\/td>\n      <td>Medio<\/td>\n      <td>Interactividad, <strong>Velocidad<\/strong><\/td>\n      <td>Escalado d\u00e9bil<\/td>\n      <td>Ordenadores de sobremesa, peque\u00f1os servidores<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>EEVDF<\/strong><\/td>\n      <td>Medio<\/td>\n      <td>Baja latencia, <strong>fechas l\u00edmite<\/strong><\/td>\n      <td>Todav\u00eda poca pr\u00e1ctica<\/td>\n      <td>Alojamiento moderno<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Ajuste del n\u00facleo: pasos pr\u00e1cticos para el SFC<\/h2>\n\n<p>Para CFS, suelo cambiar sched_autogroup_enabled=0 para que no haya grupos impl\u00edcitos que distorsionen la imagen y el <strong>Distribuci\u00f3n de la carga<\/strong> borrar <strong>sigue siendo<\/strong>. Con sched_latency_ns me gusta empezar en 20 ms, lo que favorece a los servicios interactivos, y ajustar sched_min_granularity_ns para domar los cambios de contexto. Los valores dependen del perfil: muchas peticiones web cortas necesitan un ajuste distinto que las ventanas de copia de seguridad. Pruebo los cambios en serie y mido los percentiles en lugar de fijarme s\u00f3lo en las medias. Esto garantiza que no s\u00f3lo los valores medios parezcan bonitos, sino tambi\u00e9n que las colas largas se reduzcan.<\/p>\n\n<p>Si quieres profundizar en los par\u00e1metros sysctl, encontrar\u00e1s una buena introducci\u00f3n aqu\u00ed: <a href=\"https:\/\/webhosting.de\/es\/kernel-tuning-linux-sysctl-parameter-serverboost-opti\/\">ajuste de sysctl<\/a>. Tambi\u00e9n ajusto la distribuci\u00f3n de IRQ, el gobernador de CPU y los perfiles de energ\u00eda para que la CPU no se vuelque constantemente hacia estados econ\u00f3micos. Utilizo gobernadores de rendimiento para las pilas basadas en latencia, mientras que las cajas de lotes puros viven con un control equilibrado. Separo claramente las fases de prueba y producci\u00f3n para que no haya sorpresas. Despu\u00e9s de cada paso, compruebo los registros y las m\u00e9tricas antes de seguir adelante.<\/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\/03\/linux_scheduler_cfs_tech_office_5278.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utilizar cgroups y cuotas con sensatez<\/h2>\n\n<p>Con cpu.shares asigno <strong>Pesas<\/strong> mientras cpu.max es duro <strong>L\u00edmites<\/strong> conjuntos. Un cliente con 512 acciones obtiene la mitad de tiempo de computaci\u00f3n que un cliente con 1024, si ambos generan carga al mismo tiempo. Yo uso cpu.max para limitar los picos limpiamente, por ejemplo 50ms en 100ms. Para trabajos dedicados, vale cpuset.cpus para que un servicio use n\u00facleos fijos y la cach\u00e9 se mantenga caliente. En general, esto resulta en una separaci\u00f3n resistente entre clientes y servicios.<\/p>\n\n<p>Documento cada cambio y lo comparo con los niveles de servicio que quiero alcanzar. Sin valores medidos, las cuotas conducen r\u00e1pidamente a interpretaciones err\u00f3neas, por eso siempre acompa\u00f1o los ajustes con pruebas de carga. Para los contenedores, sugiero cuotas realistas que puedan hacer frente a los picos pero que no ralenticen el host. Sigue siendo importante tener un presupuesto de errores predecible para que se detecten picos de latencia notables. Si se hace esto de forma consistente, se evitar\u00e1n sorpresas en las horas punta.<\/p>\n\n<h2>Pr\u00e1ctica: Servidor web y bases de datos en CFS<\/h2>\n\n<p>Los servidores web basados en eventos reducen los cambios de contexto y se armonizan con los CFS, lo que se traduce en una notable constancia. <strong>Tiempos de respuesta<\/strong> y mejor <strong>Escala<\/strong> generado. En las pruebas, veo que NGINX mantiene tasas de petici\u00f3n m\u00e1s altas con menos jitter en el mismo hardware. Las bases de datos reaccionan positivamente a la afinidad de n\u00facleos cuando los trabajos en segundo plano se mantienen alejados de los n\u00facleos calientes. Unas reglas sencillas ayudan: Web en n\u00facleos A-B, batch en C-D y DB en E-F. De esta forma, la pila mantiene el pipeline limpio y las cach\u00e9s calientes.<\/p>\n\n<p>Muchos peque\u00f1os PHP FPM workers causan demasiados cambios con granularidad agresiva. A continuaci\u00f3n, aumento el intervalo de tiempo m\u00ednimo y compruebo si los tiempos de respuesta se mantienen estables. Al mismo tiempo, estrangulo los registros de chat para que la E\/S no se convierta en un freno. El CFS es la base, pero el rendimiento m\u00e1ximo se consigue ajustando toda la pila. De este modo, todos los engranajes encajan sin dejar sin aliento al anfitri\u00f3n.<\/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\/03\/linux_scheduler_server_hosting_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>E\/S de memoria y programaci\u00f3n de la CPU: la interacci\u00f3n<\/h2>\n\n<p>El programador de la CPU y el programador de E\/S se influyen mutuamente, por lo que una configuraci\u00f3n armonizada puede marcar una diferencia notable. <strong>Ventajas<\/strong> en <strong>Latencia<\/strong> trae. Para NVMe suelo usar Noop o mq-deadline, mientras que en HDDs mq-deadline sirve mejor para colas largas. Si la CPU asigna tiempo a tiempo pero la ruta de E\/S se atasca, el efecto global se anula. Por lo tanto, compruebo el programador de E\/S en paralelo con los par\u00e1metros del CFS. Proporciono una visi\u00f3n general de Noop, mq-deadline y BFQ aqu\u00ed: <a href=\"https:\/\/webhosting.de\/es\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/\">Planificador de E\/S en comparaci\u00f3n<\/a>.<\/p>\n\n<p>En el caso de los hosts de bases de datos, ajusto la profundidad de las colas y la lectura anticipada para que las franjas horarias programadas por CFS no se agoten debido al bloqueo de E\/S. Los servidores web con muchos archivos peque\u00f1os se benefician de una baja latencia en la pila de E\/S. En los escenarios de virtualizaci\u00f3n, conf\u00edo en planificadores coherentes en el host y el invitado para evitar patrones impredecibles. As\u00ed es como el planificador de la CPU interact\u00faa con el subsistema de almacenamiento. Al final, lo que cuenta es la cadena coherente desde la petici\u00f3n hasta la respuesta.<\/p>\n\n<h2>Equilibrio SMP, afinidad de n\u00facleos y NUMA<\/h2>\n\n<p>Dirijo los hilos a n\u00facleos fijos para que <strong>Cach\u00e9s<\/strong> costes de calentamiento y migraci\u00f3n <strong>peque\u00f1o<\/strong> permanecen. En los hosts NUMA, la memoria y la CPU van juntas porque los accesos remotos a la memoria aumentan la latencia. CFS equilibra la carga entre las colas de ejecuci\u00f3n, pero las reglas de afinidad deliberadas suelen sacar m\u00e1s partido. Los servicios con acceso frecuente a la cach\u00e9 se benefician de grupos de n\u00facleos estables. A los trabajos por lotes se les permite vagar mientras no interfieran con los n\u00facleos calientes.<\/p>\n\n<p>En la pr\u00e1ctica, configuro las opciones cpuset.cpus y numactl y, a continuaci\u00f3n, pruebo los tiempos de solicitud y las tasas de fallo de la CPU. Cuantas menos migraciones innecesarias se produzcan, mejor ser\u00e1 el tiempo de respuesta. Tambi\u00e9n eval\u00fao la distribuci\u00f3n de interrupciones para que los picos duros de IRQ no atasquen un n\u00facleo. De este modo, consigo una sincronizaci\u00f3n suave de los hilos importantes. Esta calma compensa en el rendimiento general de la pila.<\/p>\n\n<h2>Programaci\u00f3n de grupos: agradable, ponderaci\u00f3n y jerarqu\u00edas<\/h2>\n\n<p>Un escollo frecuente en el alojamiento es la <strong>Interacci\u00f3n<\/strong> entre <strong>agradable<\/strong>-Prioridades y <strong>Pesos del grupo C<\/strong>. CFS primero distribuye equitativamente entre grupos, luego dentro del grupo entre tareas. Esto significa que un proceso con nice -5 a\u00fan puede obtener menos CPU que otro con nice 0 si su grupo (cliente\/contenedor) tiene un peso menor. Por lo tanto, para obtener resultados coherentes, primero establezco el <em>Pesos de grupo<\/em> y utilizar nice s\u00f3lo para el ajuste fino dentro de un servicio.<\/p>\n\n<p>En la pr\u00e1ctica, trabajo con algunos niveles claros (por ejemplo, 512\/1024\/2048 acciones para \u201cbajo\/normal\/alto\u201d) y documento qu\u00e9 servicios se ejecutan en cada grupo. De este modo se mantiene la <strong>Equidad<\/strong> rastreables en la jerarqu\u00eda. Cualquiera que trabaje mucho con procesos de corta duraci\u00f3n (por ejemplo, trabajos CGI\/CLI) tambi\u00e9n se beneficia de <strong>basado en cgroup<\/strong> porque, de lo contrario, las tareas vol\u00e1tiles eludir\u00edan el cors\u00e9 de grupo involuntariamente. Suelo utilizar m\u00e9tricas en tiempo de ejecuci\u00f3n para comprobar si la asignaci\u00f3n interna sigue ajust\u00e1ndose al perfil de carga.<\/p>\n\n<h2>Contenedores y orquestaci\u00f3n: solicitudes, l\u00edmites y estrangulamiento<\/h2>\n\n<p>En entornos de contenedores, una \u201csolicitud\u201d suele corresponder a <strong>peso relativo<\/strong> (acciones\/peso), un \u201cl\u00edmite\u201d en la <strong>Cuota<\/strong> (cpu.max). La interacci\u00f3n decide sobre <strong>Estrangulamiento<\/strong>Si la cuota es demasiado ajustada, la CPU del contenedor se ralentiza dentro del periodo - visible en los rebotes de latencia p95\/p99. Por lo tanto, mantengo las cuotas de tal manera que las r\u00e1fagas normales quepan en el periodo y los servicios rara vez se estrangulen con fuerza. Cuando est\u00e1 disponible, utilizo un <em>R\u00e1faga<\/em>-reserva (por ejemplo, cpu.max.burst) para amortiguar los picos cortos sin distorsiones.<\/p>\n\n<p>Es importante no establecer peticiones demasiado bajas: Si los pesos son demasiado bajos, los servicios interactivos se quedar\u00e1n rezagados frente al ruido de los lotes. Calibro las peticiones en funci\u00f3n de la carga base medida y aseguro los l\u00edmites de modo que <strong>Presupuestos de error<\/strong> se mantienen durante las horas punta. En el caso de los nodos multiinquilino, tambi\u00e9n planifico n\u00facleos de almacenamiento intermedio para que los picos de carga de los contenedores individuales no afecten a los vecinos.<\/p>\n\n<h2>M\u00e9todos de medici\u00f3n y resoluci\u00f3n de problemas en el contexto del programador<\/h2>\n\n<p>Nunca eval\u00fao la sinton\u00eda del SFC a ciegas, sino que la mido de forma dirigida. Yo uso para la visi\u00f3n general:<\/p>\n<ul>\n  <li><strong>Longitud de la cola<\/strong> por CPU (carga frente a n\u00facleos activos),<\/li>\n  <li><strong>Cambio de contexto<\/strong> por segundo y n\u00famero de hilos,<\/li>\n  <li><strong>Robo de CPU<\/strong> y <strong>SoftIRQ<\/strong>-acciones,<\/li>\n  <li><strong>Percentil<\/strong> de los tiempos de respuesta (p50\/p95\/p99),<\/li>\n  <li>Distribuci\u00f3n de <strong>vruntime<\/strong> o latencias de programaci\u00f3n.<\/li>\n<\/ul>\n<p>Si se producen picos de latencia, primero busco <strong>Estrangulamiento<\/strong> (cuota agotada), despu\u00e9s de <strong>Migraciones<\/strong> (cach\u00e9 en fr\u00edo) y finalmente tras <strong>Bloqueos de E\/S<\/strong> (profundidad de la cola, saturaci\u00f3n del almacenamiento). Observo los patrones de activaci\u00f3n: las activaciones breves y frecuentes de muchos trabajadores indican una granularidad demasiado fina o una E\/S parlanchina. Una mayor proporci\u00f3n de ksoftirqd en un n\u00facleo indica colas IRQ calientes - en este caso distribuyo IRQs y activo RPS\/XPS para que la carga de red se distribuya m\u00e1s ampliamente.<\/p>\n\n<h2>Clases en tiempo real, tanteo y control de garrapatas<\/h2>\n\n<p>Adem\u00e1s del SFC, existen las siguientes clases en tiempo real <strong>SCHED_FIFO\/RR<\/strong>. Anulan el CFS: un hilo RT mal configurado puede, literalmente, quitarle el aire al sistema. Por lo tanto, s\u00f3lo asigno RT-Prio de forma muy selectiva (por ejemplo, para audio\/telemetr\u00eda) y defino watchdogs claros. Para el alojamiento, CFS con pesos limpios suele ser suficiente.<\/p>\n\n<p>A <strong>Tanteo y retracto<\/strong>La elecci\u00f3n del modelo de tanteo (por ejemplo, \u201cvoluntario\u201d frente a \u201ctanteo completo\/din\u00e1mico\u201d) modifica la relaci\u00f3n latencia\/rendimiento. Para pilas web prefiero m\u00e1s tanteo, para hosts batch puros menos. Las optimizaciones (<em>nohz<\/em>-) pueden reducir el jitter, pero deben utilizarse con precauci\u00f3n. En n\u00facleos aislados, a veces combino <em>nohz_full<\/em> y Affinity para que los hilos calientes funcionen lo menos perturbados posible - es importante que las cargas del sistema e IRQ no migren inadvertidamente a estos n\u00facleos.<\/p>\n\n<h2>Virtualizaci\u00f3n: KVM, vCPU pinning y tiempo de robo<\/h2>\n\n<p>En el entorno del hipervisor, el programador del host determina cu\u00e1ndo <strong>vCPU<\/strong> puede ejecutar. Crear sobrerreservas <strong>Tiempo de robo<\/strong> en los hu\u00e9spedes, que act\u00faa como \u201clatencia invisible\u201d. Para los inquilinos con latencia cr\u00edtica, anclo las vCPUs a los n\u00facleos f\u00edsicos y mantengo el overcommit moderado. Tambi\u00e9n separo los hilos del emulador (hilos IO, vhost) de los n\u00facleos calientes de los hu\u00e9spedes para que no interfieran entre s\u00ed.<\/p>\n\n<p>Evito el doble estrangulamiento: si el invitado ya est\u00e1 utilizando cpu.max, no establezco cuotas duras adicionales en el host para la misma carga de trabajo. El control de la frecuencia sigue siendo tarea del anfitri\u00f3n; los hu\u00e9spedes se benefician indirectamente si el gobernador del anfitri\u00f3n escala limpiamente con la carga de trabajo real. Para latencias uniformes, considero que la estabilidad m\u00e1s all\u00e1 de la pura frecuencia m\u00e1xima es m\u00e1s importante que el pico de GHz sobre el papel.<\/p>\n\n<h2>AutoNUMA, localizaci\u00f3n de memoria y THP<\/h2>\n\n<p>NUMA puede ser una ganancia de rendimiento o una trampa para el rendimiento. <strong>AutoNUMA<\/strong> a menudo ayuda, pero puede crear una sobrecarga adicional si hay muchos hilos itinerantes. En las pilas de alojamiento con l\u00edmites de servicio claros, yo fijo la CPU y el <strong>Memoria<\/strong> (<em>cpuset.cpus<\/em> y <em>cpuset.mems<\/em>) juntos. Esto significa que los datos calientes permanecen locales y CFS tiene que compensar menos migraciones.<\/p>\n\n<p>P\u00e1ginas grandes (<strong>THP<\/strong>) reducen la presi\u00f3n TLB, pero no se ajustan a todos los perfiles. Para las bases de datos, \u201cmadvise\u201d puede tener m\u00e1s sentido que un \u201csiempre\u201d general. Los fallos de p\u00e1gina que bloquean golpean duramente la latencia interactiva; por lo tanto, planifico los buffers (cach\u00e9 de p\u00e1gina, buffer compartido) para que las ranuras CFS se utilicen de forma productiva y no esperen eventos de E\/S o MMU. Esto puede medirse mediante las tasas de fallos de p\u00e1gina y las curvas de fallos de cach\u00e9.<\/p>\n\n<h2>Ruta de red: control IRQ, RPS\/XPS y sondeo de ocupado<\/h2>\n\n<p>Muchas cargas de trabajo web est\u00e1n dominadas por NIC. Distribuyo <strong>IRQ<\/strong>-colas de la tarjeta de red en varios n\u00facleos y mantenerlas <em>af\u00edn<\/em> a los subprocesos de los trabajadores para que los despertares sigan siendo locales. <strong>RPS\/XPS<\/strong> ayuda a resolver los puntos calientes suaves si las colas RX\/TX individuales est\u00e1n soportando demasiada carga. Si ksoftirqd se calienta visiblemente, es una indicaci\u00f3n de que las SoftIRQs est\u00e1n desbordadas - entonces igualo los flujos y aumento los par\u00e1metros de presupuesto si es necesario sin perder equidad.<\/p>\n\n<p>El sondeo ocupado opcional puede tener sentido en configuraciones muy especiales de baja latencia, pero cuesta tiempo de CPU. Rara vez lo uso y s\u00f3lo si puedo probar por medici\u00f3n que p99 cae significativamente sin estresar el host en general. Normalmente, la afinidad IRQ limpia, los Cgroups y la granularidad CFS proporcionan la mejor relaci\u00f3n coste-beneficio.<\/p>\n\n<h2>Perspectivas: De CFS a EEVDF y enfoques de espacio de usuario<\/h2>\n\n<p>La EEVDF ampl\u00eda la distribuci\u00f3n equitativa para incluir los plazos, lo que es notablemente <strong>m\u00e1s corto<\/strong> y m\u00e1s predecible <strong>Respuestas<\/strong> promesas. Especialmente con objetivos de latencia interactiva, esto puede marcar la diferencia. Yo vigilo de cerca las versiones del n\u00facleo y pruebo EEVDF por separado antes de cambiar. Al mismo tiempo, la programaci\u00f3n del espacio de usuario mediante patrones eBPF est\u00e1 ganando impulso, lo que puede permitir un control adicional en funci\u00f3n de la carga de trabajo. CFS sigue siendo relevante para las infraestructuras de alojamiento, pero EEVDF se establecer\u00e1 r\u00e1pidamente.<\/p>\n\n<p>Sigue siendo importante contar con una ruta de migraci\u00f3n clara: pruebas, despliegue en hosts seleccionados y, a continuaci\u00f3n, expansi\u00f3n. Es la \u00fanica forma de mantener bajo control los percentiles y las tasas de error. Mantengo los puntos de referencia cercanos a la realidad, incluidas las fases de r\u00e1faga y los backends lentos. S\u00f3lo entonces intervengo en entornos vivos. De este modo, se puede progresar sin sorpresas desagradables.<\/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\/03\/linux-scheduler-hosting-4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brevemente resumido<\/h2>\n\n<p>El programador CFS de Linux ofrece una distribuci\u00f3n justa, integraciones s\u00f3lidas y una buena <strong>Controlar<\/strong> a trav\u00e9s de <strong>Cgroups<\/strong>. Con par\u00e1metros sysctl adecuados, afinidad limpia y cuotas realistas, mantengo las latencias bajas y el rendimiento alto. ULE, BFS o EEVDF ofrecen ventajas adicionales para patrones especiales. Mido, comparo y aplico los cambios por etapas para limitar los riesgos. Esto mantiene la previsibilidad del alojamiento y el rendimiento donde debe estar.<\/p>","protected":false},"excerpt":{"rendered":"<p>Explicaci\u00f3n del programador CFS de Linux: C\u00f3mo funciona, servidor de programaci\u00f3n de cpu y alternativas como EEVDF. Ajuste del kernel para un rendimiento \u00f3ptimo del alojamiento.<\/p>","protected":false},"author":1,"featured_media":18546,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-18553","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":"562","_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 CFS","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":"18546","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/18553","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=18553"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/18553\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/18546"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=18553"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=18553"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=18553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}