SLES 15 vs. RHEL 9: Comparativa del rendimiento de servidores empresariales

No existe un ganador universal en rendimiento entre SUSE Linux Enterprise Server 15 y Red Hat Enterprise Linux 9. Una respuesta fundamentada depende del Service Pack o la versión menor, el hardware, las actualizaciones del kernel, el perfil de optimización, la pila de aplicaciones y la carga de trabajo. La guía de optimización actual de SUSE SLES 15 SP7 y la documentación de RHEL 9 de Red Hat describen las capacidades de optimización; no establecen un resultado de velocidad comparativo general y controlado.

Esta distinción es importante porque la documentación de SLES 15 SP7 identifica una base de kernel Linux 6.4, mientras que Red Hat documenta RHEL 9 como basada en el kernel 5.14 e indica que incorpora cambios más recientes a su flujo de kernel. Estas etiquetas de versión por sí solas no permiten predecir qué distribución ejecutará una base de datos, un servicio web o una máquina virtual más rápido. Considérelas como información del producto y luego realice pruebas de rendimiento con la carga de trabajo que realmente planea ejecutar.

¿Qué se puede verificar sobre SLES 15 y RHEL 9?

Antes de comparar las máquinas, registre las versiones instaladas exactas y el perfil activo en cada una. Por ejemplo, recopile cat /etc/os-release, uname -r, y sudo tuned-adm active. Utilice la versión mostrada en lugar del nombre comercial “SLES 15” o “RHEL 9” como etiqueta de prueba.

¿La base de kernel más reciente de SLES 15 SP7 lo hace más rápido que RHEL 9?

No por sí solo. Las versiones base del kernel no constituyen una puntuación de referencia. Red Hat mantiene una rama estable del kernel de lanzamiento principal e incorpora correcciones y características seleccionadas; por lo tanto, un kernel de RHEL 9 que reporta la versión 5.14 puede contener funcionalidades de versiones más recientes. SUSE también mantiene y actualiza su propia rama del kernel compatible. El comportamiento de la aplicación depende de las correcciones, los controladores, la compatibilidad de hardware, la configuración y la ruta de código que ejecuta la carga de trabajo.

Acción: registre la versión completa del paquete del kernel y el nivel de lanzamiento para ambos sistemas de prueba. Al investigar una característica o controlador, revise las notas de lanzamiento y la matriz de soporte de cada proveedor para ese lanzamiento exacto en lugar de comparar solo los dos primeros números de uname -r.

¿Son equivalentes los perfiles TuneD predeterminados?

No se debe asumir la equivalencia. TuneD existe en ambos ecosistemas, pero el conjunto de perfiles instalados, la recomendación automática, el contenido de los perfiles y las anulaciones locales pueden diferir. La guía de SUSE para SLES 15 SP7 describe las recomendaciones de perfiles según la configuración del sistema. La documentación de Red Hat para RHEL 9 también indica que la selección automática de perfiles depende del tipo de máquina y la configuración del sistema. Incluso si ambos hosts informan un perfil con el mismo nombre, verifique qué cambios introduce antes de considerar las configuraciones como idénticas.

Acción: ejecutar sudo tuned-adm activeen sudo tuned-adm listcada host. Guardar la salida y los archivos de perfil personalizados. Para una comparación de "instalación predeterminada", conservar la configuración predeterminada compatible de cada proveedor y documentarla. Para una comparación de "mejor rendimiento posible", optimizar cada sistema operativo por separado siguiendo las instrucciones del proveedor y, a continuación, informar sobre los perfiles y la configuración utilizados.

No aplique todos los perfiles de rendimiento a la vez. Los perfiles pueden entrar en conflicto; por ejemplo, una configuración de almacenamiento orientada al rendimiento puede verse afectada por otra que aumente el tiempo de inactividad del disco. Modifique una variable relevante a la vez, confirme que el servicio se mantiene estable y guarde un registro de reversión.

¿Qué sistema tiene más probabilidades de ofrecer un mejor rendimiento para su carga de trabajo?

La carga de trabajo suele ser más importante que una etiqueta de distribución genérica. Se trata de prioridades de prueba, no de promesas sobre qué proveedor ganará:

• Aplicaciones con uso intensivo de CPU: utilice el compilador, el entorno de ejecución, las bibliotecas y la configuración de seguridad de producción. Mida el trabajo completado por segundo y el tiempo de CPU. Una microprueba de rendimiento puede ayudar a explicar una diferencia, pero no sustituye a una prueba de aplicación.
• Bases de datos y servicios que consumen mucha memoria: utilice una versión, esquema, tamaño del conjunto de trabajo, concurrencia y política de persistencia representativos de la base de datos. Realice un seguimiento de las transacciones por segundo junto con la latencia media y la latencia de cola; una tasa media más alta puede ocultar solicitudes más lentas.
• Servicios que requieren un uso intensivo de almacenamiento: mantenga el mismo modelo de unidad, firmware del controlador, sistema de archivos, opciones de montaje, conjunto de datos y profundidad de la cola. Mida la combinación real de lectura/escritura y la distribución de la latencia, no solo el rendimiento secuencial máximo.
• Servicios de red: mantenga la configuración de la tarjeta de red, el firmware, la ruta del conmutador, la MTU, la configuración de descarga y la carga del cliente consistentes. Mida el rendimiento y la latencia de la aplicación con el número de conexiones previsto.
• Máquinas virtuales o contenedores: comparar en el mismo hipervisor o pila de contenedores, con la misma asignación de CPU y memoria, políticas de host, perfil de invitado e imagen. Incluir la densidad y la contención de recursos si esto refleja un entorno de producción.
• Sistemas sensibles al consumo de energía: informan la energía por unidad de trabajo completada, no solo la velocidad máxima. Un sistema que consume menos energía pero tarda más tiempo puede no consumir menos energía total para un trabajo por lotes.

