El problema era la conexión a RabbitMQ. Debido a que estábamos usando ordenar canales en vivo, la función de "reconexión automática" de RabbitMQ.Client mantenía mucho estado sobre los canales muertos. Desactivamos esta configuración, ya que no necesitamos las "ventajas" de la función de "reconexión automática", y todo comienza a funcionar normalmente. Fue una molestia, pero básicamente tuvimos que configurar una implementación de Windows y realizar el proceso de análisis de memoria habitual con las herramientas de Windows (Jetbrains dotMemory en este caso). Usar lldb no es productivo en absoluto.
Descargo de responsabilidad:no soy un asistente de .NET.
Pero debe hacer dos cosas para seguir las mejores prácticas de Kubernetes:
-
Defina límites de recursos sensibles para su aplicación. Si la aplicación no necesita más de 200 MB de memoria, defina un límite de recursos para evitar que la aplicación consuma toda la memoria del host disponible. Pero tenga en cuenta que la API de Unix para obtener memoria disponible no es capaz de procesar el cgroup que tiene el proceso y siempre genera la memoria del host sin importar lo que diga su cgroup.
-
Dígale a su aplicación cuál es este límite de recursos. Parece que su aplicación no "siente la necesidad" de liberar memoria, ya que hay mucha. Casi todas las aplicaciones, y también los marcos, tienen un interruptor para definir la memoria máxima que se consumirá. Dígale a su aplicación este límite, y "verá" la presión de la memoria y realizará un GC completo (lo que supongo que podría ser el problema aquí)