¿Por qué 1 de mis 24 CPU está vinculada al 100%?

12

Tengo un sistema HP ProLiant DL380 G7 que usa 2 CPU de 6 núcleos, con Hyper-threading habilitado, para un total de 24 CPU lógicas (como lo ve Windows).

Al ejecutar nuestra aplicación, la utilización total de la CPU del sistema es buena, pero uno de los 24 CUP está vinculado al 100%: ingrese la descripción de la imagen aquí

Editar: estos son los datos de PerfMon para el proceso del sistema durante este tiempo y para el procesador con alta utilización: ingrese la descripción de la imagen aquí

¿Esto es normal? Si no, ¿hay alguna manera de identificar qué proceso (s) están usando esa CPU lógica? Windows PerfMon, ResMon, Task Manager y Process Explorer no han sido de ayuda, aparte de identificar que la CPU está al 100%.

windows-server-2008-r2 performance cpu-usage

— Patrick Cuff
fuente

29

Mi suposición sería que está en uso porque un proceso lo está usando.

— HopelessN00b

1

¿Sabes que puedes pasar el cursor sobre el gráfico y obtener una pista que te dice qué proceso está tomando más CPU en ese procesador?

— Lieven Keersmaekers

Sospecharía de la interrupción delta de 100k. Debe publicar una captura de pantalla de la lista de procesos de Process Explorer donde podemos ver lo que dice para cosas como Sistema, DPC, Interrupciones.

— Gabe

@RyanRies; nuestra "aplicación" consiste en varios servicios .Net WCF que también incluyen WebSphere MQ y algunos software de monitoreo de terceros.

— Patrick Cuff

2

Es relativamente costoso mover un proceso de una CPU a otra, en comparación con mantenerlo programado en la misma CPU, por lo que si un proceso realmente exige la CPU, el sistema operativo a menudo preferirá no moverlo.

— Michael Hampton

11

Como otros ya han señalado, podemos ver en esa captura de pantalla que la CPU que está trabajando tan duro está pasando todo su tiempo en modo kernel. (El color rojo).

Ejecutando Powershell como administrador, escriba:

