NVMe tuning en servidores Linux: guía completa de optimización

Si trabajas con servidores Linux y has dado el salto a discos NVMe, seguramente te habrás dado cuenta de que, aunque son muchísimo más rápidos que los HDD o incluso que los SSD SATA, no siempre ves en producción las cifras espectaculares que prometen las hojas de especificaciones. No es que el hardware te haya engañado: normalmente es el sistema operativo, la configuración del kernel y de los servicios lo que está poniendo el freno.

En este artículo vamos a ver cómo realizar un tuning serio de NVMe en servidores Linux, pensando tanto en rendimiento puro (latencia, IOPS y ancho de banda) como en durabilidad de las unidades. Además, lo integraremos con la capa de base de datos (MySQL/MariaDB, sobre todo InnoDB) y con buenas prácticas de uso de SSD y NVMe para que tu plataforma rinda como debe. El objetivo es que puedas pasar de pruebas de laboratorio con fio a cargas reales de producción que realmente vuelen.

Requisitos previos y herramientas para optimizar NVMe en Linux

Antes de empezar a cambiar parámetros es básico tener acceso root al servidor y un buen plan de copias de seguridad. Muchos de los ajustes que vamos a tratar afectan al kernel, al particionado o incluso al formato del dispositivo, así que cualquier error puede dejar un servicio caído o un volumen irrecuperable.

También necesitas contar con ciertas utilidades para gestionar NVMe, monitorizar I/O y hacer benchmarks. En Debian o Ubuntu puedes instalarlas con:

Instalación en Debian/Ubuntu: sudo apt update
sudo apt install nvme-cli fio util-linux iotop sysstat numactl -y

En sistemas basados en RHEL (Rocky, Alma, CentOS, etc.) se logran con:

Instalación en RHEL y derivados: sudo dnf update -y
sudo dnf install nvme-cli fio util-linux iotop sysstat numactl -y

Con estas herramientas podrás identificar tus dispositivos NVMe, revisar su salud y actualizar firmware en Linux, medir latencias y throughput de forma objetiva y repetible, algo crítico antes de tocar nada para poder comparar el “antes” y el “después”.

Descubrir, identificar y medir tus dispositivos NVMe

El primer paso consiste en listar qué unidades NVMe tienes realmente y cuáles son sus características. Con nvme-cli puedes verlo de forma muy clara y sin tener que pelearte con nombres raros en /dev.

Listar dispositivos NVMe: nvme list

Si quieres profundizar, el siguiente comando muestra las capacidades del controlador NVMe (colas de comandos, tamaño máximo de transferencia, etc.):

Detalles del controlador NVMe: nvme id-ctrl -H /dev/nvme0

Y para ver la información de la “namespace” (formatos LBA, tamaños de sector y ranking de rendimiento relativo):

Detalles de namespace NVMe: nvme id-ns -H /dev/nvme0n1

Antes de empezar a afinar el sistema, conviene guardar una línea base de rendimiento con fio. Por ejemplo, puedes medir la latencia en lectura aleatoria 4K con I/O directo:

Benchmark base (fio randread 4K): fio --name=randread --filename=/dev/nvme0n1 --rw=randread --bs=4k \
--iodepth=64 --numjobs=1 --ioengine=io_uring --direct=1 --time_based=1 --runtime=20

Y el throughput de lectura secuencial a 128K:

Benchmark base (fio seqread 128K): fio --name=seqread --filename=/dev/nvme0n1 --rw=read --bs=128k \
--iodepth=64 --numjobs=1 --ioengine=io_uring --direct=1 --time_based=1 --runtime=20

Para entender cómo se comporta el sistema en su conjunto, es útil complementar esto con iostat y smart-log:

Comprobaciones iostat / smart-log: iostat -x 2 10
nvme smart-log /dev/nvme0

Así sabrás si tu cuello de botella está en tiempos de servicio de la cola, temperatura, errores de medios o simplemente en la capa superior (filesystem, base de datos, etc.).

Gestión de energía NVMe (APST) para latencias bajas

Las unidades NVMe implementan APST (Autonomous Power State Transition), un mecanismo para ahorrar energía entrando en estados de bajo consumo más profundos. Eso está bien para portátiles, pero en un servidor donde importan las colas de milisegundos o microsegundos, esos “despertares” del SSD pueden introducir picos de latencia nada agradables.

