25 votos

"Picos" de Uso de CPU en los Controladores de Dominio

Tenemos dos de Windows Server 2008 SP2 (lamentablemente no 2008 R2) de los Controladores de Dominio en un pequeño 150 dominio de cliente que están exhibiendo muy "picos" de uso de la CPU. Los Controladores de Dominio de ambas presentan el mismo comportamiento y se encuentran alojadas en vSphere 5.5.0, 1331820. Cada dos o tres segundos de uso de la CPU saltos de hasta 80% al 100% y luego baja rápidamente, sigue siendo baja durante un segundo o dos y luego salta de nuevo.

DC3 Task Manager Performance




Mirando el histórico de los datos de rendimiento de la máquina virtual indica que esta condición ha estado sucediendo durante al menos un año, pero la frecuencia se ha incrementado desde el mes de Marzo.

DC3 Virtual Machine Performance





El proceso de ofender SVChost.exe que está envolviendo el Cliente DHCP (dhcpcsvc.dll), EventLog (wevtsvc.dll) y LMHOSTS (lmhsvc.dll) servicios. Ciertamente no soy un Windows internals experto, pero yo no podía parecen encontrar nada especialmente mal al ver el proceso con el Proceso de Explorer a otros de lo que aparece en el registro de Sucesos es la activación de una tonelada de RpcBindingUnbind llamadas.

DC3 Process Explorer for SVCHost.exe



En este punto estoy de café y las ideas. ¿Cómo debo seguir para solucionar este problema?

25voto

kce Puntos 9227

TL;DR: EventLog archivo completo. Sobrescribir las entradas es caro y/o que no se aplican muy bien en Windows Server 2008.




En @pk. y @joeqwerty sugerencia y después de preguntar, decidí que parecía más probable que un olvidado de la supervisión de la aplicación fue raspado de los registros de sucesos.

He instalado el Monitor de Red de Microsoft en uno de los Controladores de Dominio y comenzó filtrado para MSRPC el uso de la ProtocolName == MSRPC filtro. Había mucho tráfico, pero todo fue entre nuestro sitio remoto del RODC y lamentablemente no utilizar el mismo puerto de destino como la escucha EventLog proceso. Maldito! Ahí va esa teoría.

Para simplificar las cosas y hacer que sea más fácil de ejecutar software de monitoreo que me decidí a desenvolver el registro de Sucesos del servicio de SVCHost. El siguiente comando y un reinicio del Controlador de Dominio dedica un SVCHost proceso para el registro de Sucesos del servicio. Esto hace que la investigación sea un poco más fácil ya que no dispone de múltiples servicios conectados a la PID.

SC config EventLog Type= own

Yo entonces recurrió a ProcMon y la instalación de un filtro para excluir todo lo que no hizo uso de ese PID. No he visto toneladas de intentos fallidos por parte de EventLog para abrir faltan las claves del registro como se indica como una posible causa aquí (al parecer cutre aplicaciones se pueden registrar como un Evento de Fuentes de muy mala manera). Previsiblemente vi a muchos de los exitosos ReadFile entradas del Registro de Eventos de Seguridad (C:\Windows\System32\WinEvt\Logs\Security.evtx).

ReadFile Security.evtx



He aquí un vistazo a la Pila en uno de esos eventos: RpcBindingUnbind

Usted notará primero el RPCBinding y, a continuación, RPCBindingUnbind. Hubo una gran cantidad de estos. Como miles por segundo. El Registro de Seguridad está muy ocupado o algo no está funcionando bien con el Security.evtx de registro.

En EventViewer el Registro de Seguridad fue sólo el inicio de sesión de una entre 50 y 100 eventos por minuto que parecía apropiado para un dominio de este tamaño. Maldito! Ahí va la teoría número dos que hemos tenido alguna aplicación con muy detallado de auditoría de eventos de encendido a la izquierda en un rincón olvidado todavía obedientemente el traqueteo de distancia. Hubo todavía un montón (~250,000) de los eventos registrados, incluso a pesar de que la tasa de eventos que se registran fue baja. El tamaño del registro tal vez?

Los Registros de seguridad - (Clic Derecho) - Propiedades... y el tamaño de registro máximo fue fijado para 131,072 KB y el tamaño del registro estaba llevando a cabo actualmente en 131,072 KB. El 'Sobrescribir sucesos cuando sea necesario" botón de radio fue controlado. Yo pensé que la eliminación constante y escritura para el archivo de registro fue, probablemente, el trabajo duro, especialmente cuando se fue tan completa, así que he optado por Borrar el Registro (he guardado el log antiguo sólo en caso de que necesite para la auditoría posterior) y dejar que el registro de Sucesos del servicio de crear un nuevo archivo vacío. El resultado: el uso de la CPU devuelto a un sano nivel de alrededor del 5%.

5voto

ChuckB Puntos 688

Usted puede ser capaz de perseguirlo por la creación de un pequeño Conjunto de Recopiladores de Datos.

  • Abra el Monitor de Rendimiento y crear un nuevo usuario definido por el Conjunto de Recopiladores de Datos.
  • Seleccione Manual (sin plantilla) y seleccione el Evento de seguimiento de datos solamente.
  • Agregar el Dominio de Active Directory de Servicio: el centro de datos y guardar la configuración.
  • Cambiar la Condición de Parada en virtud de las Propiedades a 1 minuto.
  • Inicio de la serie y esperar.
  • Cuando se haya completado, convertir la guarda .etl de archivo .csv usando tracerpt –l "file.etl" –of CSV
  • Analizar el resumen.csv y dumpfile.csv de datos en Excel. Usted lo desea, puede descargar este Importación-DC-Info.xlsm doc para ayudarle con su análisis.

Si mi corazonada es correcta, vas a ver algunos de los dispositivos (IP:puerto) martilleo en su CC.

1voto

MichelZ Puntos 8960

Sin duda difícil. Aparte de simplemente dejarlo solo (1 CPU / 50% de la carga.. ¿a quién le importa?), usted podría intentar la instalación de un nuevo controlador de dominio y ver después de algunos días, si este tiene el mismo comportamiento. Si lo hace, es posible que desee probar con un Wireshark trace (obviamente, hay algo de la Red causando esto luego)

La siguiente cosa que viene a la mente es una simple llamada a microsoft

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: