Actualmente estoy buscando mover nuestro sistema de RHEL 5 a RHEL 6, pero me he encontrado con un inconveniente con el uso inesperadamente alto de CPU en las máquinas RHEL 6. Parece que esto puede deberse al menos en parte al uso de selectun sueño interrumpible. Aquí hay un ejemplo simple que muestra el comportamiento:
#include <sys/select.h>
int main()
{
timeval ts;
for (unsigned int ii=0; ii<10000; ++ii) {
ts.tv_sec = 0;
ts.tv_usec = 1000;
select(0, 0, 0, 0, &ts);
}
return 0;
}
En una máquina RHEL 5 se mantendrá con un 0% de uso de la CPU, pero en el mismo hardware con RHEL 6 instalado, usará aproximadamente el 0.5% de la CPU, por lo que cuando se ejecutan de 30 a 50 programas selectpara dormir, se consume un gran cantidad de la CPU innecesariamente.
Abrí un Bugzilla e intenté ejecutar OProfile y simplemente muestra el 100% en main para la aplicación y poco más del 99% en poll_idle al mirar el kernel (tengo inactivo = sondeo configurado en mis opciones de grub para que todo se pueda capturar).
¿Alguna otra idea de lo que puedo hacer para tratar de aislar cuál es la causa del mayor uso de la CPU?
ACTUALIZACIÓN: Encontré la herramienta de rendimiento y obtuve el siguiente resultado:
# Events: 23K cycles
#
# Overhead Command Shared Object Symbol
# ........ ....... ................... ....................................
#
13.11% test_select_sma [kernel.kallsyms] [k] find_busiest_group
5.88% test_select_sma [kernel.kallsyms] [k] schedule
5.00% test_select_sma [kernel.kallsyms] [k] system_call
3.77% test_select_sma [kernel.kallsyms] [k] copy_to_user
3.39% test_select_sma [kernel.kallsyms] [k] update_curr
3.22% test_select_sma ld-2.12.so [.] _dl_sysinfo_int80
2.83% test_select_sma [kernel.kallsyms] [k] native_sched_clock
2.72% test_select_sma [kernel.kallsyms] [k] find_next_bit
2.69% test_select_sma [kernel.kallsyms] [k] cpumask_next_and
2.58% test_select_sma [kernel.kallsyms] [k] native_write_msr_safe
2.47% test_select_sma [kernel.kallsyms] [k] sched_clock_local
2.39% test_select_sma [kernel.kallsyms] [k] read_tsc
2.26% test_select_sma [kernel.kallsyms] [k] do_select
2.13% test_select_sma [kernel.kallsyms] [k] restore_nocheck
Parece que el mayor uso de la CPU es del planificador. También utilicé el siguiente script bash para iniciar 100 de estos simultáneamente:
#!/bin/bash
for i in {1..100}
do
./test_select_small &
done
En RHEL 5, el uso de CPU se mantiene cerca del 0%, pero en RHEL 6 hay una cantidad no trivial de uso de CPU tanto en el usuario como en el sistema. ¿Alguna idea sobre cómo localizar la verdadera fuente de esto y con suerte solucionarlo?
También probé esta prueba en una compilación actual de Arch Linux y Ubuntu 11.10 y vi un comportamiento similar, por lo que parece ser algún tipo de problema del kernel y no solo un problema de RHEL.
ACTUALIZACIÓN2: dudo un poco en mencionar esto porque sé que es un gran debate, pero probé un kernel con los parches BFS en Ubuntu 11.10 y no mostró el mismo uso elevado de CPU del sistema (el uso de la CPU del usuario parecía aproximadamente lo mismo).
¿Hay alguna prueba que pueda ejecutar con cada uno de ellos para probar si este alto uso de CPU es solo una diferencia en la contabilidad del uso de CPU que lo hace parecer artificialmente alto? ¿O si el CFS está robando los ciclos reales de la CPU?
ACTUALIZACIÓN3: El análisis realizado con esta pregunta parece indicar que se trata de algo relacionado con el planificador, por lo que creé una nueva pregunta para analizar los resultados.
ACTUALIZACIÓN4: agregué más información a la otra pregunta .
ACTUALIZACIÓN5: Agregué algunos resultados a la otra pregunta de una prueba más simple que aún demuestra el problema.
fuente
selectallí?Respuestas:
Usted pregunta:
¿Qué sucede si ejecutó un punto de referencia de CPU mientras ejecuta su
test_select_smallprograma y ve si su rendimiento cambia según la versión del sistema operativo host?Hay muchas opciones: el consejo clásico es siempre "usar algo que represente el tipo de carga que tendrás". Pero los chicos geniales siempre usaron povray
fuente