Si desconoce el destino del tiempo, analice el rendimiento de la aplicación o supervise la CPU, la presión sobre la memoria, el tiempo de espera de E/S, la saturación de la red y las colas de ejecución antes de optimizar el sistema. De lo contrario, un rendimiento de CPU más rápido no solucionará un cuello de botella en el almacenamiento.

¿Cómo se debe realizar una comparación justa?

Primero, decide qué pregunta estás respondiendo. "¿Qué sistema es más rápido inmediatamente después de la instalación?" es diferente de "¿Qué sistema es más rápido después de la optimización de producción compatible?". No compares la configuración optimizada de una distribución con la configuración predeterminada de otra y llames al resultado una comparación de sistemas operativos.

1. Asegúrese de que la plataforma sea la misma: utilice modelos de servidor idénticos siempre que sea posible, con la misma revisión de CPU, cantidad de memoria, BIOS/firmware, almacenamiento, tarjeta de red y límites de potencia.
2. Congele los detalles del software: anote el nivel de actualización y paquete de servicio de SLES, el nivel de actualización y la versión menor de RHEL, el paquete del kernel, la versión de la aplicación, el entorno de ejecución/compilador, el firmware y las medidas de seguridad pertinentes.
3. Configuración de control: registre los perfiles de TuneD, el gobernador de la CPU o el modo de energía, la configuración de NUMA y páginas grandes, las opciones de sistema de archivos y montaje, y los parámetros de la aplicación. Manténgalos con los valores predeterminados para una prueba sin configuración adicional o ajuste ambos sistemas específicamente para una prueba optimizada.
4. Utilice datos y carga similares a los de producción: haga que la prueba sea lo suficientemente larga como para alcanzar un comportamiento estable e incluya la concurrencia y el tamaño de los datos relevantes. Defina el estado de la caché y el procedimiento de calentamiento para que cada ejecución comience de forma comparable.
5. Repetir y reportar variaciones: alternar el orden de las pruebas cuando sea posible, repetir las ejecuciones y mostrar la mediana más la dispersión entre ejecuciones. Reportar el rendimiento junto con la latencia p95/p99, el consumo de recursos y los errores cuando corresponda.
6. Mantenga un registro reproducible: publique la configuración del sistema, la versión de la prueba de rendimiento, los comandos o scripts, las diferencias de ajuste y los resultados brutos. Si el resultado corresponde a una prueba de rendimiento pública estandarizada, siga las normas de presentación de informes vigentes de dicha prueba.

Las normas SPEC para CPU 2017 exigen la divulgación completa de las condiciones relevantes para el rendimiento y suficientes detalles de configuración para reproducir un resultado público. Este es un estándar útil incluso al probar una carga de trabajo interna. Un benchmark con una única puntuación sin explicación no es suficiente para determinar si el resultado se debe al sistema operativo, a las opciones del compilador, a la configuración de la BIOS o a un hardware diferente.

¿Qué se sabe, qué depende de tu configuración y qué queda por comprobar?

• Información conocida: la documentación actual de SLES 15 SP7 y RHEL 9 describe diferentes flujos del kernel y configuraciones de rendimiento basadas en TuneD. Ambos proveedores documentan herramientas para la optimización específica de la carga de trabajo.
• Depende del entorno: rendimiento, latencia, consumo de energía, tiempo de arranque, densidad de máquinas virtuales, comportamiento del controlador y el esfuerzo necesario para mantener la configuración constante. Estos factores varían según el hardware, la aplicación, la versión y la política operativa.
• La documentación revisada no establece que SLES 15 sea categóricamente más rápido que RHEL 9, que RHEL 9 sea categóricamente más rápido que SLES 15, ni que una versión base del kernel garantice una ventaja de rendimiento para cada carga de trabajo.

Seleccione la distribución que cumpla con sus requisitos de certificación, soporte, ciclo de vida y operación, y luego valide el rendimiento con una prueba de concepto controlada. Si la diferencia medida es menor que la variación entre ejecuciones, considere que los sistemas tienen el mismo rendimiento para esa carga de trabajo y tome una decisión en función de la capacidad de soporte, la compatibilidad y las necesidades de administración.

Referencias oficiales

• SUSE: Guía de análisis y optimización del sistema SLES 15 SP7
• SUSE: Notas de la versión SLES 15 SP7
• Red Hat: Gestión, monitorización y actualización del kernel de RHEL 9
• Red Hat: Primeros pasos con TuneD en RHEL 9
• Red Hat: Personalización de perfiles TuneD
• ESPECIFICACIONES: Reglas de ejecución e informes de la CPU 2017
• ESPECIFICACIONES: Descripción general y uso justo de la CPU 2017