IPC y frecuencia de reloj de la CPU: cómo comparar correctamente los procesadores para servidores

IPC de la CPU: instrucciones por ciclo de reloj

IPC de la CPU Significa «Instructions per Cycle», es decir, instrucciones por ciclo de reloj. Para un intervalo de medición delimitado, normalmente se divide el número de instrucciones de máquina completadas entre el número de ciclos de CPU contados en ese mismo intervalo. Un IPC de 2 significa, en este contexto, una media de dos instrucciones completadas por cada ciclo contado.

El valor es un Característica del modelo, no es un indicador fijo para todas las tareas de un procesador. El mismo sistema puede alcanzar un IPC diferente en un cálculo con datos fácilmente disponibles que en una consulta a una base de datos, que a menudo tiene que esperar a que lleguen los datos de la memoria principal. El conjunto de datos concreto y el fragmento de programa en cuestión también influyen en el resultado.

Una caché almacena los datos de uso frecuente cerca de la CPU. Si, en cambio, un núcleo tiene que esperar a que se realicen accesos más lentos a la memoria, las unidades de ejecución pueden quedar inactivas temporalmente. Del mismo modo, las dependencias entre instrucciones y las ramificaciones en el flujo del programa influyen en la cantidad de trabajo que se puede ejecutar simultáneamente. Por lo tanto, un IPC bajo es motivo para seguir investigando, pero no constituye aún un diagnóstico definitivo.

Además, una instrucción de máquina no es una unidad estandarizada que corresponda a una solicitud web completada. El compilador, el conjunto de instrucciones y la vectorización pueden hacer que programas distintos necesiten un número diferente de instrucciones para realizar la misma tarea. Por lo tanto, un IPC más alto por sí solo no garantiza ni un tiempo de respuesta más corto ni un mayor número de solicitudes por segundo.

Para poder comparar, es fundamental saber qué aplicación y qué rango de medición hay detrás de ese valor. Una cifra IPC sin estos datos no permite saber si los sistemas realizan realmente el mismo trabajo. Encontrarás más información básica sobre la interacción entre la frecuencia de reloj, los núcleos y la jerarquía de memoria en el artículo sobre Arquitectura de la CPU en el alojamiento web.

Entender la frecuencia de reloj del servidor y el «boost»

La frecuencia de reloj describe el número de ciclos que realiza una CPU por segundo. Un gigahercio, o GHz, equivale a mil millones de ciclos por segundo. Por sí solo, este valor no indica cuántas instrucciones ejecuta un programa en esos ciclos ni cuánto trabajo útil realiza con ellas.

En las fichas técnicas suele aparecer una Frecuencia fundamental y un aumento máximo. La frecuencia base sirve como valor de referencia; el aumento indica una frecuencia más alta posible en condiciones adecuadas. Ninguno de estos datos sustituye a la observación de la frecuencia real alcanzada durante el uso concreto y con la carga correspondiente.

Un ejemplo es el AMD EPYC 9655: para este modelo, AMD indica 96 núcleos, 192 subprocesos, una frecuencia base de 2,6 GHz y una frecuencia máxima de hasta 4,5 GHz. Estos valores describen las características y las especificaciones de frecuencia del procesador. No se trata ni de un IPC medido ni de una prueba de un rendimiento de alojamiento concreto.

Para la serie EPYC 9005, AMD define el impulso máximo como la frecuencia máxima que puede alcanzar un único núcleo en condiciones normales de funcionamiento del servidor. Por lo tanto, los hasta 4,5 GHz del 9655 no garantizan que los 96 núcleos mantengan esta frecuencia de forma permanente. Los límites de potencia y temperatura influyen en el comportamiento bajo carga.

Para una tarea individual breve, puede ser relevante una frecuencia temporalmente más alta; en cambio, en el caso de una carga paralela prolongada, lo que interesa es la potencia que el sistema proporciona durante todo el tiempo de funcionamiento. Otros modelos de la serie tienen frecuencias y número de núcleos diferentes. Una comparación basada únicamente en el valor más alto en GHz pasaría por alto estas diferencias y la aplicación concreta.

Núcleos, subprocesos y CPU virtuales

En términos sencillos, un proceso es una instancia de programa en ejecución. En él, uno o varios subprocesos ejecutan instrucciones. Un núcleo físico de la CPU cuenta con el hardware necesario para llevar a cabo dicha tarea; los sistemas operativos detectan, en función del procesador, uno o varios subprocesos lógicos de la CPU por núcleo. Los subprocesos lógicos de un mismo núcleo comparten parte de su hardware.

