# Auditbeat memory leak in 8.13.0 **URL:** \ **Category:** Beats\ **Tags:** auditbeat\ **Created:** [April 16, 2024, 11:03am UTC](https://discuss.elastic.co/t/auditbeat-memory-leak-in-8-13-0/357512 "2024-04-16T11:03:26Z")\ **Posts on this page:** 6\ **Page:** 2
**Author:** ![Panos\_Koutsovasilis](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/panos_koutsovasilis/32/133632_2.png) [@Panos\_Koutsovasilis](https://discuss.elastic.co/u/Panos_Koutsovasilis)\ **Post date:** [April 30, 2024, 10:27am UTC](https://discuss.elastic.co/t/auditbeat-memory-leak-in-8-13-0/357512/21 "2024-04-30T10:27:50Z")
okay interesting, thanks for looking into this @nemo; I just pushed another commit in which the pointers are getting "nil"ed at correct code paths, mitigating the panics you observed. Whenever you get the chance please do have another of your excellent experiments (really do appreciate your help). That said, during this second look, I noticed that every time a process forks a child, we copy all the resolved dns names of the parent to the child process. As a result of this design choice, I consider the memory step ups as normal and trying to make this more lightweight, in terms of memory, may need some revisiting ---
**Author:** ![nemo](https://avatars.discourse-cdn.com/v4/letter/n/f07891/32.png) [@nemo](https://discuss.elastic.co/u/nemo)\ **Post date:** [May 9, 2024, 1:24am UTC](https://discuss.elastic.co/t/auditbeat-memory-leak-in-8-13-0/357512/22 "2024-05-09T01:24:34Z")
![image](https://us1.discourse-cdn.com/elastic/original/3X/7/9/792a6e98f39694d335206241717a3abdbf128aae.png) The growth of this memory is still very abnormal...It ran out of memory and caused the machine to crash... @Panos_Koutsovasilis ---
**Author:** ![nemo](https://avatars.discourse-cdn.com/v4/letter/n/f07891/32.png) [@nemo](https://discuss.elastic.co/u/nemo)\ **Post date:** [May 9, 2024, 1:42am UTC](https://discuss.elastic.co/t/auditbeat-memory-leak-in-8-13-0/357512/23 "2024-05-09T01:42:54Z")
I think you need use a global lru replacing the dns cache.... @Panos_Koutsovasilis ---
**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\ **Post date:** [May 9, 2024, 2:17am UTC](https://discuss.elastic.co/t/auditbeat-memory-leak-in-8-13-0/357512/24 "2024-05-09T02:17:59Z")
Hello @Panos_Koutsovasilis, is there a public issue tracking this? We use Elastic Agent and are planning to upgrade from 8.12, I saw this post but could not find any public issue tracking this so it is not clear if this also affects the auditbeat process used by the Elastic Agent. A memory leak that could lead to the machine crashing seems pretty critical, we skipped 8.11 because a similar issue with metricbeat. ---
**Author:** ![Panos\_Koutsovasilis](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/panos_koutsovasilis/32/133632_2.png) [@Panos\_Koutsovasilis](https://discuss.elastic.co/u/Panos_Koutsovasilis)\ **Post date:** [May 9, 2024, 2:37am UTC](https://discuss.elastic.co/t/auditbeat-memory-leak-in-8-13-0/357512/25 "2024-05-09T02:37:51Z")
thank you for checking this again @nemo, I think that the design choice of cloning all map entries during fork is what causing this enormous memory footprint that your charts are capturing and it isn't a memory leak, but eitherway it needs further investigation. So then let's make you capture your nice graphs and all your effort in a issue [here](https://github.com/elastic/beats/issues/new?assignees=&labels=&projects=&template=bug-report.md). This will help with the logistics and will get the necessary attention from the auditbeat owner team PS: thanks for the LRU proposal this needs we will definitely consider it ---
**Author:** ![Panos\_Koutsovasilis](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/panos_koutsovasilis/32/133632_2.png) [@Panos\_Koutsovasilis](https://discuss.elastic.co/u/Panos_Koutsovasilis)\ **Post date:** [May 9, 2024, 2:40am UTC](https://discuss.elastic.co/t/auditbeat-memory-leak-in-8-13-0/357512/26 "2024-05-09T02:40:53Z")
Hi @leandrojmp 👋 @nemo was kind enough to do some experiments for us but at this time point I am not 100% sure of the reason (if it is a memory leak) or a memory heavy design choice. I am leaning towards the latter. Either way, @nemo will capture this in an issue on the beats repo and the team will follow up with updates there [Previous page](https://discuss.elastic.co/t/auditbeat-memory-leak-in-8-13-0/357512.md?page=1)