Tenemos aproximadamente 200 servidores, Hyper V, File Cluster e IIS, que están experimentando el mismo problema: se produce un evento en el servidor durante el uso normal que maximiza o casi maximiza la RAM en el servidor. Una vez que esto sucede, el servicio SVCHOST/Workstation, específicamente (eliminado aislando el servicio Workstation en su propio SVCHOST) deja de liberar identificadores/subprocesos y la memoria utilizada por ese servicio nunca se libera. En algunos casos extremos, tenemos servicios de estaciones de trabajo que utilizan hasta 40 GB de RAM en un servidor de 255 GB. También se encuentran más de 40 millones de identificadores en algunos casos.
Al reiniciar, el problema, por supuesto, desaparece y no vuelve a aparecer hasta que se haya utilizado toda la memoria, digamos por el proceso W3 o las máquinas virtuales HyperV, después de eso, el servicio Workstation comienza a tomar toda la RAM. El proceso es muy lento y puede tardar semanas/meses dependiendo de la cantidad de RAM en un servidor.
Tanto nuestros servidores Hyper V como nuestros 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 hemos pasado a R2 ya que contamos con muchas herramientas que harán de este un paso importante y no podemos encontrar ninguna indicación clara de que esto se solucione en R2.
Hemos ejecutado ProcMon y otras herramientas, pero en los servidores más problemáticos esas herramientas ni siquiera se ejecutan. En otros, los resultados que proporcionan simplemente 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 reinicios regulares para "solucionar" este problema, por lo que agradeceríamos cualquier respuesta.
Respuesta1
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 limpié y todo volvió a funcionar como si nada hubiera pasado.
(También recomiendo cambiar el tamaño predeterminado del registro de eventos, 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), utilice el control giratorio para establecer el valor que desee y haga clic en Aceptar.
Suena exactamente igual a 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 saldría de control y seguiría consumiendo recursos.
¡Espero que esto ayude!
Respuesta2
>Is there a way we can free up the memory from this process ?
No hay forma de que pueda liberar externamente (correctamente) la memoria asignada o manejar recursos sin eliminar la aplicación infractora.
>or avoid the bug all together?
Está experimentando una pérdida de memoria y recursos. La única manera de resolver el problema es encontrar la fuga y evitar su desencadenante (si es posible) o arreglar la fuga a nivel del código fuente; En el último caso, necesitas ayuda de Microsoft para producir el parche, pero parece que esperan que les digas "exactamente" dónde está realmente el problema.
Puede intentar encontrar al culpable identificando la pérdida de memoria/recursos utilizando, por ejemplo, MSVerificador de aplicaciones
Respuesta3
Crear RAM es fácil pero no es una solución.
Sugiero Sysinternals RAMMAP o VMMAP para una investigación más profunda. Con estas herramientas podrás ver mejor lo que sucede. muy a menudo es un problema de metarchivo.
Desde Server 2008 tenemos este problema con todos los servidores de terminales que se quedan sin memoria con un consumo de memoria increíble a lo largo del tiempo al iniciar aplicaciones desde el recurso compartido.
Nuestra solución alternativa es alojar esas aplicaciones en un servidor de terminal independiente y eliminar con frecuencia el consumo de memoria.
Hacemos esto con una aplicación de línea de comandos C++ autodiseñada usando
SetProcessWorkingSetSize() con SeDebugPrivilege en todos los procesos.
Se recomienda encarecidamente no hacer algo como esto;)