Una tarea con una parte muy secuencial no puede distribuir esa parte entre tantos núcleos como se desee. En ese caso, lo importante es la rapidez con la que el hilo de ejecución realiza el trabajo concreto. Por el contrario, las solicitudes web independientes suelen poder procesarse en paralelo: en ese caso, los núcleos adicionales disponibles pueden contribuir al rendimiento total, siempre que no haya otros recursos que lo limiten.

El número de subprocesos lógicos no debe equipararse al número de núcleos físicos independientes. El EPYC 9655, por ejemplo, tiene 96 núcleos físicos y 192 subprocesos, según el fabricante. El hecho de que haya 192 subprocesos no implica ni que el rendimiento se duplique con respecto a los 96 subprocesos, ni que se alcance un rendimiento concreto para un servidor web.

En el caso de un servidor virtual, el proveedor proporciona al sistema operativo invitado vCPU Listo. Una vCPU no es necesariamente un núcleo físico de uso exclusivo: su asignación al hardware del host puede variar en función de la oferta, y el tiempo de procesamiento puede compartirse con otros invitados o estar limitado por restricciones.

Pregunta previa a la selección sobre la asignación concreta de recursos: ¿El tiempo de CPU está garantizado o se comparte? ¿Existen límites de rendimiento permanentes y cómo se asignan las vCPU? Un número elevado de vCPU solo ayuda a una aplicación paralela en la medida en que realmente haya suficiente tiempo de cálculo disponible; para una sección en serie, no sustituye a una ejecución rápida en un hilo.

Calcular conjuntamente el IPC y la frecuencia de reloj

El IPC y la frecuencia de reloj describen diferentes aspectos del rendimiento de la CPU. Para un rango de medición adecuadamente delimitado, su efecto puede relacionarse de forma aproximada: Instrucciones por segundo corresponden al IPC multiplicado por los ciclos efectivos de la CPU por segundo. El IPC se refiere a las instrucciones completadas y a los ciclos contados en el mismo intervalo.

Ejemplo ilustrativo de cálculo, no se trata de una medición: si se supone un valor constante de 2,0 instrucciones por ciclo y 3,0 GHz, el cálculo da como resultado 6,0 mil millones de instrucciones por segundo. Incluso con un IPC de 1,5 a 4,0 GHz se obtienen 6.000 millones. En este ejemplo, la mayor frecuencia de reloj compensa, por tanto, el menor IPC en el cálculo.

Sin embargo, el hecho de que las tasas de instrucciones sean iguales no significa que ambos sistemas procesen el mismo número de solicitudes web. Para una misma tarea, los programas pueden necesitar un número diferente de instrucciones en función del compilador, el conjunto de instrucciones y las instrucciones utilizadas. Por lo tanto, una instrucción no equivale a una cantidad uniforme de trabajo realizado por la aplicación.

El tiempo de respuesta de una página web tampoco se puede deducir directamente del producto. Un hilo puede estar esperando datos del soporte de almacenamiento o una respuesta de la red; mientras tanto, su tasa de instrucciones no explica todo el tiempo transcurrido. En el caso de una máquina virtual, hay que tener en cuenta además que no siempre dispone de tiempo de CPU.

Por lo tanto, para poder realizar una comparación, debe quedar claro qué código y qué periodo de tiempo se han tenido en cuenta. La fórmula ayuda a clasificar la ejecución activa; para tomar una decisión sobre el alojamiento, también es necesario disponer de las tareas completadas y sus tiempos de respuesta en un perfil de solicitudes comparable.

Clasificar la ficha técnica y las cifras clave

Una ficha técnica ofrece datos útiles para elegir una CPU de alojamiento web. Sin embargo, los datos responden a cuestiones diferentes: el IPC describe un comportamiento en el rango de medición correspondiente, mientras que los datos de frecuencia y el número de núcleos especifican las características de un modelo de procesador. Solo cuando se tienen en cuenta junto con la aplicación se convierten en criterios de comparación útiles.

El EPYC 9655 muestra cómo se relacionan entre sí estos datos: según AMD, el modelo cuenta con 96 núcleos y 192 hilos, una frecuencia base de 2,6 GHz y una frecuencia máxima de hasta 4,5 GHz. Los 4,5 GHz no son una frecuencia garantizada para todos los núcleos bajo carga continua ni un rendimiento de alojamiento medido.

