Por qué su nuevo servidor da peores benchmarks que el antiguo, sin ser más lento.
Un bogomips más bajo tras una migración no es un servidor más lento, es un artefacto de la virtualización. Qué mide realmente, y cómo se pone a prueba el trabajo real.
En este artículo 5 secciones
Una pregunta habitual tras una migración es si un bogomips más bajo significa un servidor más lento. No lo significa. Así es como la respondimos.
- Un cliente recién migrado a nuestra plataforma notó que un valor llamado bogomips salía más bajo que en su máquina antigua, y preguntó si el nuevo servidor era más lento.
- El bogomips no mide nada que usted quisiera comprar. Es un bucle de calibración que el kernel ejecuta al arrancar para dimensionar sus propios retardos internos. En un host virtual refleja el reloj presentado al guest, mientras el núcleo físico de debajo sigue funcionando a turbo pleno.
- No se fíe del dato sustituto a ciegas. Ejecute usted mismo los benchmarks reales, cargas criptográficas y de cómputo, en las dos máquinas: una generación de procesador más nueva es más rápida, con instrucciones más anchas. El trabajo real responde a la pregunta.
- La lección: una medición vale lo que vale aquello que mide. No discuta el dato sustituto. Diga qué mide realmente, y deje que el trabajo real lo zanje.
El número detrás de la pregunta
Había comparado el bogomips en su máquina antigua y en la nueva, y la lectura nueva salió más baja. Leído al pie de la letra, parece una pérdida. No lo es, y para ver por qué hay que saber qué es ese número.
$ grep -m1 bogomips /proc/cpuinfoQué mide realmente el bogomips
El bogomips no es un benchmark. Es un bucle de calibración que el kernel ejecuta una vez al arrancar para dimensionar sus propios retardos internos de temporización, de modo que sepa aproximadamente cuántos busy-loops caben en un intervalo dado. El nombre es una broma que los desarrolladores del kernel hicieron a su propia costa: bogus millions of instructions per second. En un host virtualizado el número es más bogus de lo habitual, porque refleja el reloj presentado al guest, el valor que el hipervisor le entrega a la VM, mientras el núcleo físico de debajo sigue funcionando a turbo pleno. Un bogomips más bajo es una rareza de cómo la virtualización expone el reloj, no la pérdida de nada real.
“El bogomips no mide nada que usted quisiera comprar.”
La lectura bajó. El silicio no.
El dato sustituto frente al trabajo real
Toda discusión del tipo «mi servidor se ha vuelto más lento» es en realidad una pelea sobre qué eligió medir. Ponga el dato sustituto junto al trabajo y la pelea se acaba.
| EL DATO SUSTITUTO: BOGOMIPS | EL TRABAJO REAL: UN BENCHMARK | |
|---|---|---|
| Qué es realmente | Un bucle de calibración que el kernel ejecuta una vez al arrancar para dimensionar sus propios retardos de temporización | Cargas criptográficas y de cómputo que representan lo que hace su aplicación bajo carga |
| Qué lee en un host virtual | El reloj presentado al guest, un número que el hipervisor le entrega a la VM | Instrucciones ejecutadas en el núcleo físico, que sigue funcionando a turbo pleno |
| THE ONE THAT MATTERS¿Cambia cuando el hardware es más nuevo? | No de forma fiable. Sigue un valor de reloj virtualizado, no el silicio | Sí. Una generación más nueva con instrucciones más anchas hace más por ciclo |
| Cuándo se mide | Una vez, al arrancar, y nunca más | Bajo demanda, tantas veces como quiera, por usted |
| ¿Se puede comprar? | Nadie vende bogomips, y ningún usuario ha sentido nunca uno | Sí. Es el trabajo que usted paga para que se haga más rápido |
Mida el trabajo, no el dato sustituto
La jugada perdedora es decir que el bogomips no significa nada y dejarlo ahí, porque le pide a un cliente que cambie su número por nuestra palabra. Así que hicimos lo contrario. Dijimos qué mide realmente el bogomips, y después le entregamos los benchmarks para que los ejecutara él mismo: cargas criptográficas y de cómputo reales, de las que representan lo que hace realmente una aplicación. Añadimos una nota. La generación de procesador más nueva bajo su VM es más rápida, con instrucciones más anchas, así que el trabajo real muy probablemente saldría por delante, no por detrás.
# stop measuring the proxy. measure the work.
$ openssl speed -evp aes-256-gcm # cryptographic throughput
$ sysbench cpu --cpu-max-prime=20000 run # raw CPU work
# run on the old box and the new one, then compare the work, not the clock.Mida el trabajo, no el reloj
: Elija cargas que se parezcan a su aplicación. El rendimiento criptográfico y una prueba de CPU son un comienzo justo y honesto. Bogomips, MHz y «puntuaciones» de un solo número son datos sustitutos. Sáltelos.
Ejecute comandos idénticos en las dos máquinas
: Lo único que compara es cuánto trabajo real termina cada una en el mismo tiempo de reloj.
Deje que el resultado lo zanje
: Si la máquina nueva hace más trabajo, la migración fue una mejora y la lectura del bogomips era ruido. Si realmente hace menos, ahora tiene un número real, y ahora tenemos algo que merece la pena investigar juntos.
La lección
Una medición vale lo que vale aquello que realmente mide. Cuando un cliente llega con un dato sustituto, la jugada no es discutir el número. Es decir qué mide realmente ese número, y después dejar que el trabajo real lo zanje. La máquina de debajo estuvo tranquila y rápida todo el tiempo. Lo único que se volvió más lento fue el benchmark.
Respuestas directas
¿Es un problema un bogomips más bajo en mi nuevo servidor?+
Casi nunca. El bogomips es un bucle de calibración del kernel al arrancar, no un benchmark de rendimiento. En una máquina virtual refleja el reloj presentado al guest, mientras el núcleo físico de debajo puede seguir funcionando a turbo pleno. Una lectura más baja suele ser un artefacto de la virtualización, no rendimiento perdido.
¿Por qué el bogomips es más bajo en una máquina virtual o tras pasar a un VPS?+
Porque el hipervisor presenta un valor de reloj al guest, y el kernel se calibra contra ese número presentado al arrancar. El núcleo físico sigue funcionando a su velocidad turbo real, a menudo más alta. La lectura cambió. El silicio no.
Mi nuevo servidor parece más lento tras migrar. ¿Qué compruebo primero?+
Primero, confirme que está midiendo el trabajo y no un dato sustituto como bogomips, MHz de reloj o una puntuación sintética de un solo número. Después compruebe los verdaderos culpables de nuestro playbook de diagnóstico: latencia de las consultas de base de datos, profundidad de la cola de disco, saturación de los workers PHP, o espera de red. Tras una migración, lo primero que comprobamos es si cambió la métrica, no la máquina.
¿Cómo sé realmente si mi nuevo servidor es más lento?+
Ejecute el trabajo, no el dato sustituto. Haga benchmarks de cargas que se parezcan a su aplicación, una prueba de rendimiento criptográfico (openssl speed) y una prueba de CPU (sysbench), y ejecute comandos idénticos en las dos máquinas. El trabajo real lo zanja en minutos.
¿Una frecuencia de reloj más baja en la nueva CPU no es un retroceso?+
No por sí sola. La frecuencia es una entrada. Una generación más nueva con instrucciones más anchas hace más trabajo por ciclo, así que puede terminar antes a un reloj nominal más bajo. Exactamente por eso una lectura de un solo número le engaña.
Acabo de migrar y algo parece más lento. ¿Me ayudan a comprobarlo?+
Sí. Envíenos el número. Le diremos qué mide realmente, y le entregaremos el benchmark para que lo ejecute usted mismo. Si el trabajo real es realmente más lento, eso es un ticket de verdad y lo investigaremos con usted. Si no lo es, tendrá la prueba en un par de minutos.
¿Acaba de migrar, y algo parece más lento?
Envíenos el número y le diremos qué mide. No hace falta que se fíe de nosotros.
Hable con un ingenieroHa llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero