¿Cuántos conmutadores de contexto es "normal" (en función de los núcleos de la CPU (u otros))?

34

Hola Overlords Linux / UNIX,

¿Alguno de ustedes tiene una regla general sobre cuántos cambios de contexto (por núcleo de procesador) es Normal en un servidor Linux?

Mi universidad aquí lo mencionó, y él está viendo 16K en una x86_64máquina de 8 núcleos .

Aquí hay algunas estadísticas de sarface en los últimos días ...

texto alternativo http://src.autonomy.net.au/imagebin/81895e338fae67d3d205c09db44a81e6-Picture_10.png

Y para ver las estadísticas de creación de procesos, aquí hay una vista logarítmica del mismo gráfico ...

texto alternativo http://src.autonomy.net.au/imagebin/7481f7e52bead4effc90248fc23c72fe-Picture_11.png

Y los 8 núcleos están aburridos de morir ...

texto alternativo http://src.autonomy.net.au/imagebin/0e94326652e977fd74edcd840f94200f-Picture_12.png

CS vs IOwait (escala x10000)

texto alternativo http://src.autonomy.net.au/imagebin/a52a2a8a120394849c0da4045933e306-Picture_13.png

Más información inútil en caso de que alguien pregunte.

  • El almacenamiento en el que trabaja el servidor es una SAN de 0.5 TB a través de FC
  • Hay 8 GB de RAM, principalmente caché, sin intercambio.
linux performance context-switch Jerjes
fuente
1
¿En algún período en particular?
dmckee
¿Puedes ser más específico sobre la carga de trabajo?
dmo
1
¿Cómo hiciste esa gráfica? ¡Se ve muy bien!
Antoine Benkemoun
Hola Antoine - Los gráficos están hechos de sarface ( projects.autonomy.net.au/sarface )
Xerxes
los enlaces del gráfico están muertos a partir de ahora. @ Jerjes, ¿puedes llegar desde algún lugar?
törzsmókus

Respuestas:

25

Esto depende mucho del tipo de aplicación que ejecute. Si tiene aplicaciones que son llamadas de sistema WRT muy fáciles de activar, puede esperar ver grandes cantidades de cambio de contexto. Si la mayoría de sus aplicaciones están inactivas y solo se activan cuando ocurren cosas en un socket, puede esperar ver bajas tasas de cambio de contexto.

Sistema de llamadas

Las llamadas al sistema provocan cambios de contexto por su propia naturaleza. Cuando un proceso realiza una llamada al sistema, básicamente le dice al kernel que se haga cargo de su punto actual de tiempo y memoria para hacer cosas que el proceso no tiene el privilegio de hacer, y que regrese al mismo lugar cuando haya terminado.

Cuando miramos la definición de syscall write (2) desde Linux, esto queda muy claro:

NOMBRE
       escribir: escribir en un descriptor de archivo

SINOPSIS
       #incluir 

       ssize_t write (int fd, const void * buf, size_t count);

DESCRIPCIÓN
       write () escribe para contar bytes desde la memoria intermedia apuntada al búfer en el archivo
       referido por el descriptor de archivo fd. [..]

VALOR DEVUELTO
       En caso de éxito, se devuelve el número de bytes escritos (cero indica
       nada fue escrito). En caso de error, se devuelve -1 y se establece errno
       apropiadamente.
       [..]

Básicamente, esto le dice al kernel que se haga cargo de la operación del proceso, se mueva a countbytes, comenzando desde la dirección de memoria señalada por *bufel descriptor fdde archivo del proceso actual y luego regrese al proceso y dígale cómo fue.

Un buen ejemplo para mostrar esto es el servidor de juegos dedicado para juegos basados ​​en Valve Source, hlds . http://nopaste.narf.at/f1b22dbc9 muestra un segundo valor de syscalls realizadas por una sola instancia de un servidor de juegos que no tenía jugadores. Este proceso requiere aproximadamente un 3% de tiempo de CPU en un Xeon X3220 (2.4Ghz), solo para darle una idea de lo caro que es.

