Cuando configuro un punto de referencia y quiero medir la eficiencia de la CPU de algo, encuentro que a menudo es una buena opción ejecutar un programa de punto de referencia, así como la base de datos, en el mismo servidor. Esto es para eliminar el impacto de la red y mantener el rendimiento de un solo hilo, para eliminar la disputa.

Por lo general, este enfoque da resultados bastante estables; por ejemplo, comparando MySQL con Sysbench OLTP Carga de trabajo de solo lectura Tengo una variación de menú del uno por ciento entre ejecuciones de 1 minuto.

En este caso, sin embargo, he visto algunos 20 por ciento de diferencia entre carreras, que parecía bastante aleatorio y no funcionaba ni siquiera con carreras de más de 10 minutos.

El punto de referencia que hice fue evaluar MySQL a través de ProxySQL (todos ejecutándose en la misma máquina):

Sysbench -> ProxySQL -> MySQL

Mientras pensaba más en las posibles razones, pensé que la programación de la CPU podría ser un problema. ¿Cómo van las solicitudes de un proceso a otro, las solicitudes de programación del Kernel de Linux al mismo núcleo de CPU u otro? Aunque solo un proceso puede estar realmente ocupado procesando una solicitud a la vez en esta configuración, existe el problema del uso de la memoria caché de la CPU, así como otras implicaciones de programar el trabajo en el núcleo, CPU única u otra.

Para validar mis suposiciones, utilicé conjunto de tareasuna pequeña utilidad disponible en las distribuciones modernas de Linux, que permite mapear un proceso de afinidad de CPU establecido, esencialmente mapeándolo a algunos de los núcleos de CPU.

Configuré MySQL y ProxySQL para que se limiten a diferentes núcleos de CPU:

Y también ejecute sysbench vinculado al núcleo de CPU dado:

Con este cambio, vuelvo a tener resultados de referencia muy estables. Entonces, si alguna vez se encontró con un problema similar, ¡vea si es útil establecer la afinidad del proceso con el conjunto de tareas!