Uso de memoria de Windows 2012 Core Extreme en el servicio SVCHOST / Workstation

Tenemos aproximadamente 200 servidores, Hyper V, File Cluster e IIS, que están experimentando el mismo problema, un evento ocurre en el servidor a través del uso normal que maximiza o casi maximiza la RAM en el servidor. Una vez que esto sucede, el servicio SVCHOST / Workstation, específicamente (eliminado al aislar el servicio Workstation a su propio SVCHOST) deja de liberar identificadores / subprocesos y la memoria utilizada por ese servicio nunca se libera. Tenemos, en algunos casos extremos, servicios de estaciones de trabajo que utilizan hasta 40 GB de RAM en un servidor de 255 GB. También encontrar más de 40 millones de mangos en algunos casos.

Al reiniciar, el problema, por supuesto, desaparece y no vuelve a aparecer hasta que se haya utilizado toda la memoria, por ejemplo, por el proceso W3 o las máquinas virtuales HyperV, después de eso, el servicio de la estación de trabajo comienza a tomar toda la RAM. El proceso es muy lento y puede llevar semanas / meses dependiendo de la cantidad de RAM en un servidor.

Tanto nuestros servidores Hyper V como los servidores IIS acceden a recursos compartidos para archivos de trabajo, estos recursos compartidos están en almacenamiento SSD, por lo que tienen un gran rendimiento. Hemos instalado todos los parches actuales, pero no nos hemos movido a R2, ya que tenemos muchas herramientas en el lugar que harán de esto un paso significativo y no podemos encontrar ninguna indicación clara de que esto se solucionará en R2.

Hemos ejecutado ProcMon y otras herramientas, pero en los servidores más problemáticos esas herramientas ni siquiera se ejecutarán. En los demás, los resultados que proporcionan solo muestran que parece haber una pérdida de memoria en ese proceso.

¿Hay alguna manera de liberar la memoria de este proceso o evitar el error por completo? No queremos tener que reiniciar y no podemos reiniciar el proceso una vez que está en estado de error. El proceso se congela.

Estamos tratando de evitar reiniciar regularmente para 'solucionar' este problema, por lo que cualquier respuesta sería apreciada.

Tuve un problema inquietantemente similar en el que svchost estaba destruyendo el rendimiento del servidor.

La solución: Resulta que tenía un registro de eventos completo. Lo borré y todo volvió a funcionar como si nada hubiera pasado.

(También recomiendo cambiar el tamaño del registro de eventos del predeterminado, ver más abajo)

Para establecer el tamaño máximo de registro mediante la interfaz de Windows
: inicie el Visor de eventos.
- En el árbol de la consola, navegue y seleccione el registro de eventos que desea administrar.
- En el menú Acción, haga clic en Propiedades.
- En Tamaño máximo de registro (KB), use el control giratorio para establecer el valor que desee y haga clic en Aceptar.

Suena exactamente como lo que está sucediendo aquí, pero terminó siendo una solución realmente fácil. Un reinicio resolvería temporalmente el problema, pero tan pronto como algo intentara escribir en el registro, todo se iría de las manos y seguiría consumiendo recursos.

¡Espero que esto ayude!

>Is there a way we can free up the memory from this process ?

No hay forma de liberar externamente (correctamente) la memoria asignada o manejar recursos sin matar la aplicación ofensiva.

>or avoid the bug all together? 

Está experimentando una pérdida de memoria y recursos. La única forma de resolver el problema es encontrar la fuga y evitar su desencadenante (si es posible) o solucionar la fuga a nivel del código fuente; En el último caso, necesita la ayuda de Microsoft para producir el parche, pero parece que esperan que les diga "exactamente" dónde está realmente el problema.

Puede intentar encontrar al culpable señalando la pérdida de memoria / recursos utilizando, por ejemplo, MS Application Verifier

Crear RAM es fácil pero no hay solución.

Sugiero Sysinternals RAMMAP o VMMAP para una investigación más profunda. Con estas herramientas puedes ver mejor lo que sucede. muy a menudo es un problema de metarchivo.

Desde Server 2008, tenemos este problema con todos los servidores de Terminal Server que se están quedando sin memoria con un consumo de memoria increíble a lo largo del tiempo al iniciar aplicaciones desde el recurso compartido.

Nuestra solución consiste en alojar esas aplicaciones en un Terminal Server separado y eliminar el consumo de memoria con frecuencia.

Hacemos esto con una aplicación de línea de comando c ++ de diseño propio usando
SetProcessWorkingSetSize () con SeDebugPrivilege en todos los procesos

Se recomienda encarecidamente no hacer algo como esto;)