Gestión de memoria para aplicaciones intensivas en memoria intencionalmente

Question

Nota: Conozco la pregunta Memory management in memory intensive application, sin embargo, esa pregunta parece ser sobre aplicaciones que hacen frecuentes asignaciones de memoria, mientras que mi pregunta es sobre aplicaciones intencionalmente diseñadas para consumir tanta memoria física como es seguro.

Tengo una aplicación de servidor que usa grandes cantidades de memoria para realizar el almacenamiento en caché y otras optimizaciones (piense en SQL Server). La aplicación se ejecuta en una máquina dedicada, por lo que puede (y debe) consumir la cantidad de memoria que quiera/pueda para acelerar y aumentar el rendimiento y los tiempos de respuesta sin preocuparse de afectar a otras aplicaciones en el sistema.

El problema es que si se subestima el uso de la memoria, o si aumenta la carga, es posible que termine con fallas desagradables ya que las asignaciones de memoria fallan; en esta situación, obviamente lo mejor es liberar memoria para evitar falla a expensas del rendimiento.

Algunos supuestos:

• la aplicación se ejecuta en una máquina dedicada
• Los requisitos de memoria de la aplicación exceden la memoria física en la máquina (es decir, si estaba disponible para la aplicación que la memoria expandible siempre será capaz de usar esa memoria para de alguna manera mejorar los tiempos de respuesta o el rendimiento)
• La memoria se gestiona de forma efectiva de manera que la fragmentación de la memoria no sea un problema.
• La aplicación sabe qué memoria se puede liberar con seguridad, y qué memoria se debe liberar primero para el menor impacto de rendimiento.
• Las carreras de aplicaciones en una máquina Windows

Mi pregunta es - ¿Cómo debo manejar las asignaciones de memoria en una aplicación de este tipo? En particular:

• ¿Cómo puedo predecir si una asignación de memoria fallará o no?
• ¿Debo dejar cierta cantidad de memoria libre para garantizar que las operaciones del sistema operativo principal sigan siendo receptivas (y de esa manera no afecten adversamente el rendimiento de las aplicaciones) y cómo puedo saber cuánta memoria hay?

El objetivo central es evitar fallos como resultado del uso de demasiada memoria, mientras que al mismo tiempo utilizando la mayor cantidad de memoria posible.

Soy un desarrollador de C#, sin embargo, mi esperanza es que los conceptos básicos para cualquier aplicación de este tipo sean los mismos independientemente del idioma.

Answer 1

En Linux, el porcentaje de uso de memoria se divide en los siguientes niveles.

0 - 30% - sin intercambio 30 - 60% - páginas sucias de intercambio solo 60 - 90% - páginas de intercambio de intercambio también basadas en la política de LRU.

90% - Invocar OOM (Sin memoria) matar y matar el proceso que consume la memoria máxima.

cheque esto - http://linux-mm.org/OOM_Killer

En las ventanas piensa que podría tener una política similar, por lo que puede comprobar las estadísticas de memoria y asegurarse de que nunca llegue al umbral máximo.

Una forma de dejar de consumir más memoria es ir a dormir y dar más tiempo para que se ejecuten los hilos de limpieza de la memoria.

Answer 2

Esa es una muy buena pregunta, y también será subjetiva, porque la naturaleza misma de la característica fundamental de C# es que toda la administración de la memoria es realizada por el tiempo de ejecución, es decir, Garbage Collector. El recolector de basura es una entidad no determinista que administra y barre la memoria para reclamar, dependiendo de la frecuencia con la que la memoria se fragmente, el GC entrará en acción, por lo tanto, saber de antemano no es algo fácil de hacer.

Para administrar correctamente la memoria suena tedioso, pero se aplica el sentido común, como la cláusula using para asegurar que un objeto sea eliminado. Podrías poner un solo controlador para atrapar el OutOfMemory Exception, pero eso es una forma incómoda, ya que si el programa se ha quedado sin memoria, el programa simplemente se agarrota y explota, o debería esperar pacientemente a que el GC entre en acción. , una vez más determinar que es complicado.

La carga del sistema puede afectar negativamente el trabajo del CG, casi a un punto de un ataque de Denegación de Servicio, donde todo detendría, de nuevo, ya que las especificaciones de la máquina, o lo que es la naturaleza de esa el trabajo de la máquina es desconocido, no puedo responderlo completamente, pero supongo que tiene mucha RAM ...

En esencia, aunque es una excelente pregunta, creo que no deberías preocuparte por eso y dejarlo en .NET. CLR para manejar la asignación de memoria/fragmentación, ya que parece hacer un trabajo bastante bueno.

Espero que esto ayude, Saludos cordiales, Tom.

Answer 3

Su pregunta me recuerda a una discusión anterior "So what's wrong with 1975 programming ?". El arquitecto de varnish-cache argumenta que, en lugar de decirle al sistema operativo que salga del camino y administre toda la memoria usted mismo, debería cooperar con el sistema operativo y dejar que comprenda qué piensa hacer con la memoria.

Por ejemplo, en lugar de simplemente leer datos del disco, debe usar memory-mapped files. Esto permite que el sistema operativo aplique su algoritmo LRU para reescribir datos en el disco cuando la memoria escasea. Al mismo tiempo, mientras haya suficiente memoria, sus datos permanecerán en la memoria. Por lo tanto, su aplicación puede utilizar toda la memoria, sin riesgo de ser asesinado.