haskell - Depuración de una pérdida de memoria que no se muestra en el perfil de montón

memory-leaks profiling

Question

Estoy trabajando en un daemon Haskell que recibe y procesa solicitudes JSON. Si bien las operaciones del daemon son complejas, la estructura principal se mantiene intencionalmente simple: su estado interno es solo un IORef con una estructura de datos y todos los hilos realizan operaciones atómicas en este IORef . Luego hay algunos hilos que sobre un disparador toman el valor de hacer algo con él.

El problema es que el daemon está perdiendo memoria y no puedo descubrir por qué. Ciertamente está relacionado con las solicitudes: cuando el daemon recibe varias solicitudes por segundo, pierde algo así como 1 MB / s (según lo informado por las herramientas de Linux). El consumo de memoria aumenta constantemente. Sin solicitudes, el consumo de memoria permanece constante.

Lo que me desconcierta es que nada de esto se muestra en los perfiles de GHC. O me falta algo en los parámetros de creación de perfiles, o la memoria es consumida por otra cosa:

Ejecutar con +RTS -hc -xt -p :

Ejecutar con +RTS -hr -xt -p :

Durante esta ejecución de prueba, el daemon consume más de 1 GB. Por lo tanto, los datos de generación de perfiles claramente no se corresponden con la memoria consumida real en órdenes de magnitud. (Entiendo que el RTS, el GC y el perfilado se agregan al consumo de memoria real, pero esta diferencia es demasiado grande y no corresponde al consumo cada vez mayor).

Ya traté de rnf todos los datos de estado del daemon dentro del IORef , así como las solicitudes JSON analizadas (para evitar que se retuvieran partes de las cadenas JSON), pero sin mucho éxito.

Cualquier idea o sugerencia bienvenida.

Actualización: el daemon se ejecuta sin -threaded , por lo que no hay subprocesos de nivel del sistema operativo.

Las estadísticas de GC están mucho más cerca del perfil de montón que de las cifras reportadas por Linux:

    Alloc    Copied     Live    GC    GC     TOT     TOT  Page Flts
    bytes     bytes     bytes  user  elap    user    elap
[...]
  5476616     44504   2505736  0.00  0.00   23.21  410.03    0    0  (Gen:  0)
 35499296     41624   2603032  0.00  0.00   23.26  410.25    0    0  (Gen:  0)
 51841800     46848   2701592  0.00  0.00   23.32  410.49    0    0  (Gen:  0)
 31259144     36416   2612088  0.00  0.00   23.40  410.61    0    0  (Gen:  0)
 53433632     51976   2742664  0.00  0.00   23.49  412.05    0    0  (Gen:  0)
 48142768     50928   2784744  0.00  0.00   23.54  412.49    0    0  (Gen:  0)
[...]

Actualización 2: Encontré el origen del problema, la pérdida de memoria es causada por handleToFd (consulte este problema para la biblioteca de Unix ). Me pregunto cómo sería posible identificar de manera más efectiva una fuga de este tipo (tal vez en una pieza de código extranjera).

Answer 1

Si bien no estoy familiarizado con el daemon Haskell en sí mismo, respondiendo a su pregunta "¿cómo sería posible identificar con mayor eficacia una fuga de este tipo?", Podría ser posible utilizar

valgrind --leak-check=yes haskelldaemon (mejor si lo compila con información de depuración),

O, si la fuga ocurre en la biblioteca compartida, pruebe

LD_PRELOAD="yourlibrary.so" valgrind your-executable .