2011-11-28 41 views
7

Tengo un problema con la administración de memoria en mi aplicación. La memoria de la aplicación está creciendo rápidamente durante el tiempo de ejecución. Estoy usando conjuntos de datos en el modo desconectado. Para solucionar este problema, estoy descargando el DS con frecuencia y también usando SetProcessWorkingSetSize para administrar el uso de la memoria. Está funcionando bien en mi computadora de desarrollo. ¿Cuáles son los pros y los contras de usar SetProcessWorkingSetSize?Pros y contras de usar SetProcessWorkingSetSize

+3

Difícil imaginar que esto haga algo más que obstaculizar el rendimiento de otro proceso sin ganancia para su proceso. –

+0

Parece que tiene una pérdida de memoria, que la API de Win32 no puede resolver por usted. Use algo como UMDH para obtener volcados de memoria y localizar la fuga. –

Respuesta

12

SetProcessWorkingSetSize() controla la cantidad de RAM que usa su proceso, de lo contrario no afecta el tamaño de la memoria virtual de su proceso. Windows ya es bastante bueno para controlar dinámicamente esto, intercambiando páginas de memoria a pedido cuando otro proceso necesita RAM. Al hacerlo manualmente, ralentiza mucho su programa, causando una gran cantidad de fallas de página cuando Windows se ve obligado a intercambiar las páginas de memoria nuevamente. SetProcessWorkingSetSize se usa generalmente para aumentar la cantidad de RAM asignada para un proceso. O forzar un recorte cuando la aplicación sabe que va a estar inactiva durante mucho tiempo. También lo hacen automáticamente las versiones anteriores de Windows cuando minimizas la ventana principal de la aplicación.

No es necesario marcar este byt, puede usar las propiedades Process.GetCurrentProcess.Min/MaxWorkingSet.

3

El único caso de buen uso que he visto para esta llamada es cuando usted SABE que su proceso va a acaparar una gran cantidad de la RAM del sistema y desea reservarla para la duración. Lo usas para decirle al sistema operativo: "Sí, voy a comer gran cantidad de RAM del sistema durante toda mi carrera y no me interpondré en mi camino".

En esa situación, dejar el comportamiento predeterminado del sistema operativo en su lugar es malo. El sistema operativo asigna un número predeterminado de MB de RAM a cada proceso, básicamente su área de trabajo. Sus heurísticas de gestión de recursos no son oráculos, por lo que si detectan que algunos procesos consumen mucho más que su parte de los recursos del sistema (como la memoria RAM), tratarán de recuperar la mayor cantidad de exceso posible. Para SU proceso, esto significa que el sistema operativo perderá una gran cantidad de CPU (y, por lo tanto, dañará su rendimiento) al mover la memoria dentro y fuera de su espacio de direcciones cuando no sea necesario.

0

Hemos descubierto que, para una aplicación GUI escrita en Delphi para Win32/Win64 o escrita de manera similar que usa bibliotecas grandes y pesadas sobre la API Win32 (GDI, etc.), vale la pena llamar a SetProcessWorkingSetSize una vez.

Lo llamamos con -1, -1 parámetros, en una fracción de segundo después de que la aplicación se haya abierto completamente y mostramos la ventana principal al usuario. En este caso, SetProcessWorkingSetSize (... -1, -1) libera muchos códigos de inicio que parecen no necesitar más. La memoria se restaura rápidamente a aproximadamente 1/3 de lo que hubiera sido sin SetProcessWorkingSetSize (... -1, -1), pero no crece más. Así que efectivamente hemos guardado 2/3 de la memoria de la mayoría de los códigos de inicio (carga y análisis de archivos de configuración, inicialización de la GUI, etc.) que quizás nunca se necesitaron.

Si tiene una aplicación de GUI, puede probar en su propia aplicación de la misma manera: solo llámelo una vez y vea la cantidad de memoria que se ha liberado definitivamente.

Incluso para una aplicación de servidor (servicio) que no tiene GUI, creo que llamar SetProcessWorkingSetSize una vez después de que el servidor se haya cargado completamente e inicializado podría haber sido útil.