Uso de CPU "pico" en controladores de dominio

Tenemos dos controladores de dominio de Windows Server 2008 SP2 (lamentablemente no 2008 R2) en un pequeño dominio de 150 clientes que exhiben un uso de CPU muy "pico". Los controladores de dominio exhiben el mismo comportamiento y están alojados en vSphere 5.5.0, 1331820. Cada dos o tres segundos, el uso de la CPU aumenta hasta 80-100% y luego cae rápidamente, permanece bajo durante un segundo o dos y luego sube otra vez.

Ver los datos históricos de rendimiento de la máquina virtual indica que esta condición ha estado sucediendo durante al menos un año, pero la frecuencia ha aumentado desde marzo.

El proceso ofensivo es SVChost.exe que está envolviendo los servicios del Cliente DHCP (dhcpcsvc.dll), EventLog (wevtsvc.dll) y LMHOSTS (lmhsvc.dll). Ciertamente no soy un experto interno de Windows, pero parece que no puedo encontrar nada especialmente malo al ver el proceso con Process Explorer, aparte de que parece que EventLog está disparando una tonelada de llamadas RpcBindingUnbind .

En este punto no tengo café ni ideas. ¿Cómo debo continuar para solucionar este problema?

TL; DR: el archivo EventLog estaba lleno. Sobrescribir entradas es costoso y / o no se implementa muy bien en Windows Server 2008.

En @pk. y @joeqwerty sugerencia y después de preguntar, decidí que parecía muy probable que una implementación de monitoreo olvidada estuviera borrando los registros de eventos.

Instalé el Monitor de red de Microsoft en uno de los Controladores de dominio y comencé a filtrar para MSRPC usando el ProtocolName == MSRPCfiltro. Había mucho tráfico, pero todo estaba entre el RODC de nuestro sitio remoto y desafortunadamente no usó el mismo puerto de destino que el proceso de escucha de EventLog. ¡Maldito! Ahí va esa teoría.

Para simplificar las cosas y facilitar la ejecución del software de monitoreo, decidí desenvolver el servicio EventLog de SVCHost. El siguiente comando y un reinicio del controlador de dominio dedica un proceso SVCHost al servicio EventLog. Esto hace que la investigación sea un poco más fácil ya que no tiene múltiples servicios conectados a ese PID.

SC config EventLog Type= own

Luego recurrí a ProcMon y configuré un filtro para excluir todo lo que no usaba ese PID. No vi toneladas de intentos fallidos por parte de EventLog para abrir las claves de registro que faltan, como se indica como una posible causa aquí (aplicaciones aparentemente malas pueden registrarse como orígenes de eventos de maneras extremadamente pobres). Como era previsible, vi muchas entradas exitosas de ReadFile del registro de eventos de seguridad (C: \ Windows \ System32 \ WinEvt \ Logs \ Security.evtx).

Aquí hay un vistazo al Stack en uno de esos eventos:

Notarás primero RPCBinding y luego RPCBindingUnbind. Había muchos de estos. Como miles por segundo. O bien el Registro de seguridad está realmente ocupado o algo no funciona correctamente con el Security.evtxregistro.

En EventViewer, el registro de seguridad solo registraba entre 50 y 100 eventos por minuto, lo que parecía apropiado para un dominio de este tamaño. ¡Maldito! Ahí va la teoría número dos de que teníamos alguna aplicación con una auditoría de eventos muy detallada activada a la izquierda en un rincón olvidado que todavía se estaba llevando a cabo. Todavía se registraron muchos eventos (~ 250,000) a pesar de que la tasa de eventos registrados fue baja. Tamaño de registro tal vez?

Registros de seguridad - (clic con el botón derecho) - Propiedades ... y el tamaño máximo de registro se estableció en 131,072 KB y el tamaño de registro se mantuvo actualmente en 131,072 KB. Se marcó el botón de opción 'Sobrescribir eventos según sea necesario'. Pensé que eliminar y escribir constantemente en el archivo de registro probablemente era un trabajo duro, especialmente cuando estaba tan lleno, así que opté por borrar el registro (guardé el registro anterior en caso de que lo necesitemos para auditarlo más tarde) y dejé que el servicio EventLog creara Un nuevo archivo vacío. El resultado: el uso de la CPU volvió a un nivel sensato de alrededor del 5%.

Puede perseguir esto creando un pequeño conjunto de recopiladores de datos.

• Abra el Monitor de rendimiento y cree un nuevo conjunto de recopiladores de datos definidos por el usuario.
• Elija Manual (sin plantilla) y seleccione Solo datos de seguimiento de eventos .
• Agregue el Servicio de dominio de Active Directory: Datos principales y guarde el conjunto.
• Cambie la Condición de detención en Propiedades a 1 minuto.
• Comienza el set y espera.
• Cuando termine, convierta el archivo .etl guardado en un archivo .csv usandotracerpt –l “file.etl” –of CSV
• Analice los datos summary.csv y dumpfile.csv en Excel. Es posible que desee descargar este documento Import-DC-Info.xlsm para ayudarlo con su análisis.

Si mi presentimiento es correcto, verá algunos dispositivos (IP: puerto) que afectan su DC.

Ciertamente uno difícil. Además de dejarlo solo (1 CPU / 50% de carga ... ¿a quién le importa?), Podría intentar configurar un nuevo controlador de dominio y ver después de algunos días si este le da el mismo comportamiento. Si es así, es posible que desee probar con un rastro de Wireshark (obviamente, hay algo de la red que causa esto entonces)

Lo siguiente que viene a la mente es una simple llamada a Microsoft.

Travis, "archivo" no te ayudó. De hecho, incluso borrar el registro de eventos cuando crecía 2/3 no lo ayudó. Pero "archivo" ayudó a KraigM.

kce: borró un archivo de "sobrescritura" de 131MB y vio una caída en el rendimiento de, digamos, 55% o 5%, pero PREGUNTA: tal vez finalmente haya visto una alta utilización nuevamente ya que esto (a) solo puede activarse cuando se alcanza la condición de sobrescritura o (b) puede empeorar linealmente a medida que el archivo borrado aumenta de 0mb de tamaño a 131MB de tamaño.

Algunos ven esto para security.evtx y uno lo vio para el registro operativo del Programador de tareas. Sugiero desinstalar completamente su AV (¿cuál está usando?) E intentarlo. Los intrusos deben ocultar sus pistas y sus pistas se realizan en tareas programadas que configuran o en los inicios de sesión que realizan. Por lo tanto, ocultarán sus pistas rompiendo los controladores de estos registros de eventos y reescribiéndolas para omitirlas. Los AV pueden estar detectando esto de una manera defectuosa ya que si se tratara de Microsoft, se habría informado más de esta alta utilización, pero estoy viendo solo unas pocas publicaciones cuando busco en Google. También estoy viendo esto en el servidor 2008 R2 para el registro security.evtx. Sin suscriptores de registro de eventos, sin monitores externos. Observé un par de servicios AV (McAfee) ejecutándose y tenían una utilización total muy baja para un servidor en funcionamiento durante tantos días, así que sospecho que se desinstaló y solo parcialmente (probablemente necesite el desinstalador especial de McAfee) y me pregunto si hay ganchos en el vestigio (o incluso normalmente instalado) el servicio de McAfee o los controladores de filtro de McAfee en ejecución que de alguna manera toman una escritura normal en el registro de eventos y deciden en su filtrado que necesitan convertir esto en una lectura completa de todo el registro de eventos. Confía en mí, los controladores de filtro de terceros de algunas compañías de AV tienen errores y ciertamente son 10000 veces más defectuosos que la implementación de registro de eventos de Microsoft, lo que probablemente sea perfecto. En resumen, desinstalar al 100% TODOS SUS AV y VER SI el problema se resuelve. Si es así, trabaje con su compañía AV para arreglar su AV. No es aconsejable hacer excepciones de archivo para.