Si priorizas la latencia consistente sobre el ahorro energético, puedes desactivar APST ajustando el parámetro del módulo nvme_core (consulta las novedades del kernel). En sistemas con GRUB bastaría con añadir:

Desactivar APST (GRUB): sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="nvme_core.default_ps_max_latency_us=0 /' /etc/default/grub
sudo update-grub

Tras reiniciar, el kernel dejará de mandar la unidad a estados profundos de ahorro y, en general, las colas 99% y 99.9% de latencia deberían mejorar, siempre que la refrigeración del servidor sea adecuada para el aumento de temperatura.

Planificador de E/S adecuado para NVMe y ajustes de la capa de bloque

El planificador de E/S (I/O scheduler) es la capa que decide en qué orden se sirven las peticiones de lectura y escritura hacia el dispositivo. Con discos mecánicos tenía mucho sentido usar planificadores complejos que optimizasen el movimiento físico de los cabezales, pero con NVMe eso sobra y hasta puede estorbar.

En la mayoría de distribuciones modernas, las unidades NVMe ya usan scheduler «none» (o mq-deadline en ciertos casos). Aun así, merece la pena comprobarlo:

Verificar scheduler I/O: cat /sys/block/nvme0n1/queue/scheduler

Si ves algo distinto y tu carga es principalmente I/O aleatorio de baja latencia, puedes forzar el planificador «none»:

Forzar scheduler ‘none’: echo none | sudo tee /sys/block/nvme0n1/queue/scheduler

Para cargas muy mezcladas con escrituras intensivas, «mq-deadline» puede dar mejor equilibrio entre throughput y latencia:

Forzar scheduler ‘mq-deadline’: echo mq-deadline | sudo tee /sys/block/nvme0n1/queue/scheduler

Además del planificador, la capa de bloque ofrece otros dos controles importantes: read-ahead y tamaño máximo de petición. El read-ahead (read_ahead_kb) “lee por adelantado” más datos de los que se han pedido, algo útil en accesos secuenciales largos pero contraproducente en accesos aleatorios.

Valores típicos de read_ahead_kb: echo 128 | sudo tee /sys/block/nvme0n1/queue/read_ahead_kb # cargas aleatorias (BBDD)
echo 4096 | sudo tee /sys/block/nvme0n1/queue/read_ahead_kb # secuencial grande (backups, vídeo, etc.)

Respecto al tamaño máximo de petición (max_sectors_kb), conviene alinearlo con el tamaño de I/O óptimo de la unidad y no superar el máximo hardware:

Consultar tamaños óptimos de I/O: cat /sys/block/nvme0n1/queue/optimal_io_size
cat /sys/block/nvme0n1/queue/max_hw_sectors_kb

Una vez conocido esto, puedes fijar un valor razonable, por ejemplo 1024 KB:

Fijar max_sectors_kb: sudo sh -c 'echo 1024 > /sys/block/nvme0n1/queue/max_sectors_kb'

Afinar afinidad de CPU y NUMA para NVMe

En servidores modernos con varias CPUs o sockets (NUMA), la latencia de acceso a memoria y dispositivos no es uniforme. Una unidad NVMe está físicamente próxima a un nodo NUMA concreto y, si los hilos que la usan viven en otro nodo, cada I/O cruza el bus inter-socket con el consiguiente peaje de latencia.

Por eso interesa que tanto las interrupciones de la NVMe como los procesos que la usan se fijen al mismo nodo NUMA. Primero averigua qué IRQs usa la NVMe:

Localizar IRQs NVMe: grep -i nvme /proc/interrupts

Luego puedes fijar, por ejemplo, todas las IRQ de nvme0 a los núcleos 0-3:

Asignar afinidad IRQ a núcleos: for i in $(grep -i nvme0 /proc/interrupts | awk -F: '{print $1}'); do
echo 0-3 | sudo tee /proc/irq/$i/smp_affinity_list
done

Cuando lances tu base de datos o servicio principal, incluso en virtualización con KVM, usa numactl para fijar CPU y memoria al mismo nodo:

Ejecutar servicio con numactl: numactl --cpunodebind=0 --membind=0 tu-binario --tus-opciones

Otro pequeño ajuste de la capa de bloque es rq_affinity, que indica cómo se procesan las colas de completado de I/O. El valor 2 fuerza a que la finalización se maneje en el mismo núcleo que lanzó la petición, mejorando la localidad de caché:

Activar rq_affinity=2: echo 2 | sudo tee /sys/block/nvme0n1/queue/rq_affinity

Hacer persistentes los cambios de tuning NVMe con udev

Todos los cambios hechos tocando files en /sys se pierden al reiniciar. Para no tener que ejecutar scripts manualmente cada vez, lo más limpio es usar reglas de udev que apliquen el tuning en cuanto el kernel detecta el dispositivo.

Por ejemplo, para fijar scheduler a none, rq_affinity a 2 y read_ahead a 128 KB en todas las unidades NVMe, podrías crear:

Crear regla udev para tuning: sudo nano /etc/udev/rules.d/60-nvme-tuning.rules

Con el contenido:

Ejemplo de regla udev: ACTION=="add|change", KERNEL=="nvme*n*", \
ATTR{queue/rq_affinity}="2", \
ATTR{queue/scheduler}="none", \
ATTR{queue/read_ahead_kb}="128"

Después recargas udev y disparas las reglas:

Aplicar reglas udev: sudo udevadm control --reload
sudo udevadm trigger

Si además quieres asegurarte de que todas las unidades montadas se benefician de opciones como noatime o tmpfs para directorios temporales, combina estas reglas con una buena configuración de /etc/fstab, algo que también reduce escrituras y ayuda a la longevidad de SSD y NVMe.

Alineación de particiones, sector lógico y TRIM en NVMe

Para que un NVMe rinda como debe a largo plazo no basta con parámetros del kernel: la geometría lógica de las particiones y el uso de TRIM, ni tecnologías como el almacenamiento persistente en memoria, marcan la diferencia, sobre todo en cargas de base de datos y virtualización donde la fragmentación y la sobreescritura son constantes.

Lo primero es comprobar que tus particiones están alineadas a 1 MiB, lo que suele cuadrar bien con la geometría interna de la mayoría de SSD modernos. Con parted puedes crear un esquema limpio:

Particionado alineado (parted): sudo parted -s /dev/nvme0n1 mklabel gpt
sudo parted -s /dev/nvme0n1 mkpart primary 1MiB 100%
sudo parted -s /dev/nvme0n1 align-check optimal 1

Además, muchas NVMe ofrecen varios formatos de LBA (LBAF) con distintos tamaños de sector, típicamente 512B y 4K. Puedes ver las opciones y la métrica RP (Relative Performance) con:

Ver formatos LBA: nvme id-ns -H /dev/nvme0n1 | grep -E 'LBA Format|Relative'

Si decides cambiar, ten claro que se trata de una operación destructiva que borra todo el contenido de la unidad. Un ejemplo para escoger el formato con índice 1 sería:

Cambiar formato LBA (operación destructiva): sudo nvme format /dev/nvme0n1 --lbaf=1

En cuanto a TRIM, la idea es informar a la unidad de qué bloques ya no contienen datos válidos para que pueda reutilizarlos sin penalización. Primero comprueba que el dispositivo lo soporta con lsblk:

Comprobar soporte TRIM: lsblk --discard

Si ves un valor DISC-GRAN distinto de cero, hay soporte. La mayoría de distribuciones recientes activan un timer semanal de fstrim que es la opción recomendada, mejor que usar la opción discard en /etc/fstab, que mete overhead en cada borrado:

Habilitar fstrim periódico: systemctl enable --now fstrim.timer
systemctl status fstrim.timer

Elección y montaje de sistemas de ficheros sobre NVMe

La capa de filesystem es el último filtro entre tu aplicación y el NVMe. Tanto XFS como ext4 funcionan muy bien en servidores Linux, y en la mayoría de casos conviene usar sus opciones por defecto con ligeros ajustes orientados a reducir escrituras inútiles.

Una opción muy efectiva y casi sin contrapartidas es noatime, que evita actualizar la hora de último acceso cada vez que se lee un archivo. De esta forma reduces escrituras en disco, lo que ayuda tanto a la durabilidad como al rendimiento. Un ejemplo en /etc/fstab con ext4 sería:

Ejemplo fstab (ext4 noatime): /dev/nvme0n1p1 / ext4 noatime,errors=remount-ro 0 1

