Ubuntu Server 24.04 Minimal vs Standard: Explicación de las pruebas de rendimiento

Un servidor virtual privado se queda corto de memoria, así que reinstalas Ubuntu Server 24.04 LTS y te enfrentas a una decisión: la instalación predeterminada de Ubuntu Server o Ubuntu Server (minimizado). Es tentador suponer que menos paquetes implican automáticamente solicitudes web más rápidas, consultas de base de datos más cortas y mayor rendimiento de la CPU. La diferencia es más compleja. Un conjunto de paquetes inicial más pequeño puede reducir el uso del disco y la actividad en segundo plano, pero no acelera automáticamente el procesador ni el dispositivo de almacenamiento.

En resumen: elige la instalación minimizada si buscas un punto de partida sencillo y solo necesitas añadir las herramientas imprescindibles. Elige la opción estándar si prefieres el conjunto de herramientas de servidor predeterminado más completo. Compara el tiempo de arranque, la memoria inactiva, el espacio en disco y el rendimiento real de las aplicaciones por separado, en lugar de agruparlos bajo la etiqueta de "más rápido".

Nota explicativa (9 de octubre de 2026): Este artículo describe un método de evaluación comparativa reproducible y los resultados que puede obtener cada métrica. No presenta puntuaciones originales medidas en dos instalaciones idénticas de Ubuntu 24.04. No se incluyen datos no verificados de RAM, disco, tiempo de arranque ni rendimiento como resultados de las pruebas.

¿Cuál es la diferencia entre Ubuntu Server estándar y minimizado?

El instalador Subiquity de Ubuntu Server ofrece dos fuentes de instalación: ubuntu-serveruna estándar (la predeterminada) y ubuntu-server-minimalotra minimizada. Canonical documenta estos identificadores de fuente y recomienda verificar casper/install-sources.yamlla imagen ISO elegida, ya que los identificadores del instalador pueden cambiar. Consulte la documentación de la fuente de instalación automática de Canonical Subiquity .

Ambas son Ubuntu Server 24.04 LTS, no dos arquitecturas de CPU optimizadas de forma diferente ni distribuciones de Linux distintas. Lo que cambia principalmente es el software incluido durante la instalación. Los paquetes que aparecen dependen de la revisión del medio de instalación, las opciones seleccionadas, las actualizaciones, los controladores y las aplicaciones instaladas posteriormente. No asuma que la lista publicada para una imagen se aplica sin cambios a todos los instaladores de versiones menores de 24.04.

La opción de servidor minimizado no debe confundirse con las imágenes de nube de Ubuntu mínimas , una familia de imágenes independiente, ni con la opción de instalación mínima de Ubuntu Desktop. Las notas de la versión Ubuntu 24.04 LTS mencionan una reducción sustancial en la cantidad de paquetes y el tamaño de descarga de las imágenes de nube mínimas en comparación con versiones anteriores. Estos ejemplos de imágenes de nube publicados no constituyen una prueba comparativa controlada entre una imagen ISO de servidor en vivo estándar y una minimizada, y sus cifras no deben reutilizarse como si lo fueran.

¿Qué indicadores de rendimiento son importantes?

El comportamiento esperado no es un resultado medido. Una máquina optimizada puede consumir menos recursos inmediatamente después de la instalación. Sin embargo, una vez que ambas máquinas ejecutan la misma base de datos, entorno de ejecución de contenedores, agente de monitorización y servidor web, la diferencia observada puede reducirse, desaparecer o cambiar de dirección. La única conclusión válida proviene de la medición de la carga de trabajo objetivo.

Empiece con una configuración de prueba justa, no con un cronómetro.

Cree dos máquinas virtuales desechables a partir de la misma revisión ISO de Ubuntu Server 24.04 LTS, una estándar y otra minimizada. Asigne la misma cantidad de vCPU, RAM, discos virtuales, sistemas de archivos, modo de arranque, configuración del hipervisor, conexión de red y clase de almacenamiento. Para las máquinas físicas, utilice hardware equivalente y realice pruebas en condiciones térmicas y de energía similares. Mantenga las máquinas fuera del tráfico de producción.

