15 commentaires
classique. glibc et les threads python ça fait pas bon ménage sur la gestion des arènes. par défaut glibc crée jusqu'à 8 arènes par cœur cpu. ça fragmente à mort.
t'as essayé de limiter les arènes avec une variable d'environnement ?
voilà le retour du rollup :
Rss: 1245672 kB
Pss: 1210432 kB
Shared_Clean: 512 kB
Shared_Dirty: 0 kB
Private_Clean: 124 kB
Private_Dirty: 1245036 kB
Referenced: 1245672 kB
Anonymous: 1245012 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kBpresque tout est en private dirty. c'est pas du leak de lib externe on dirait.
si ton heap python est stable c'est forcément la glibc qui retient les pages. elle utilise brk() ou mmap() pour tes allocs ?
si c'est du brk() et que t'as un objet long-lived tout en haut du tas ça bloque toute la libération en dessous.
ajoute ça pour que jemalloc rende la mémoire plus vite :
MALLOC_CONF="dirty_decay_ms:1000,muzzy_decay_ms:1000"check quand même tes latences. jemalloc peut rajouter un peu d'overhead sur les allocs très fréquentes mais normalement sur du python ça se voit pas.
Laisser une réponse
Vous devez être connecté pour poster un message !
hello. on a un souci de fuite mémoire sur nos workers python en prod. l'appli tourne sur debian bullseye. le RSS monte linéairement jusqu'au OOM-kill du pod sans jamais redescendre même après un cycle GC complet.
on a déjà checké avec tracemalloc et objgraph. l'heap python est stable. le souci semble être au niveau de l'allocateur système. c'est une horreur à debugger.