Multitarea

Otra fuente de cambio de contexto podrían ser los procesos que no realizan llamadas al sistema, pero que necesitan moverse de una CPU determinada para dejar espacio para otros procesos.

Una buena manera de visualizar esto es cpuburn . cpuburn no hace ninguna llamada al sistema, solo itera sobre su propia memoria, por lo que no debería causar ningún cambio de contexto.

Tome una máquina inactiva, inicie vmstat y luego ejecute un burnMMX (o cualquier prueba diferente del paquete cpuburn) para cada núcleo de CPU que tenga el sistema. Debería tener una utilización completa del sistema para entonces, pero casi ningún cambio de contexto aumentado. Luego intente iniciar algunos procesos más. Verá que la velocidad de cambio de contexto aumenta a medida que los procesos comienzan a competir por los núcleos de la CPU. La cantidad de conmutación depende de la relación procesos / núcleo y la resolución multitarea de su núcleo.

Otras lecturas

linfo.org tiene un buen resumen de los cambios de contexto y las llamadas al sistema . Wikipedia tiene información genérica y una buena colección de enlaces sobre llamadas del sistema.

Michael Renner
fuente
1
Esto ha sido útil, ¡me has dado una gran idea! =)
Jerjes
1
Tu afirmación System calls cause context switches by their very own natureparece incorrecta. Las llamadas del sistema causan el cambio de modo como lo indica linfo.org/context_switch.html
Nicolas Labrot el
6

mi servidor web moderadamente cargado se encuentra entre 100 y 150 conmutadores por segundo la mayor parte del tiempo con picos de miles.

Las altas tasas de cambio de contexto no son en sí mismas un problema, pero pueden señalar el camino a un problema más significativo.

editar: los cambios de contexto son un síntoma, no una causa. ¿Qué intentas ejecutar en el servidor? Si tiene una máquina multiprocesador, puede intentar configurar la afinidad de la CPU para los procesos del servidor principal.

Alternativamente, si está ejecutando X, intente desplegarse en modo consola.

edite de nuevo: a 16k cs por segundo, cada CPU tiene un promedio de dos interruptores por milisegundo, es decir, entre la mitad y la sexta parte del intervalo de tiempo normal. ¿Podría estar ejecutando una gran cantidad de hilos IO?

editar nuevamente publicar gráficos: Ciertamente se ve obligado a IO. ¿El sistema pasa la mayor parte de su tiempo en SYS cuando los cambios de contexto son altos?

edite una vez más: Alto iowait y sistema en ese último gráfico, eclipsando por completo el espacio del usuario. Tienes problemas de IO.
¿Qué tarjeta FC estás usando?

editar: hmmm. ¿Alguna posibilidad de obtener algunos puntos de referencia en su acceso SAN con bonnie ++ o dbench durante el tiempo muerto? Me interesaría ver si tienen resultados similares.

editar: He estado pensando en esto durante el fin de semana y he visto patrones de uso similares cuando Bonnie está haciendo el pase "escribir un byte a la vez". Eso puede explicar la gran cantidad de conmutación que está ocurriendo, ya que cada escritura requeriría una llamada al sistema por separado.

jay_dubya
fuente
Todavía no estoy convencido de que una alta velocidad de cambio de contexto no sea un problema, estoy hablando de alta como en 4K a 16K, no 100-150.
Jerjes
Ninguno de nuestros servidores ejecuta ninguna X. Estoy de acuerdo con usted en el problema de espera IO y la relación entre eso y el CS. Sin embargo, la tarjeta HBA no es sospechosa porque usamos la misma tarjeta en los otros cientos de servidores ... La conclusión es que culpo a los equipos SAN de EVA SAN que intentan y defienden desesperadamente todo el tiempo. Tenga en cuenta que una alta espera de E / S no siempre es motivo de alarma, si la mayoría de los procesos en una máquina están vinculados a E / S, se espera que el servidor no tenga nada mejor para hacer los giros inactivos.
Jerjes
Sin embargo, en el segundo, el cuarto gráfico adjunto muestra que en realidad no está tan cerca como pensé al principio. No es exactamente un eclipse de ninguna manera. Aunque todavía culpo a la SAN. =)
Jerjes
1