Get-Process | Select Name, PrivilegedProcessorTime | `
Sort-Object PrivilegedProcessorTime -Descending

El proceso en la parte superior de la lista es el proceso que actualmente utiliza la mayor cantidad de tiempo de CPU en modo kernel en este momento. Si ese proceso no es "Sistema", acaba de descubrir qué proceso de modo de usuario está causando el uso de esta CPU. Si el proceso con el mayor tiempo de procesador privilegiado es el sistema, que sospecho que es, entonces es un poco más complicado.

Abra el Explorador de procesos. Opcionalmente, configure su servidor de símbolos. Asegúrese de estar ejecutando con la elevación completa de UAC. Haga clic derecho en el "proceso" del sistema y vaya a Propiedades. Luego vaya a la pestaña Hilos. Ordenar los hilos por uso de CPU. El hilo que está causando todo este trabajo en modo kernel debería estar aquí. Si observa el módulo que figura en la Dirección de inicio, debería darle una pista de lo que está relacionado el trabajo. Si es NDIS.sys, por ejemplo, es un controlador de interfaz de red. Si configura el servidor de símbolos, debería ver el nombre de una función dentro de un módulo (a menos que el módulo no sea Microsoft), de lo contrario, verá un desplazamiento numérico desde la dirección de inicio del módulo.

Alternativamente, use Xperf del Kit de herramientas de rendimiento de Windows para perfilar interrupciones, DPC, etc.

xperf -on PROC_THREAD+LOADER+DPC+INTERRUPT

y deja de grabar con xperf -d logfile.etl

Xperf reemplaza la antigua herramienta Kernrate y puede proporcionarle datos extremadamente detallados.

Cuando una CPU está trabajando en modo kernel, está ejecutando principalmente rutinas de servicio de interrupción. (ISR) Cuando se produce una interrupción, el trabajo en modo de usuario se suspende en ese procesador y la CPU ejecuta el ISR registrado en esa interrupción. Si encuentra que su CPU pasa una cantidad excesiva de tiempo en estas interrupciones, eso generalmente indica un controlador de dispositivo defectuoso que debe actualizarse.

Sin embargo, lo que me molesta (sin juego de palabras) sobre este escenario es que parece que cualquier hilo del núcleo que esté haciendo esto parece estar afinado a ese núcleo. Me pregunto por qué el despachador parece estar programando solo el hilo para que se ejecute en ese núcleo aparentemente arbitrario. Por lo tanto, tengo la sensación de que necesitamos encontrar a quien escribió este controlador de dispositivo y mostrarles cómo hacer DPC roscados, y no establecer explícitamente una afinidad en los hilos del núcleo, etc.

— Ryan Ries
fuente

IIRC, es un comportamiento bastante estándar para un sistema operativo usar solo una sola CPU para manejar las interrupciones de hardware ...

— Massimo

1

@ Massimo Este podría haber sido el caso con los sistemas operativos antiguos, pero ya no. Cada CPU tiene su propia tabla de descripciones de interrupciones, y cada procesador tiene su propio IRQL. Si una CPU está atascada en un IRQL alto por algún motivo (es decir, ya está prestando servicio a una interrupción), no puede recibir interrupciones del mismo nivel o de un nivel inferior, por lo que Windows le dará la interrupción a otro procesador o simplemente la mantendrá. hasta que una CPU esté disponible. Incluso los temporizadores (un objeto anteriormente conocido por ejecutarse solo en CPU0) ahora tienen un algoritmo de selección de procesador.

— Ryan Ries

Pero sí, esto puede ser tan simple como ejecutar una aplicación heredada o mal escrita que se afina mal y, posteriormente, realiza muchas llamadas al sistema. Las interrupciones generalmente deben comenzar y finalizar en la misma CPU desde la que se llamaron ... pero normalmente incluso una aplicación de un solo subproceso se "equilibraría en la carga" entre los núcleos mientras se ejecuta ... esta parece tener un extraño afinidad.

— Ryan Ries

@RyanRies; Instalé el Kit de herramientas de rendimiento de Windows en el sistema y utilicé el Grabador de rendimiento de Windows; el comando xperf anterior seguía dando errores. Parece que la CPU alta proviene de: Proceso - Sistema; Módulo - ntoskrnl.exe; Hilo - Phase1Initialize; Función - KeZeroPages. Solo sucede cuando la aplicación se está ejecutando, así que creo (espero) que tenga suficiente para llevar a los desarrolladores, pero también estoy interesado en cualquier idea que pueda tener.

— Patrick Cuff

23

Muestre la columna "Tiempo de CPU" en la pestaña "Detalles" en "Administrador de tareas" y busque un proceso con un recuento de tiempo de CPU que aumenta constantemente. Ese es tu proceso en cuña. Debería estar usando alrededor de 4.17% de CPU constantemente.

— Evan Anderson
fuente

10

Parece ser todo el tiempo del kernel, podrían ser interrupciones, solo podrían ser manejados por una sola CPU.

— MichelZ
fuente

+1 - Seguro que parece tiempo de kernel, ¿no?

— Evan Anderson

¿Aparecería eso bajo el proceso "Sistema"? Los datos de PerfMon que recopilamos durante una ejecución de prueba tienen 100% de CPU para el proceso "Sistema".

— Patrick Cuff

Sí, creo que caería bajo el sistema (si está en la lista ...)

— MichelZ

66

¿No podría ser también un error del controlador o una pieza de hardware defectuoso que interactúa con un controlador sin recuperación de errores? O tal vez software llamando al kernel en un ciclo cerrado.

— Zan Lynx

1

@MichelZ, un proceso de usuario que realiza un montón de llamadas al sistema (que incluiría cualquier tipo de E / S) se vería así.

— reirab

6

Busque un proceso con una utilización constante de CPU de ~ 4% (= 1/24 del total de CPU disponible). Ese debería ser el que toma continuamente una sola CPU.

— Massimo
fuente