{"id":16149,"date":"2025-12-23T11:53:06","date_gmt":"2025-12-23T10:53:06","guid":{"rendered":"https:\/\/webhosting.de\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/"},"modified":"2025-12-23T11:53:06","modified_gmt":"2025-12-23T10:53:06","slug":"io-scheduler-linux-noop-mq-deadline-bfq-serverboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/","title":{"rendered":"Programador de E\/S Linux: Noop, mq-deadline y BFQ explicados en el alojamiento web"},"content":{"rendered":"<p>El programador de E\/S de Linux decide c\u00f3mo el sistema clasifica y prioriza los accesos de lectura y escritura a SSD, NVMe y HDD, y c\u00f3mo los env\u00eda al dispositivo. En esta gu\u00eda explico de forma pr\u00e1ctica cu\u00e1ndo <strong>Noop<\/strong>, <strong>mq-fecha l\u00edmite<\/strong> y <strong>BFQ<\/strong> son la mejor opci\u00f3n para el alojamiento, incluyendo ajustes, pruebas y pasos claros a seguir.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>Noop<\/strong>: Sobrecarga m\u00ednima en SSD\/NVMe y en m\u00e1quinas virtuales.<\/li>\n  <li><strong>mq-fecha l\u00edmite<\/strong>: Latencia y rendimiento equilibrados para servidores<\/li>\n  <li><strong>BFQ<\/strong>: Equidad y respuesta r\u00e1pida en entornos multiusuario<\/li>\n  <li><strong>blk-mq<\/strong>: Dise\u00f1o multicolumna para hardware moderno<\/li>\n  <li><strong>Sintonizaci\u00f3n<\/strong>: Pruebas por carga de trabajo en lugar de reglas fijas<\/li>\n<\/ul>\n\n<h2>C\u00f3mo funciona el programador de E\/S en el alojamiento Linux<\/h2>\n\n<p>Un programador de E\/S de Linux ordena las solicitudes de E\/S en colas, realiza fusiones y decide la entrega al dispositivo para <strong>Latencia<\/strong> y aumentar el rendimiento. Los n\u00facleos modernos utilizan blk-mq, es decir, multi-cola, para que varios n\u00facleos de CPU puedan iniciar E\/S en paralelo. Esto encaja con los SSD NVMe, que ofrecen muchas colas y un alto grado de paralelismo, lo que reduce las colas de espera. En el alojamiento, a menudo se producen cargas mixtas amplias: los servidores web proporcionan muchas lecturas peque\u00f1as, las bases de datos generan escrituras sincronizadas y las copias de seguridad generan flujos. El programador adecuado reduce los atascos, mantiene estables los tiempos de respuesta y protege la <strong>Servidor<\/strong>-Experiencia bajo carga.<\/p>\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\/2025\/12\/linux-io-scheduler-hosting-8391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>blk-mq en la pr\u00e1ctica: none vs. noop y valores predeterminados del kernel<\/h2>\n\n<p>Desde el kernel 5.x, el dise\u00f1o multicoloca es la ruta est\u00e1ndar. En este caso, <strong>ninguno<\/strong> el equivalente \u201eNoop\u201c para blk-mq, mientras que <strong>noop<\/strong> proviene hist\u00f3ricamente de la ruta de cola \u00fanica. En los dispositivos NVMe, normalmente solo <code>ninguno<\/code> disponible; en SATA\/SAS se ve a menudo <code>mq-fecha l\u00edmite<\/code>, opcional <code>bfq<\/code> y, dependiendo de la distribuci\u00f3n, tambi\u00e9n <code>kyber<\/code>. Los valores predeterminados var\u00edan: NVMe suele iniciarse con <code>ninguno<\/code>, SCSI\/SATA a menudo con <code>mq-fecha l\u00edmite<\/code>. Por lo tanto, siempre compruebo las opciones disponibles a trav\u00e9s de <code>cat \/sys\/block\/\/queue\/scheduler<\/code> y decide por dispositivo. \u00bfD\u00f3nde solo? <code>ninguno<\/code> es seleccionable, es intencionado: una clasificaci\u00f3n adicional no aporta pr\u00e1cticamente ning\u00fan valor a\u00f1adido.<\/p>\n\n<h2>Noop en el uso de servidores: cu\u00e1ndo gana el minimalismo<\/h2>\n\n<p>Noop realiza principalmente la fusi\u00f3n de bloques adyacentes, pero no los ordena, lo que reduce considerablemente la sobrecarga de la CPU. <strong>bajo<\/strong> En SSD y NVMe, los controladores y el firmware se encargan de la secuencia inteligente, por lo que la clasificaci\u00f3n adicional en el n\u00facleo apenas aporta beneficios. En m\u00e1quinas virtuales y contenedores, suelo planificar Noop, ya que el hipervisor planifica de todos modos de forma global. En discos giratorios, prescindo de Noop, ya que la falta de clasificaci\u00f3n aumenta los tiempos de b\u00fasqueda. Si se quiere delimitar con seguridad el contexto del hardware, hay que fijarse primero en el tipo de memoria; aqu\u00ed es \u00fatil echar un vistazo a <a href=\"https:\/\/webhosting.de\/es\/nvme-ssd-hdd-alojamiento-web-comparacion-rendimiento-costes-consejos-servidor-profesional\/\">NVMe, SSD y HDD<\/a>, antes de iniciar el programador <strong>establecer<\/strong>.<\/p>\n\n<h2>mq-deadline: plazos, secuencias y prioridades claras<\/h2>\n\n<p>mq-deadline establece plazos cortos para los accesos de lectura y hace que los accesos de escritura esperen un poco m\u00e1s para <strong>Tiempo de respuesta<\/strong> El programador tambi\u00e9n clasifica por direcciones de bloque, lo que reduce los tiempos de b\u00fasqueda, lo que resulta especialmente \u00fatil para los discos duros y las matrices RAID. En los hosts web y de bases de datos, mq-deadline ofrece un buen equilibrio entre latencia y rendimiento. Me gusta utilizarlo cuando las cargas de trabajo son mixtas y hay lecturas y escrituras pendientes de forma permanente. Para el ajuste fino, compruebo la profundidad de la solicitud, el comportamiento de reescritura y la cach\u00e9 del controlador para que la l\u00f3gica de Deadline sea coherente. <strong>agarra<\/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\/2025\/12\/linux_io_scheduler_meeting_4273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>BFQ: equidad y capacidad de respuesta para muchos usuarios simult\u00e1neos<\/h2>\n\n<p>BFQ distribuye el ancho de banda de forma proporcional y asigna presupuestos por proceso, lo que se nota. <strong>feria<\/strong> Funciona cuando muchos usuarios generan E\/S en paralelo. Las tareas interactivas, como los shells de administraci\u00f3n, los editores o las llamadas a la API, siguen funcionando con rapidez, aunque se est\u00e9n realizando copias de seguridad en segundo plano. En los discos duros, BFQ suele alcanzar una alta eficiencia porque aprovecha las fases secuenciales y utiliza de forma inteligente las breves ventanas de inactividad. En los SSD muy r\u00e1pidos se produce un peque\u00f1o esfuerzo adicional, que sopeso frente a la notable capacidad de respuesta. Quienes utilizan cgroups e ioprio pueden obtener garant\u00edas claras con BFQ y evitar as\u00ed molestias por vecinos ruidosos. <strong>Evite<\/strong>.<\/p>\n\n<h2>QoS en el d\u00eda a d\u00eda: ioprio, ionice y Cgroups v2 con BFQ<\/h2>\n\n<p>Para limpiar <strong>Priorizaci\u00f3n<\/strong> Combino BFQ con reglas de proceso y cgroup. A nivel de proceso, utilizo <code>ionice<\/code> Clases y prioridades: <code>ionice -c1<\/code> (tiempo real) para lecturas cr\u00edticas en cuanto a latencia, <code>ionice -c2 -n7<\/code> (mejor esfuerzo, bajo) para copias de seguridad o ejecuciones de \u00edndices, <code>ionice -c3<\/code> (Idle) para todo lo que solo debe ejecutarse en tiempos de inactividad. En Cgroups v2 utilizo <code>io.weight<\/code> para proporciones relativas (por ejemplo, 100 frente a 1000) y <code>io.max<\/code> para l\u00edmites estrictos, por ejemplo <code>echo \"259:0 rbps=50M wbps=20M\" &gt; \/sys\/fs\/cgroup\/\/io.max<\/code>. Con BFQ, los pesos se convierten con gran precisi\u00f3n en proporciones de ancho de banda, lo que resulta ideal para el alojamiento compartido y los hosts de contenedores en los que <strong>Equidad<\/strong> es m\u00e1s importante que la potencia bruta m\u00e1xima.<\/p>\n\n<h2>Comparaci\u00f3n pr\u00e1ctica: qu\u00e9 opci\u00f3n es la adecuada para el hardware<\/h2>\n\n<p>La elecci\u00f3n depende en gran medida del tipo de memoria y de la arquitectura de la cola, por lo que primero compruebo <strong>Dispositivo<\/strong> y controladores. Los SSD y NVMe suelen beneficiarse de Noop\/none, mientras que los HDD funcionan mejor con mq-deadline o BFQ. En configuraciones RAID, SAN y hosts vers\u00e1tiles, suelo preferir mq-deadline porque la l\u00f3gica de deadline y la clasificaci\u00f3n armonizan bien. Los entornos multiusuario con muchas sesiones interactivas suelen beneficiarse de BFQ. La siguiente tabla resume claramente las ventajas y los campos de aplicaci\u00f3n m\u00e1s adecuados. <strong>juntos<\/strong>:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>programador<\/th>\n      <th>Hardware<\/th>\n      <th>Puntos fuertes<\/th>\n      <th>Puntos d\u00e9biles<\/th>\n      <th>Escenarios de alojamiento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Noop\/ninguno<\/td>\n      <td>SSD, NVMe, m\u00e1quinas virtuales<\/td>\n      <td>Sobrecarga m\u00ednima, fusi\u00f3n limpia<\/td>\n      <td>Sin clasificaci\u00f3n en discos duros, desfavorable<\/td>\n      <td>Servidor Flash, contenedor, controlado por hipervisor<\/td>\n    <\/tr>\n    <tr>\n      <td>mq-fecha l\u00edmite<\/td>\n      <td>HDD, RAID, servidor vers\u00e1til<\/td>\n      <td>Prioridad de lectura estricta, clasificaci\u00f3n, latencia s\u00f3lida<\/td>\n      <td>M\u00e1s l\u00f3gica que Noop<\/td>\n      <td>Bases de datos, backends web, cargas mixtas<\/td>\n    <\/tr>\n    <tr>\n      <td>BFQ<\/td>\n      <td>HDD, multiusuario, hosts similares a equipos de escritorio<\/td>\n      <td>Equidad, capacidad de reacci\u00f3n, buenas secuencias.<\/td>\n      <td>Un poco m\u00e1s de sobrecarga en SSD muy r\u00e1pidos<\/td>\n      <td>Servicios interactivos, alojamiento compartido, servidor de desarrollo<\/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\/2025\/12\/linux-io-scheduler-hosting-4397.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuraci\u00f3n: comprobar el programador y establecerlo de forma permanente<\/h2>\n\n<p>Primero compruebo qu\u00e9 programador est\u00e1 activo, por ejemplo con <code>cat \/sys\/block\/sdX\/queue\/scheduler<\/code>, y anota el <strong>Opci\u00f3n<\/strong> entre corchetes. Para cambiar temporalmente, escribo, por ejemplo <code>echo mq-deadline | sudo tee \/sys\/block\/sdX\/queue\/scheduler<\/code>. Para configuraciones persistentes, utilizo reglas udev o par\u00e1metros del kernel como <code>scsi_mod.use_blk_mq=1<\/code> y <code>mq-fecha l\u00edmite<\/code> en la l\u00ednea de comandos. En el caso de los dispositivos NVMe, compruebo las rutas en <code>\/sys\/block\/nvme0n1\/queue\/<\/code> y selecciona la opci\u00f3n para cada dispositivo. Importante: documento los cambios para que el mantenimiento y la reversi\u00f3n se puedan realizar sin conjeturas. <strong>triunfar<\/strong>.<\/p>\n\n<h2>Persistencia y automatizaci\u00f3n en el funcionamiento<\/h2>\n\n<p>En mi d\u00eda a d\u00eda, antepongo la repetibilidad a la automatizaci\u00f3n. Hay tres formas que han demostrado su eficacia:<\/p>\n<ul>\n  <li><strong>Reglas udev<\/strong>: Ejemplo para todos los discos duros (rotacionales=1) <code>echo 'ACTION==\"add|change\", KERNEL==\"sd*\", ATTR{queue\/rotational}==\"1\", ATTR{queue\/scheduler}=\"mq-deadline\"' &gt; \/etc\/udev\/rules.d\/60-io-scheduler.rules<\/code>, entonces <code>udevadm control --reload-rules &amp;&amp; udevadm trigger<\/code>.<\/li>\n  <li><strong>systemd-tmpfiles<\/strong>: Para dispositivos espec\u00edficos, defino <code>\/etc\/tmpfiles.d\/blk.conf<\/code> con frases como <code>w \/sys\/block\/sdX\/queue\/scheduler - - - - mq-deadline<\/code>, que escriben al arrancar.<\/li>\n  <li><strong>Gesti\u00f3n de la configuraci\u00f3n<\/strong>: En Ansible\/Salt, creo clases de dispositivos (NVMe, HDD) y distribuyo valores predeterminados coherentes, junto con la documentaci\u00f3n y la reversi\u00f3n.<\/li>\n<\/ul>\n<p>Nota: <code>elevador=<\/code> como par\u00e1metro del n\u00facleo se aplicaba a la antigua ruta de cola \u00fanica. En blk-mq, yo determino la elecci\u00f3n. <strong>por dispositivo<\/strong>. En el caso de las pilas (dm-crypt, LVM, MD), establezco el valor predeterminado en el dispositivo superior. M\u00e1s informaci\u00f3n al respecto a continuaci\u00f3n.<\/p>\n\n<h2>Cargas de trabajo en el alojamiento: reconocer patrones y actuar correctamente<\/h2>\n\n<p>Primero analizo la carga: muchas lecturas peque\u00f1as indican interfaces web, escrituras con mucha sincronizaci\u00f3n en bases de datos y canalizaciones de registros, grandes flujos secuenciales en copias de seguridad o <strong>Archivo<\/strong>. Herramientas como <code>iostat<\/code>, <code>vmstat<\/code> y <code>blktrace<\/code> muestran colas, latencias y efectos de fusi\u00f3n. En caso de un tiempo de inactividad notable de la CPU debido a la E\/S, remito a <a href=\"https:\/\/webhosting.de\/es\/io-wait-comprender-cuello-de-botella-de-memoria-solucionar-optimizacion\/\">Entender la espera de E\/S<\/a>, para resolver los cuellos de botella de forma estructurada. A continuaci\u00f3n, pruebo 1-2 candidatos a programador en intervalos de tiempo id\u00e9nticos. Solo los resultados de las mediciones son decisivos, no la intuici\u00f3n o <strong>mitos<\/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\/2025\/12\/linux_scheduler_hosting_4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Profundizar en la pr\u00e1ctica de la medici\u00f3n: puntos de referencia reproducibles<\/h2>\n\n<p>Para tomar decisiones s\u00f3lidas, utilizo <strong>fio<\/strong>Perfiles y confirmaci\u00f3n mediante pruebas reales de la aplicaci\u00f3n:<\/p>\n<ul>\n  <li><strong>Lecturas aleatorias<\/strong> (Web\/Cach\u00e9): <code>fio --name=rr --rw=randread --bs=4k --iodepth=32 --numjobs=4 --runtime=120 --time_based --filename=\/mnt\/testfile --direct=1<\/code><\/li>\n  <li><strong>Mezcla aleatoria<\/strong> (DB): <code>fio --name=randmix --rw=randrw --rwmixread=70 --bs=8k --iodepth=64 --numjobs=8 --runtime=180 --time_based --direct=1<\/code><\/li>\n  <li><strong>Secuencial<\/strong> (Copia de seguridad): <code>fio --name=seqw --rw=write --bs=1m --iodepth=128 --numjobs=2 --runtime=120 --time_based --direct=1<\/code><\/li>\n<\/ul>\n<p>Al mismo tiempo, inicio sesi\u00f3n. <code>iostat -x 1<\/code>, <code>pidstat -d 1<\/code> y anota las latencias P95\/P99. <code>fio<\/code>. Para diagn\u00f3sticos profundos utilizo <code>blktrace<\/code> o herramientas eBPF como <code>biolatencia<\/code> . Importante: realizo las mediciones a la misma hora del d\u00eda, con las mismas ventanas de carga y los mismos tama\u00f1os de archivo. Minimizo los efectos de la cach\u00e9 con <code>direct=1<\/code> y condiciones previas limpias (por ejemplo, prellenado en el volumen).<\/p>\n\n<h2>Sistemas de archivos y programadores de E\/S: la interacci\u00f3n es importante<\/h2>\n\n<p>El sistema de archivos influye en las caracter\u00edsticas de E\/S, por lo que compruebo minuciosamente su modo de registro, la profundidad de la cola y el comportamiento de sincronizaci\u00f3n. <strong>exactamente<\/strong>. EXT4 y XFS funcionan de manera eficiente con mq-deadline, mientras que ZFS almacena y agrega gran parte por s\u00ed mismo. En hosts con ZFS, observo que el efecto del programador suele ser menor, ya que ZFS ya da forma a la salida. Para las comparaciones, utilizo opciones de montaje y cargas de trabajo id\u00e9nticas. Si se est\u00e1n sopesando opciones, en <a href=\"https:\/\/webhosting.de\/es\/ext4-xfs-zfs-alojamiento-rendimiento-comparacion-almacenamiento\/\">EXT4, XFS o ZFS<\/a> perspectivas \u00fatiles sobre <strong>Almacenamiento<\/strong>-Puesta a punto.<\/p>\n\n<h2>Writeback, cach\u00e9 y barreras: la mitad que a menudo se pasa por alto<\/h2>\n\n<p>Los programadores solo pueden funcionar tan bien como lo permita el subsistema de reescritura. Por lo tanto, siempre compruebo lo siguiente:<\/p>\n<ul>\n  <li><strong>Par\u00e1metro dirty<\/strong>: <code>sysctl vm.dirty_background_bytes<\/code>, <code>vm.bytes sucios<\/code>, <code>vm.dirty_expire_centisecs<\/code> Controlar cu\u00e1ndo y con qu\u00e9 agresividad escribe el n\u00facleo. Para las bases de datos, a menudo reduzco los picos de r\u00e1fagas para mantener estable el P99.<\/li>\n  <li><strong>Barreras\/Flush<\/strong>: Opciones como EXT4 <code>barrera<\/code> Solo aseguro los vaciados predeterminados de XFS si el hardware (por ejemplo, BBWC) los asume. \u201enobarrier\u201c sin protecci\u00f3n contra descargas el\u00e9ctricas es <strong>arriesgado<\/strong>.<\/li>\n  <li><strong>Cach\u00e9 de escritura del dispositivo<\/strong>: Verifico la configuraci\u00f3n de la cach\u00e9 de escritura del controlador para que <code>fsync<\/code> realmente llega al medio y no solo a la cach\u00e9.<\/li>\n<\/ul>\n<p>Quien suaviza Writeback alivia la carga del programador: los plazos siguen siendo fiables y BFQ tiene que trabajar menos contra las oleadas repentinas de vaciado.<\/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\/2025\/12\/linux_io_scheduler_4813.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Virtualizaci\u00f3n, contenedores y nube: \u00bfqui\u00e9n planifica realmente?<\/h2>\n\n<p>En las m\u00e1quinas virtuales, el hipervisor controla el flujo f\u00edsico de E\/S, por lo que a menudo selecciono Noop\/none en el invitado para evitar duplicados. <strong>l\u00f3gica<\/strong> . En el propio host utilizo mq-deadline o BFQ, dependiendo del dispositivo y la tarea. En los vol\u00famenes en la nube (por ejemplo, el almacenamiento en bloques de red), parte de la planificaci\u00f3n se realiza en el backend, por lo que mido las latencias reales en lugar de basarme en suposiciones. Para los hosts de contenedores con una carga muy mixta, BFQ suele ofrecer una mejor interactividad. En cl\u00fasteres por lotes homog\u00e9neos con solo flash, Noop se impone porque cada tiempo de CPU cuenta y los controladores son eficientes. <strong>trabajo<\/strong>.<\/p>\n\n<h2>RAID, LVM, MD y multipath: d\u00f3nde interviene el programador<\/h2>\n\n<p>En pilas de bloques apilados, coloco el programador en el <strong>Dispositivo de gama alta<\/strong> , ya que all\u00ed se encuentran las colas relevantes:<\/p>\n<ul>\n  <li><strong>LVM\/dm-crypt<\/strong>: Programador en <code>\/dev\/dm-*<\/code> respectivamente <code>\/dev\/mapper\/<\/code> . Por lo general, dejo los PV f\u00edsicos en <code>ninguno<\/code>, para que la fusi\u00f3n\/clasificaci\u00f3n no se realice dos veces.<\/li>\n  <li><strong>MD-RAID<\/strong>: En <code>\/dev\/mdX<\/code> decidir; subyacente <code>sdX<\/code> Los dispositivos permanecen tranquilos <code>ninguno<\/code>. El RAID por hardware se trata como un \u00fanico dispositivo de bloque.<\/li>\n  <li><strong>Multitrayecto<\/strong>: En el mapeador multipath (<code>\/dev\/mapper\/mpatha<\/code>); los dispositivos de ruta debajo de <code>ninguno<\/code>.<\/li>\n<\/ul>\n<p>Importante: separo las pruebas seg\u00fan <strong>piscina<\/strong> y nivel de redundancia (RAID1\/10 frente a RAID5\/6). Los RAID de paridad son m\u00e1s sensibles a las escrituras aleatorias; en este caso, mq-deadline suele ganar gracias a sus plazos de lectura coherentes y a su salida ordenada.<\/p>\n\n<h2>Estrategias de optimizaci\u00f3n: paso a paso hacia un rendimiento fiable<\/h2>\n\n<p>Empiezo con una medici\u00f3n b\u00e1sica: tiempos de respuesta actuales, rendimiento, percentiles 95\/99 y CPU.<strong>Carga<\/strong>. A continuaci\u00f3n, solo cambio un factor, normalmente el programador, y repito la misma carga. Herramientas como <code>fio<\/code> ayudan a controlar, pero confirmo cada hip\u00f3tesis con pruebas de aplicaci\u00f3n reales. Para las bases de datos son adecuados los propios puntos de referencia, que reflejan las transacciones y el comportamiento fsync. Solo cuando la medici\u00f3n es estable, confirmo la elecci\u00f3n y la documento. <strong>Por qu\u00e9<\/strong>.<\/p>\n\n<h2>Profundidad de la cola, lectura anticipada y afinidad de la CPU<\/h2>\n\n<p>Adem\u00e1s del programador, los par\u00e1metros de la cola influyen considerablemente en la pr\u00e1ctica:<\/p>\n<ul>\n  <li><strong>Profundidad de la cola<\/strong>: <code>\/sys\/block\/\/queue\/nr_requests<\/code> Limita las solicitudes pendientes por cola de hardware. NVMe admite una gran profundidad (alto rendimiento), mientras que los HDD se benefician de una profundidad moderada (latencia m\u00e1s estable).<\/li>\n  <li><strong>Readahead<\/strong>: <code>\/sys\/block\/\/queue\/read_ahead_kb<\/code> respectivamente <code>blockdev --getra\/setra<\/code>. Mant\u00e9ngalo algo m\u00e1s alto para cargas de trabajo secuenciales y bajo para cargas de trabajo aleatorias.<\/li>\n  <li><strong>rq_affinity<\/strong>Con <code>\/sys\/block\/\/queue\/rq_affinity<\/code> En el segundo, me aseguro de que la finalizaci\u00f3n de E\/S se realice preferentemente en el n\u00facleo de CPU generador, lo que reduce los costes entre CPU.<\/li>\n  <li><strong>rotacional<\/strong>: Verifico que los SSD <code>rotacional=0<\/code> para que el n\u00facleo no aplique heur\u00edsticas HDD.<\/li>\n  <li><strong>Fusiones<\/strong>: <code>\/sys\/block\/\/queue\/nomerges<\/code> Puede reducir las fusiones (2=desactivado). \u00datil en parte para la microlatencia NVMe, pero generalmente desfavorable para los discos duros.<\/li>\n  <li><strong>io_poll<\/strong> (NVMe): el sondeo puede reducir las latencias, pero requiere CPU. Lo activo espec\u00edficamente en <strong>Baja latencia<\/strong>-Requisitos.<\/li>\n<\/ul>\n\n<h2>Ajustes del programador en detalle<\/h2>\n\n<p>Dependiendo del programador, hay disponibles ajustes precisos \u00fatiles:<\/p>\n<ul>\n  <li><strong>mq-fecha l\u00edmite<\/strong>: <code>\/sys\/block\/\/queue\/iosched\/read_expire<\/code> (ms, t\u00edpicamente peque\u00f1o), <code>write_expire<\/code> (m\u00e1s grande), <code>fifo_batch<\/code> (tama\u00f1o del lote), <code>front_merges<\/code> (0\/1). Considero que <code>read_expire<\/code> brevemente para proteger las lecturas P95 y ajustar <code>fifo_batch<\/code> Seg\u00fan el dispositivo.<\/li>\n  <li><strong>BFQ<\/strong>: <code>slice_inactivo<\/code> (Tiempo de inactividad para el uso de secuencias), <code>baja latencia<\/code> (0\/1) para una interactividad con gran capacidad de reacci\u00f3n. Con <code>bfq.weight<\/code> En Cgroups controlo las cuotas relativas con mucha precisi\u00f3n.<\/li>\n  <li><strong>none\/noop<\/strong>: Apenas tornillos de ajuste, pero los <strong>Alrededores<\/strong> (profundidad de la cola, lectura anticipada) determina los resultados.<\/li>\n<\/ul>\n<p>Siempre cambio solo un par\u00e1metro y registro estrictamente el cambio, as\u00ed queda claro qu\u00e9 efecto ha tenido cada cosa.<\/p>\n\n<h2>Errores comunes y c\u00f3mo evitarlos<\/h2>\n\n<p>Las combinaciones mixtas de HDD y SSD detr\u00e1s de un controlador RAID falsean las pruebas, por lo que separo las mediciones por <strong>Grupo<\/strong>. No olvido que el programador se aplica por dispositivo de bloque; considero por separado los dispositivos LVM Mapper y MD. La persistencia tiende a desaparecer: sin una regla udev o un par\u00e1metro del n\u00facleo, tras el reinicio vuelve a aparecer el valor predeterminado. Los cgroups y las prioridades de E\/S suelen quedar sin utilizar, aunque mejoran considerablemente la equidad. Y siempre compruebo la profundidad de la cola, la reescritura y las opciones del sistema de archivos para que la l\u00f3gica elegida alcance su potencial. <strong>muestra<\/strong>.<\/p>\n\n<h2>Soluci\u00f3n de problemas: leer los s\u00edntomas de forma espec\u00edfica<\/h2>\n\n<p>Cuando los valores medidos cambian, interpreto los patrones y deduzco medidas concretas:<\/p>\n<ul>\n  <li><strong>Alta latencia P99 con muchas lecturas<\/strong>: Comprobar si las escrituras desplazan a las lecturas. Probar con mq-deadline., <code>read_expire<\/code> reducir, suavizar la reversi\u00f3n (<code>vm.dirty_*<\/code> adaptar).<\/li>\n  <li><strong>100% util en HDD, rendimiento bajo<\/strong>: Dominan las b\u00fasquedas. Probar BFQ o mq-deadline, reducir Readahead, moderar la profundidad de la cola.<\/li>\n  <li><strong>Buen rendimiento, pero la interfaz de usuario es irregular.<\/strong>: La interactividad se ve afectada. Activar BFQ, servicios cr\u00edticos mediante <code>ionice -c1<\/code> o dar preferencia a las ponderaciones de Cgroup.<\/li>\n  <li><strong>Gran variaci\u00f3n seg\u00fan la hora del d\u00eda<\/strong>: Recursos compartidos. Aislar con cgroups, seleccionar el programador para cada grupo, trasladar las copias de seguridad a horas de menor actividad.<\/li>\n  <li><strong>Tiempo de espera NVMe en dmesg<\/strong>: Backend o tema del firmware. <code>io_poll<\/code> Desactivar a modo de prueba, comprobar el firmware\/controlador, verificar la redundancia de la ruta (multiruta).<\/li>\n<\/ul>\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\/2025\/12\/linux-io-hosting-9481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En resumen: decisiones claras para el d\u00eda a d\u00eda del alojamiento web.<\/h2>\n\n<p>Para el almacenamiento flash y los invitados, suelo optar por <strong>Noop<\/strong>, para ahorrar gastos generales y dejar trabajar a los controladores. En servidores vers\u00e1tiles con HDD o RAID, mq-deadline ofrece una latencia fiable y una alta disponibilidad. Con muchos usuarios activos y una carga interactiva, BFQ garantiza una distribuci\u00f3n equitativa y una capacidad de respuesta notable. Antes de cada fijaci\u00f3n, realizo mediciones con cargas de trabajo reales y observo los efectos en P95\/P99. De este modo, tomo decisiones comprensibles, mantengo los sistemas en funcionamiento y estabilizo el <strong>Servidor<\/strong>-Rendimiento en las actividades diarias.<\/p>","protected":false},"excerpt":{"rendered":"<p>Explicaci\u00f3n del programador de E\/S de Linux: noop, mq-deadline y BFQ para un alojamiento \u00f3ptimo. Consejos de ajuste del almacenamiento para el rendimiento del servidor.<\/p>","protected":false},"author":1,"featured_media":16142,"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-16149","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":"1826","_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":null,"_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":"I\/O Scheduler Linux","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":"16142","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/16149","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=16149"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/16149\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/16142"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=16149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=16149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=16149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}