En ambos sistemas, aplique las mismas actualizaciones de seguridad y reinicie. Registre cat /etc/os-release, uname -r, y lscpu, además de la versión de la imagen del instalador y la fecha de la prueba. Ubuntu Server 24.04 normalmente usa la rama del kernel de disponibilidad general, pero opcionalmente puede usar kernels de habilitación de hardware; diferentes ramas del kernel comprometerían una comparación basada únicamente en el tipo de instalación. La documentación del kernel de Ubuntu sobre los kernels GA y HWE explica esta distinción.

Recopile dos conjuntos de mediciones:

1. Instalación limpia de referencia: Inmediatamente después de actualizaciones idénticas, antes de instalar una carga de trabajo. Esto permite aislar las diferencias prácticas en la configuración predeterminada de la instalación.
2. Configuración de referencia similar a la de producción: Tras instalar los mismos paquetes de aplicaciones, habilitar los mismos servicios y aplicar configuraciones idénticas. Esto permite determinar si la diferencia en el tamaño inicial de la infraestructura sigue siendo relevante.

Utilice al menos varias ejecuciones por prueba, preferiblemente cinco o más después del calentamiento, y compare las medianas y la variabilidad. Reinicie el sistema y mida el tiempo de arranque en varios arranques. Nunca compare el resultado de un arranque en frío en un sistema con el resultado de un arranque ya caliente en otro.

Primero, mide las diferencias más sencillas.

1. Cuenta los paquetes instalados y comprueba el espacio en disco.

El número de paquetes y el uso del almacenamiento suelen ser las características más sencillas de inspeccionar. En cada máquina virtual, ejecute:

dpkg-query -W -f='${binary:Package}\n' | wc -l
df -h /
lsblk -f

Registre el número de particiones, el espacio utilizado en el sistema de archivos raíz y la estructura del sistema de archivos. Asegúrese de que las particiones raíz tengan tamaños comparables; de lo contrario, podría existir una diferencia aparente debido al particionamiento. El uso del disco también incluye registros, cachés de paquetes y metadatos del sistema de archivos, por lo que es importante que los tiempos de instalación sean idénticos y que los historiales de actualización sean comparables.

2. Compara la RAM disponible, no solo la RAM "libre".

Después de que ambos sistemas hayan estado inactivos durante un período de estabilización constante, ejecute:

free -h
systemctl --type=service --state=running --no-pager

Observa también la availablecolumna en . Linux utiliza memoria que de otro modo estaría inactiva para la caché, la cual se puede recuperar cuando las aplicaciones la necesiten. Un valor menor en la columna no indica automáticamente un problema. Verifica si el uso adicional de memoria corresponde a servicios que realmente planeas mantener.freeusedfree

3. Compara el tiempo de arranque y encuentra servicios lentos.

Para cada arranque, utilice las herramientas systemd suministradas con la distribución:

systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain

systemd-analyze timeSe informa sobre los tiempos de arranque, pero esto no significa necesariamente que la aplicación esté lista para aceptar solicitudes. La blamelista también puede resultar engañosa, ya que las unidades pueden inicializarse en paralelo y algunos tipos de servicio no se miden de la misma manera. Investigue la cadena crítica y, a continuación, verifique por separado el punto final del servicio que le interesa. Estas limitaciones están documentadas en el manual de systemd-analyze de Ubuntu 24.04 .

Por ejemplo, si un servidor ejecuta una API HTTP, mida el tiempo transcurrido desde el reinicio hasta que el punto final de estado de la API se complete correctamente. Si un host ejecuta una base de datos, verifique que una consulta se complete correctamente. Esta medición de disponibilidad es más útil que el hecho de que el sistema operativo alcance un objetivo de arranque.

Luego, pruebe la CPU y el almacenamiento bajo una carga controlada.

4. Ejecuta la misma carga de trabajo de CPU en ambas máquinas.

Para una comparación sencilla de la CPU, instale una versión idéntica de sysbench en cada máquina virtual desechable después de registrar el consumo de recursos de la instalación nueva. Luego ejecute el mismo comando:

sudo apt update
sudo apt install sysbench
sysbench --threads=1 --time=30 cpu --cpu-max-prime=20000 run

Compara los eventos por segundo y la latencia en ejecuciones repetidas. La documentación del proyecto sysbench proporciona la sintaxis del comando y la prueba de CPU integrada. Utiliza una segunda ejecución con el mismo número de subprocesos, aunque mayor, solo si se ajusta al número de CPU asignado. Un conjunto de paquetes reducido por sí solo no justifica afirmar una mejora en la velocidad de la CPU; las diferencias inesperadas deberían motivar una comprobación de la contención de la CPU del host, el comportamiento del reloj, la versión del kernel y los procesos en segundo plano.

5. Prueba la E/S del disco sin realizar pruebas de rendimiento en un disco de producción.

Para un experimento de almacenamiento opcional, instale fio en ambas máquinas de prueba y cree archivos de prueba idénticos en un sistema de archivos desechable con amplio espacio libre. Los siguientes comandos crean un archivo de 256 MiB en el directorio principal del usuario actual y, a continuación, ejecutan una carga de trabajo de lectura aleatoria limitada sobre ese archivo:

sudo apt install fio
dd if=/dev/urandom of="$HOME/fio-sample.bin" bs=1M count=256 status=progress
fio --name=randread --filename="$HOME/fio-sample.bin" --rw=randread --bs=4k --size=256M --ioengine=libaio --iodepth=16 --direct=1 --runtime=30 --time_based --group_reporting

Ejecute ambas máquinas con discos y parámetros de E/S idénticos. Un archivo de 256 MiB puede ser demasiado pequeño para modelar con precisión su base de datos o dispositivo de almacenamiento; amplíe el archivo y varíe la carga de trabajo solo cuando disponga de suficiente espacio temporal y un entorno de prueba seguro. Registre las IOPS, el ancho de banda y la distribución de latencia, no solo el valor máximo de ancho de banda. El manual de fio de Ubuntu 24.04 explica los parámetros de carga de trabajo. Nunca dirija las pruebas de escritura a un dispositivo de bloques sin procesar que contenga datos útiles.

6. Pruebe la aplicación real al final.

Instale exactamente la misma pila de aplicaciones en ambas máquinas, incluyendo versiones web o de base de datos, límites de conexión, registro, TLS, caché y monitorización. Envíe una combinación de solicitudes equivalente desde un generador de carga independiente, con la misma concurrencia y duración de la prueba. Mida el rendimiento, la latencia de respuesta mediana y del percentil 95, la tasa de errores, la utilización de la CPU, la presión de memoria y el intercambio de memoria. Utilice el mismo conjunto de datos y asegúrese de que ninguna máquina comparta un sistema de almacenamiento con problemas de rendimiento sin tener en cuenta la contención.

Para un servidor API pequeño, una diferencia en la memoria inactiva es relevante si una configuración comienza a usar la memoria virtual durante la carga. Para un proceso con uso intensivo de CPU y abundante RAM disponible, el mismo binario de la aplicación puede ofrecer un rendimiento prácticamente idéntico. Ninguno de estos resultados puede confirmarse sin realizar pruebas.

Cómo interpretar resultados de referencia contradictorios