Una clasificación basada en la frecuencia máxima en GHz ocultaría la cantidad de trabajo que realizan los distintos procesadores por ciclo y por tarea. Por el contrario, una clasificación basada en el número de núcleos pasa por alto el hecho de que no todas las aplicaciones pueden distribuir su trabajo en paralelo con la misma eficacia. Ambos datos son puntos de partida, no valoraciones definitivas del rendimiento.

Por eso, cuando veas ofertas, presta atención a la Variante del modelo y de qué recursos se pueden utilizar realmente. Para realizar una comparación fiable, también necesitas un perfil de carga adecuado y resultados obtenidos con un software y una configuración comparables. Las especificaciones de los distintos modelos no deben confundirse con un valor máximo supuesto para toda la familia de productos.

Seleccionar la CPU del alojamiento según el perfil de carga

La elección de la CPU adecuada para el alojamiento web depende de las funciones que deba realizar el servidor. Una tarea única de larga duración plantea requisitos distintos a los de numerosas solicitudes web independientes. La tabla traduce los perfiles de carga típicos en un parámetro clave y una pregunta que conviene aclarar antes de realizar la selección.

En el caso de una tarea individual, el rendimiento del hilo que la ejecuta es especialmente importante cuando una parte considerable del trabajo se ejecuta en serie. Un mayor número de núcleos no acorta automáticamente esta parte. Un breve pico de rendimiento máximo tampoco basta como prueba para una tarea de larga duración: lo decisivo es su tiempo de ejecución medido en las condiciones previstas.

En cambio, se pueden procesar muchas consultas independientes en paralelo. En este caso, además del rendimiento por hilo, lo que cuenta es cuántos recursos están disponibles al mismo tiempo y cómo evolucionan los tiempos de respuesta a medida que aumenta la carga. La suma de los valores nominales en GHz no sustituye a una comparación del Rendimiento total con el mismo grado de paralelismo.

En una base de datos con un conjunto de datos de trabajo de gran tamaño, los accesos a la memoria pueden ralentizar la ejecución si los datos necesarios no se obtienen de forma eficaz de las cachés. Un IPC bajo puede ser motivo para realizar más análisis, pero por sí solo no demuestra que exista un cuello de botella en la memoria. Por lo tanto, comprueba también las consultas, el conjunto de datos y la configuración de la memoria antes de cambiar la CPU.

En el caso del VPS, además, la Compromiso de recursos Es fundamental: una vCPU no es automáticamente un núcleo físico exclusivo. Hay que informarse sobre la asignación, los posibles límites de la CPU y el uso compartido con otros invitados. Solo con estos datos se puede comparar de forma significativa una prueba de aplicación con una oferta en un servidor dedicado.

Planificar pruebas de aplicación comparables

Una comparación significativa parte de tu aplicación, no de una cifra aislada de la CPU. Establece la misma versión de software, el mismo conjunto de datos y la misma configuración para ambas ofertas de alojamiento. SPEC considera que la propia aplicación en la propia infraestructura es el criterio ideal para la selección de productos.

A continuación, define un Perfil de la solicitud, que refleje lo mejor posible el uso posterior: por ejemplo, qué páginas o puntos finales de la API se acceden y cuántas solicitudes se reciben simultáneamente. Mantén comparables los niveles de paralelismo y los límites de recursos entre las ejecuciones. Si una oferta establece otros límites, documéntalos expresamente, en lugar de atribuir la diferencia únicamente a la CPU.

Prevé una fase de calentamiento para que, por ejemplo, la aplicación se haya iniciado y las cachés puedan llenarse. A continuación, realizar varias ejecuciones de duración suficiente ayudará a distinguir las fluctuaciones a corto plazo de una diferencia recurrente. Documenta también si durante la medición se estaban ejecutando otras tareas en los sistemas.

Registra, además del rendimiento, el Distribución de los tiempos de respuesta y los errores. Un promedio más alto de solicitudes completadas por segundo no sirve de mucho por sí solo si algunas solicitudes tardan mucho en procesarse o fallan con frecuencia. Por eso, compara también los percentiles altos del tiempo de respuesta con el mismo nivel de paralelismo.

Los resultados publicados de SPEC-CPU2017 pueden servir como referencia adicional. SPECspeed mide el tiempo necesario para realizar las tareas, mientras que SPECrate mide el rendimiento; ambas métricas no son directamente intercambiables entre sí. Compara resultados de la misma métrica y ten en cuenta la configuración del sistema y el software. La suite de CPU no refleja la red ni las E/S de un servicio de alojamiento completo.