Además, cuando use procmon, preste atención a las llamadas de WriteFile porque el Writefile es lo que activará el administrador de filtros para leer todo el archivo. En mi caso, la lectura se inició aproximadamente 30 segundos después de completar la escritura, lo que podría ser por diseño. Pero fue consistente y en mi caso el archivo tenía 4GB y la lectura del archivo involucraba 64K Readfiles cada 64KB de longitud y utilizaba el 35% de la CPU para lograr esto. Muy triste.

Actualización 23/03/2016 Miré los controladores de filtro en esta máquina después de concluir que esto tenía que ser causado por uno de ellos (el mecanismo de registro de eventos nunca podría tener errores por sí mismo o la cantidad de informes de este tipo sería asombrosa y No lo es). Vi algunos controladores de filtro de un AV y de una conocida empresa de terceros que aumenta el rendimiento del disco de la máquina virtual con lecturas anticipadas y le pregunté a su arquitecto en jefe (que fue muy amable y gentil) si su producto podría estar leyendo demasiado agresivamente todo registro de eventos de seguridad (que estaba sucediendo claramente por procmon). Esto sería útil para los registros de seguridad más pequeños, pero no para los tamaños que se informan aquí. De ninguna manera dijo. Estuvo de acuerdo en que podría ser el AV.

Como le dije al compañero de Azure a continuación, no tenemos un seguimiento del póster original si el problema reapareció después de borrar el registro de eventos porque esa es una solución común y errónea ya que el rendimiento se degrada con el tiempo una vez más. Esto se llama "seguimiento" y veo de primera mano que la solución del póster original puede engañar a aquellos que no lo hacen para que crean que han resuelto el problema. Casi me engaño también. Borré el registro de eventos y mejoré el rendimiento, pero usé procmon y vi que el problema crecerá y crecerá lentamente con el tiempo hasta que se vuelva problemático. Por alguna razón, el compañero de Azure me critica duramente cuando el póster original no siguió (puede haber muerto, despedido, dejarlo u ocupado). El compañero de Azure a continuación piensa que si el póster original no siguió, debe ser un problema solucionado. Esto es desconcertante y desconcertante porque no puedo pensar en alguien que sea tan respetado técnicamente que tome esta posición. Pido disculpas si pinché un nervio. Tal vez en mi activismo en otra parte de Internet donde llamo a la gente me puse nervioso: aquí (servidor predeterminado) simplemente soy amable y comparto un profundo conocimiento técnico y el resultado del Sr. Azure es intimidar sobre si mi contribución técnica es incluso necesario o es para algún blog mío (no tengo tal blog). Todavía no tengo la intención de enviar este enlace a alrededor de media docena de amigos clave de Microsoft y preguntarles qué está pasando con este tipo de acoso por parte de un empleado clave de MSFT porque estoy especialmente enfocado en tener el mejor interés de la comunidad en mente y las respuestas a continuación del Sr. Azure son, en pocas palabras, increíbles, vitriólicas, desconcertante e intimidante, que estoy seguro de que algunas personas disfrutan haciéndole a otros Inicialmente me ofendí, pero lo supere y sé que los lectores pasivos o activos apreciarán lo que estoy diciendo y apreciarán mis comentarios; estoy 100% detrás de esto sin tener en cuenta las razones legales por las que aquí es sutilmente inapropiado o no. M. Azure, practique la amabilidad y abstenerse de emitir mis comentarios con poca luz. Solo supéralo y muestra moderación y no hagas comentarios una vez más. por favor practique la amabilidad y abstenerse de emitir mis comentarios con poca luz. Solo supéralo y muestra moderación y no hagas comentarios una vez más. por favor practique la amabilidad y abstenerse de emitir mis comentarios con poca luz. Solo supéralo y muestra moderación y no hagas comentarios nuevamente.

Acosar