Con XFS la filosofía es la misma: usar el sistema de ficheros por defecto y añadir noatime si quieres apurar aún más la vida útil del SSD. En el caso de ext4 y XFS, es preferible TRIM periódico con fstrim.timer antes que la opción discard, salvo necesidades muy específicas.

Si trabajas con SD cards o medios extraíbles, ten en cuenta que muchos usan FAT32 o exFAT, que no tienen journaling ni TRIM. En esos casos el tuning se centra más en elegir tarjetas de mayor calidad y capacidad, y en minimizar escrituras cambiando /var/log, /tmp o directorios con mucha I/O a tmpfs cuando tenga sentido.

Optimización general de SSD/NVMe: noatime, tmpfs, swap y logging

Además del tuning específico de NVMe, hay un conjunto de ajustes clásicos para SSD que siguen siendo muy válidos. El primero es revisar qué directorios sufren más lecturas y escrituras constantes usando iotop:

Monitorizar I/O en tiempo real: iotop -oPa

Deja que corra un rato y verás qué procesos y rutas se llevan el gato al agua. A partir de ahí, puedes mover algunos directorios altamente volátiles a tmpfs en RAM, siempre que tengas memoria de sobra. Ejemplos típicos en /etc/fstab:

Ejemplo tmpfs en fstab: tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0

En muchos Linux modernos /tmp ya es tmpfs, pero aún puedes llevarte /var/tmp u otros directorios ruidosos a RAM. Otro candidato es /var/log, si no te importa perder logs entre reinicios o si envías los registros a un syslog remoto:

tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0

En paralelo, revisa la configuración de systemd-journald en /etc/systemd/journald.conf para limitar tamaño máximo de logs (SystemMaxUse, RuntimeMaxUse, etc.) y el nivel de detalle (MaxLevelStore), evitando tormentas de escritura innecesarias.

Otro punto clave para cualquier SSD o NVMe es el uso de swap y la política de swappiness. Reducir este valor hace que el kernel aguante más en RAM y tire menos de disco:

Ajuste de swappiness: vm.swappiness=1

Si tienes muchísima memoria y eres consciente del riesgo, podrías incluso fijarlo a 0, aunque en la práctica suele ser más equilibrado combinarlo con zram o zswap, que comprimen y gestionan la swap en memoria antes de llegar al disco físico, reduciendo mucho las escrituras sobre el NVMe.

Diagnóstico de problemas reales vs benchmarks sintéticos (fio, dd, copias de ficheros)

No es raro que un administrador se encuentre con la situación de que fio da números excelentes, pero una simple copia de archivos o un SELECT INTO de base de datos parece ridículamente lenta. Es crucial entender que las cargas reales no se parecen a un benchmark perfecto y que hay muchos más factores implicados.

Comandos como dd con bs=1M suelen mostrar velocidades limitadas por la capa de filesystem, el cache de página del kernel, el propio dd y la forma en que escribe. Del mismo modo, una operación masiva en MSSQL, MySQL o MariaDB sobre ext4 o XFS no solo mide el NVMe, sino journaling, fsync, flush de logs, locking, CPU, planificador del kernel y un largo etcétera.

Si en un servidor con Epyc, grandes cantidades de RAM y NVMe de alta gama ves que las copias no pasan de 1-2 GB/s, pero fio reporta valores cercanos a especificación, lo más probable es que el cuello esté en la capa de software (filesystem, DB, configuración de journaling, tamaño de logs, etc.) o en cómo se está usando el paralelismo (número de hilos efectivos, límites de concurrencia en la base de datos, etc.).

El enfoque práctico es combinar herramientas de bajo nivel (fio, iostat, smart-log) con mediciones a nivel de aplicación y ajustar por capas: primero kernel y NVMe, luego filesystem y, por último, la base de datos y las propias consultas.

El papel del hardware y del sistema operativo en el rendimiento de bases de datos

Cuando se habla de tuning de bases de datos sobre NVMe es fundamental recordar que la configuración por defecto rara vez es suficiente para producción. La pirámide del rendimiento empieza por el hardware: CPU, cantidad de RAM y, sobre todo, tipo de almacenamiento.

En la base de esa pirámide está la calidad del almacenamiento: los HDD mecánicos ya no tienen sentido para BBDD transaccionales serias; los SSD SATA son el mínimo aceptable; y los NVMe conectados por PCIe son el estándar de oro gracias a su baja latencia y altísimo IOPS.

Por encima está el sistema operativo: cómo gestiona memoria, caché de página, E/S de disco y planificación de procesos influye directamente en la base de datos. Ajustes como swappiness, la elección del scheduler, el uso de O_DIRECT en InnoDB, la afinidad NUMA y el montaje de directorios en tmpfs pueden marcar más diferencia que un simple cambio de parámetro interno en MySQL.

Solo después tiene sentido pelear con la configuración del servidor de BBDD (InnoDB, buffers globales, logs, etc.) y, en la cúspide, con el diseño de esquemas e índices y con la calidad de las consultas SQL.

MySQL/MariaDB sobre NVMe: afinando InnoDB para explotar el hardware

InnoDB es el motor de almacenamiento moderno por defecto por una razón: ofrece transacciones ACID, bloqueo a nivel de fila, buena resistencia a la corrupción y capacidad para manejar mucha concurrencia. Pero para que brille necesita que su configuración esté alineada con el hardware subyacente, especialmente con NVMe rápidos.

El parámetro estrella es innodb_buffer_pool_size, que define cuánta RAM dedica InnoDB a mantener datos e índices calientes en memoria. Como regla general, en un servidor dedicado a base de datos, se reserva entre un 70% y un 80% de la RAM disponible para el buffer pool, ajustando según el resto de servicios que convivan en la máquina.

Cuando los datos caben principalmente en el buffer pool, las lecturas se resuelven en RAM y el NVMe se utiliza sobre todo para escrituras secuenciales de log y flushing controlado. De lo contrario, cada cache miss implica un viaje al disco, y aunque sea NVMe, el tiempo de respuesta será órdenes de magnitud más lento que un acceso en memoria.

El otro gran bloque de tuning son los logs de InnoDB (innodb_log_file_size y innodb_log_buffer_size). Un log de tamaño adecuado permite agrupar más cambios en escrituras secuenciales largas, reduciendo la presión de I/O aleatorio sobre los archivos de datos:

• Log file grande: más rendimiento de escritura pero tiempos de recuperación más largos tras un crash, ya que hay que re-reproducir más eventos.
• Log file pequeño: recuperación más rápida pero posible cuello de botella en escrituras intensivas.

Para aprovechar bien NVMe, suele compensar tener logs algo más grandes de lo habitual, ya que la unidad puede absorber cómodamente escrituras secuenciales y el tiempo de recuperación suele seguir siendo aceptable.

Concurrencia, hilos e I/O en InnoDB sobre NVMe

En entornos con muchas CPU y NVMe rápidos, es tentador tocar parámetros como innodb_thread_concurrency, innodb_read_io_threads e innodb_write_io_threads. Sin embargo, en versiones actuales de MySQL/MariaDB lo habitual es dejar innodb_thread_concurrency a 0 para que el motor gestione él mismo la concurrencia interna.

Lo que sí importa es vigilar que el servidor no se quede corto de hilos para operaciones de lectura y escritura y que la capa inferior (kernel y NVMe) esté preparada para manejar colas profundas (iodepth) cuando realmente la carga lo demande. Con NVMe no suele haber problema, pero conviene medir con herramientas como Performance Schema o sys schema para ver si hay esperas anómalas de I/O.

También es crítico cómo InnoDB interactúa con el sistema de ficheros. El parámetro innodb_flush_method=O_DIRECT en Linux evita el double buffering con la caché del sistema de archivos y escribe directamente en el dispositivo, algo especialmente recomendable cuando hay RAID con caché protegida o NVMe con buena caché interna.

Gestión de conexiones, buffers por sesión y cachés globales

NVMe rápido no sirve de mucho si el servidor de base de datos está saturado por miles de conexiones inactivas, buffers por sesión gigantescos o una configuración desfasada del Query Cache. Por eso, junto al tuning de InnoDB, hay que poner orden en los parámetros generales.

La variable max_connections define el número máximo de conexiones simultáneas permitidas. Aumentarla ciegamente porque “hay RAM de sobra” es un error: cada conexión arrastra buffers y estructuras internas que se suman en memoria. Lo sano es monitorizar Max_used_connections y ajustar max_connections un poco por encima del pico real, dejando margen pero sin dispararse.