Estoy más inclinado a preocuparme por la tasa de ocupación de CPU del estado del sistema. Si está cerca del 10% o más, eso significa que su sistema operativo está pasando demasiado tiempo haciendo los cambios de contexto. Aunque mover algunos procesos a otra máquina es mucho más lento, merece hacerlo.


fuente
1

Cosas como esta son las razones por las que debería intentar mantener las líneas de base de rendimiento para sus servidores. De esa manera, puedes comparar cosas que notas de repente con cosas que has grabado en el pasado.

Dicho esto, tengo servidores en ejecución (servidores Oracle no muy ocupados, principalmente), que son constantes alrededor de 2k con algunos picos de 4k. Para mis servidores, eso es normal, para los servidores de otras personas que pueden ser demasiado bajos o demasiado altos.

¿Hasta dónde puede retroceder en sus datos?

¿Qué tipo de información de CPU nos puede dar?

wzzrd
fuente
Definitivamente estoy de acuerdo con mantener una línea de base, y tenemos datos de nagios que se remontan por largos períodos; el problema con este servidor es que es sangre nueva, solo ha estado presente por un corto tiempo. Además, está ejecutando software empresarial (léase: basura) - Teamsite - solo para agregarlo a la lista de variables indefinidas. Todavía prefiero sar (preferencia personal), así que lo configuraré para mantener más que el valor predeterminado (2 semanas) y veré cómo funciona.
Jerjes
El uso de sar en combinación con rrdtool (que parece que provienen de sus gráficos) puede ser un medio fácil de mantener sus datos (o al menos resúmenes de ellos) durante mucho tiempo.
wzzrd
0

No hay una regla general. Un cambio de contexto es solo la CPU que pasa de procesar un hilo a otro. Si ejecuta muchos procesos (o algunos procesos altamente enhebrados) verá más interruptores. Afortunadamente, no necesita preocuparse por la cantidad de cambios de contexto que existen: el costo es pequeño y más o menos inevitable.

Alex J
fuente
66
En realidad, el costo de un cambio de contexto es costoso . Esto es aún peor en las máquinas virtuales: hicimos algunas pruebas hace unos meses que mostraron que una de las principales causas del rendimiento de la VM fue el cambio de contexto.
Jerjes
De hecho, en cualquier sistema operativo moderno (multitarea), la minimización del cambio de contexto es una tarea de optimización muy significativa. ¿Tiene alguna fuente para respaldar su afirmación de que el costo es pequeño?
Jerjes
Lo sentimos, ¿estás hablando de minimizar los cambios de contexto desde la perspectiva del desarrollo del sistema operativo? Al no tener nada que ver con tal desarrollo, no tengo ninguna opinión sobre los beneficios de diseñar un sistema para minimizar CS :) Si está hablando de minimizar los cambios de contexto en un servidor, el problema es que mitigar los cambios de contexto introduce latencia en otros lugares. Por ejemplo, reducir el número de procesos en una máquina significa que debe mover estos procesos a otra máquina, lo que significa que la comunicación se produce a través de una red, ¡lo cual es mucho más lento!
Alex J
Creo que su definición de cambios de contexto es defectuosa; También suceden cuando se realiza una llamada al sistema, incluso si vuelve al mismo hilo. Las aplicaciones optimizan contra esto haciendo varios trucos. Por ejemplo, Apache necesita obtener la hora del sistema con mucha frecuencia; para ese propósito, un hilo llama a localtime repetidamente y almacena el resultado en la memoria compartida. Los otros subprocesos solo tienen que leer de la RAM y no incurren en un cambio de proceso al hacerlo.
niXar