Comprobar el IPC y la frecuencia durante el funcionamiento

Para crear tu propio entorno de pruebas en Linux, puedes registrar con «perf» las instrucciones y los ciclos completados de un programa existente y comprobado. En el siguiente ejemplo, testprogramm Un marcador de posición: sustitúyelo por tu programa de prueba y, si procede, por sus argumentos. El comando es una sugerencia de medición, no una prueba ya realizada.

perf stat -e '{instructions,cycles}' -- testprogramm

Las llaves resumen los acontecimientos en una Grupo de contadores juntas. Deben registrarse simultáneamente, lo que puede reducir los errores derivados del multiplexado con desfase temporal. Divide las instrucciones contadas entre los ciclos contados para obtener el IPC de ese intervalo de medición; «perf» también puede mostrar este valor directamente.

La disponibilidad de los eventos y la posibilidad de consultarlos dependen del hardware, el núcleo, los permisos y, en su caso, el entorno de virtualización. Un grupo de eventos que no esté disponible o que no se pueda contabilizar de forma conjunta no permite realizar una comparación fiable. No modifiques la configuración de seguridad únicamente para este ejemplo.

Una indicación de frecuencia también necesita contexto: scaling_cur_freq Según la documentación del núcleo, en muchos casos corresponde al último estado solicitado por el controlador y no necesariamente a la frecuencia de hardware realmente alcanzada. El valor, que no está disponible en todos los casos, cpuinfo_cur_freq por su parte, debe mostrar la frecuencia actual detectada por el hardware. Más información sobre Regulador de la CPU en servidores de alojamiento explica el funcionamiento del escalado de frecuencia.

Un IPC bajo es un indicio de que hay que seguir investigando, pero no constituye un diagnóstico definitivo. Los accesos a la memoria pueden ralentizar la ejecución; asimismo, hay que comprobar qué parte del programa se ha medido y si existen otros factores que influyan. Por lo tanto, compara el valor del contador con el comportamiento de la aplicación y su acceso a los datos.

Detectar el cuello de botella y decidir la actualización

Empieza por un síntoma concreto: ¿las consultas se ralentizan bajo carga, aumenta la tasa de errores o una tarea concreta tarda demasiado en completarse? Anota cuándo se produce el problema y qué tareas se están ejecutando al mismo tiempo. Solo así se podrá comprobar si un mayor rendimiento de la CPU puede, de hecho, reducir ese retraso concreto.

Comprueba primero el espacio disponible y el utilizado tiempo de CPU. Una tarea que requiere un esfuerzo computacional constante puede beneficiarse de una ejecución más rápida o de un mayor paralelismo aprovechable. Sin embargo, una elevada carga de trabajo por sí sola no explica qué código la provoca, ni si el tiempo de respuesta se debe principalmente a ella. Por lo tanto, compara este hallazgo con el rendimiento y los tiempos de respuesta de la misma fase de carga.

A continuación, analiza las necesidades de memoria y los accesos a los datos. Si una base de datos tiene que acceder con frecuencia a datos que se encuentran fuera de la caché de la CPU, puede que tenga que esperar a que la memoria los proporcione; un IPC bajo puede ser un indicio de ello, pero no prueba la causa. La escasez de memoria RAM, los accesos a dispositivos de almacenamiento o la lentitud de los servicios externos también pueden influir en el retraso observado.

En un VPS, la Compromiso de recursos En cuanto al diagnóstico: consulta sobre la asignación de las vCPU, los posibles límites de la CPU y el reparto con otros invitados. Un servidor dedicado ofrece una asignación diferente de los recursos físicos, pero también en este caso la aplicación, la configuración y el perfil de carga determinan el resultado. Compara ambas ofertas, a ser posible, con la misma prueba de aplicación.

Plantéate actualizar la CPU si las mediciones indican que existe un cuello de botella en la CPU y la nueva tarifa proporciona realmente el tiempo de cálculo necesario. Si el retraso se debe principalmente a la memoria, al disco duro o a un servicio externo, tiene más sentido investigar en esos ámbitos. Anota el estado inicial para poder evaluar posteriormente cualquier cambio de forma comparable.

No interpretes los datos de «boost» máximo como una frecuencia continua garantizada para todos los núcleos, ni un valor de IPC como una característica universal de la CPU. Del mismo modo, una sola cifra de utilización no basta para realizar un diagnóstico completo de los cuellos de botella. La decisión se toma en función de la tarea concreta y de los recursos realmente disponibles, no en función de un único valor máximo.