- Normalmente se juzga el límite de rendimiento de un servidor con el % de uso de CPU de herramientas de monitoreo como
top, pero en realidad esta métrica no refleja el rendimiento de forma lineal
- En pruebas con stress-ng en un entorno con Ryzen 9 5900X, cuando el uso marcaba 50% la carga de trabajo real llegaba a 60~100%, mostrando una gran brecha con la métrica
- Las principales causas son el hyper-threading y el turbo boost, ya que el uso compartido de recursos entre núcleos lógicos y los cambios en la velocidad de reloj distorsionan la métrica
- Por eso, en lugar de usar solo el uso de CPU, es más preciso comparar un benchmark de la carga de trabajo realmente procesable con el throughput actual
- Si se interpreta el uso de CPU de manera lineal, se pueden producir grandes errores al estimar el rendimiento, por lo que al planificar sistemas se necesita un enfoque basado en benchmarks
Desajuste entre la cifra de uso de CPU del servidor y el throughput real
- Al operar un servidor, mucha gente quiere saber si está cerca de su uso máximo
- Por lo general, se toma como referencia el valor más alto entre uso de red, memoria y CPU mediante herramientas de monitoreo como
top
- Pero en la práctica surge el problema de que la cifra de uso de CPU y la cantidad de trabajo que puede procesarse no aumentan de forma lineal
Entorno y método de prueba
- Experimento basado en Ubuntu Desktop + Ryzen 9 5900X (12 núcleos/24 hilos)
- Precision Boost Overdrive (Turbo) activado
- Simulación de distintas cargas con stress-ng (1~24 workers, 1~100% de uso)
- Métricas medidas: uso de CPU reportado por el sistema y volumen real de cómputo (Bogo ops)
Resumen de resultados
- Carga general de CPU: con 50% de uso, throughput real de 60~65%
- Operaciones enteras de 64 bits: con 50% de uso, throughput real de 65~85%
- Operaciones matriciales (Matrix math): con 50% de uso, throughput real de 80~100%
- En la práctica, aunque los workers adicionales no contribuyan al rendimiento, el uso de CPU sí aumenta
Análisis de causas
-
Hyper-threading
- Estructura de 12 núcleos físicos + 12 núcleos lógicos
- Hasta 12 workers se asignan de forma óptima a los núcleos físicos, pero al superar ese número el uso compartido de núcleos lógicos degrada el rendimiento
- En especial, en operaciones SIMD (operaciones matriciales) no hay recursos compartidos disponibles, así que no puede mejorar el rendimiento
-
Turbo boost
- Con poca carga: 4.9GHz → con carga total: 4.3GHz, una caída de reloj del 15%
- Esto distorsiona la fórmula de cálculo del uso de CPU (= busy cycles / total cycles)
- Al reducirse el denominador (ciclos totales), el aumento del uso se sobreestima frente a la carga de trabajo real
Implicaciones
- El uso de CPU no es una métrica absoluta de rendimiento
- Al dimensionar capacidad de servidores y predecir rendimiento:
- 1. Medir el throughput máximo con benchmarks
- 2. Monitorear el throughput en tiempo real
- 3. Comparar ambos valores para determinar si se está cerca del límite de rendimiento
- Como la variación es grande según la arquitectura de CPU (AMD vs Intel), la eficiencia del hyper-threading y la forma en que actúa el turbo, se necesita un análisis por procesador
Conclusión
- El uso de CPU es simplemente la proporción de ciclos ocupados, y no refleja con precisión el rendimiento real de procesamiento
- Incluso con un “50% de uso”, si se aprovecha eficientemente, el sistema ya podría estar en 80~100% de su rendimiento máximo
- Por lo tanto, el monitoreo de rendimiento y la planificación del sistema deben centrarse en el throughput de trabajo basado en benchmarks en lugar del uso de CPU
Aún no hay comentarios.