wait_timeout manda cuánto tiempo se mantiene viva una conexión ociosa antes de cerrarla. Valores por defecto de horas no tienen mucho sentido en aplicaciones web con pools de conexiones. Reducirlo a 60 o incluso 30 segundos ayuda a limpiar sesiones abandonadas y a no llenar la memoria de conexiones “sleep”.

El parámetro thread_cache_size controla cuántos hilos se guardan en caché para reusar en nuevas conexiones. Si Threads_created sube mucho en relación con Connections, es una señal de que la caché es pequeña. Ajustarlo reduce el coste de creación de hilos y mejora la respuesta bajo ráfagas de tráfico.

En cuanto a la Query Cache, en MySQL moderno está obsoleta y en MariaDB suele causar más bloqueos y problemas de invalidación que beneficios en sistemas con alta tasa de escrituras. Sobre NVMe no aporta nada especial, y en la mayoría de casos conviene desactivarla.

Buffers de trabajo por sesión: cuidado con la memoria

Parámetros como sort_buffer_size, join_buffer_size y read_buffer_size son asignados por hilo cuando se necesitan, lo que significa que valores enormes multiplicados por cientos de conexiones pueden comerse la RAM a toda velocidad.

Estos buffers sirven para operaciones concretas (ordenaciones sin índice, joins sin índice, lecturas secuenciales), y solo deberían crecer para casos puntuales de consultas pesadas y controladas. A nivel global es mejor mantener valores conservadores y, si hace falta, subirlos de forma puntual en una sesión de mantenimiento o en un proceso batch, en lugar de fijar límites gigantes para todos los clientes.

Diseño de esquemas, índices y consultas: la capa donde más se gana

Por mucho NVMe, tuning de kernel e InnoDB que tengas, si tus tablas carecen de índices adecuados y las consultas hacen scans completos masivos, el hardware no podrá salvarte. La herramienta básica para ver qué está pasando es EXPLAIN.

Cuando analices un plan de ejecución, fíjate en:

• type: si ves ALL en tablas grandes, hay escaneo completo y toca añadir índices.
• key y possible_keys: qué índices podrían usarse y cuál se usa realmente.
• rows: número estimado de filas a examinar; cuanto más bajo, mejor.

Es clave indexar correctamente las columnas usadas en WHERE y en las condiciones de JOIN, así como reescribir subconsultas correlacionadas en JOINs cuando sea posible. Un buen diseño de índices reduce la I/O necesaria por consulta y, por tanto, explota mejor la baja latencia del NVMe.

A nivel de esquema, usar tipos de datos lo más pequeños posibles, normalizar hasta un nivel razonable y definir claves primarias simples (INT/BIGINT AUTO_INCREMENT) en InnoDB ayuda a que las tablas sean más compactas, quepan mejor en el buffer pool y se aprovechen de la caché y del hardware subyacente.

Monitorización continua y ciclo iterativo de tuning

Todo este tuning no tiene sentido si no mides antes y después de cada cambio. Para la base de datos, el Slow Query Log, Performance Schema y sys schema permiten localizar consultas lentas, tablas con muchos full scans, índices infrautilizados o ficheros que concentran demasiada I/O.

Herramientas externas como Prometheus/Grafana, Percona PMM u otros sistemas de monitorización facilitan ver la foto grande: latencia media y p95/p99 de consultas, QPS, uso de CPU, colas de I/O, temperatura y salud del NVMe, etc. Con esa información puedes aplicar un proceso iterativo sensato:

• Definir una línea base de rendimiento (hardware + kernel + BBDD).
• Identificar el cuello de botella dominante en ese momento.
• Aplicar un único cambio (ej. ajustar buffer pool, cambiar scheduler o añadir un índice).
• Medir de nuevo y decidir si el cambio se queda, se revierte o se modifica.

La optimización de NVMe y bases de datos sobre Linux no es un truco mágico ni un cambio de parámetro aislado, sino un proceso continuo de medir, entender y ajustar por capas. Combinando buen hardware (especialmente NVMe de calidad), un kernel bien afinado (APST, scheduler, NUMA, TRIM), sistemas de ficheros configurados con cabeza (noatime, tmpfs cuando conviene) y un MySQL/MariaDB bien parametrizado y con esquemas e índices sólidos, es perfectamente posible conseguir que tus servidores Linux expriman de verdad el potencial de sus unidades NVMe en cargas reales, más allá de los benchmarks sintéticos de laboratorio.