• Menor cantidad de paquetes pero puntuaciones de CPU iguales: esto es totalmente coherente. Un menor número de herramientas instaladas no tiene por qué cambiar el rendimiento computacional.
• Menor uso del disco pero IOPS iguales: el espacio libre y la velocidad del dispositivo son propiedades diferentes. Analice el hardware de almacenamiento, el patrón de E/S, el sistema de archivos y el almacenamiento en caché.
• Arranque de systemd más rápido, pero preparación de la aplicación igualmente lenta: el cuello de botella puede ser el inicio de la aplicación, las dependencias de red o la recuperación de la base de datos.
• Menos RAM inactiva pero igual latencia de solicitud: la minimización puede ofrecer un margen de capacidad útil, aunque la carga de trabajo actual no está limitada por la memoria.
• Variaciones drásticas en las puntuaciones entre ejecuciones: investigue los procesos vecinos que generan ruido, el escalado de la frecuencia de la CPU, las actualizaciones, las tareas programadas, la limitación térmica y el calentamiento de la caché antes de declarar un ganador.

Si la ventaja medida es solo una pequeña cantidad de espacio en disco inactivo, pero su flujo de trabajo operativo requiere repetidamente utilidades de administración faltantes, la instalación estándar puede ser la opción más productiva. Si sus servidores se aprovisionan automáticamente y ejecutan un servicio estrictamente definido, una base minimizada suele facilitar la auditoría de la selección de paquetes.

¿Deberías minimizar un servidor existente?

Por lo general, no se trata solo de buscar cifras de referencia. Para una instalación estándar que funcione correctamente, primero inspeccione sus servicios activos y evalúe el rendimiento de la aplicación. Eliminar paquetes irrelevantes puede no mejorar una carga de trabajo que ya funciona bien, y la eliminación descuidada de paquetes puede afectar la red, la recuperación, el registro o la administración remota. La guía de seguridad de Ubuntu de Canonical sobre paquetes innecesarios recomienda elegir una instalación inicial mínima adecuada en lugar de eliminar indiscriminadamente los paquetes predeterminados.

Si vale la pena reconstruir el sistema, realice una copia de seguridad de los datos y la configuración, verifique la restauración, instale la opción minimizada en una nueva instancia y aprovisione explícitamente los paquetes necesarios. Valide el acceso SSH, las actualizaciones, la sincronización horaria, las copias de seguridad, la monitorización, la política del firewall y el estado de la aplicación antes de redirigir el tráfico. Si un administrador utiliza habitualmente diagnósticos integrados o desempeña diversas funciones, la instalación estándar puede ser preferible, incluso si su tamaño es mayor.

La seguridad está relacionada, pero es un aspecto distinto: un menor número de paquetes puede reducir la cantidad de software que necesita mantener, pero esto no demuestra una reducción específica de vulnerabilidades (CVE). Ambos tipos de instalación siguen requiriendo actualizaciones de seguridad y refuerzo del servicio.

Lista de verificación final

• Confirme que ambas máquinas sean Ubuntu Server 24.04 LTS con la misma arquitectura, nivel de parches, versión del kernel y generación del instalador.
• Documente la selección de la opción estándar o minimizada, las opciones de instalación opcionales y los servicios añadidos posteriormente.
• Compare la cantidad de paquetes, el uso del sistema de archivos raíz y la memoria disponible después de actualizaciones idénticas y un período de estabilización inactivo.
• Repetir las mediciones de arranque y de disponibilidad de las aplicaciones durante varios reinicios, informando de las medianas en lugar de un único mejor resultado.
• Utilice parámetros coincidentes para las cargas de trabajo de la CPU, el almacenamiento y las aplicaciones, y registre los errores y las distribuciones de latencia.
• Ejecute la aplicación con las mismas dependencias, configuración y datos, y luego decida si alguna diferencia afecta la capacidad, la confiabilidad o el tiempo de implementación.

Conclusión práctica: La configuración minimizada suele ser la mejor opción inicial para servidores automatizados con funciones limitadas; la configuración estándar ofrece un conjunto de herramientas predeterminado más completo. Ninguna de las dos opciones es universalmente más rápida. En Ubuntu Server 24.04 LTS, la prueba de rendimiento más útil es la que mide el servicio bajo la carga de trabajo real que debe gestionar.