xmrig
memory leak！
run xmrig-proxy long time, the memory Rising from 100M to 3G. there is no increase in online users, but there may be different users. I suspect that the user data that has been offline has not been cleaned up, resulting in all the user data that has been logged in being stored in memory and expanding.
The result is that it needs to be restarted once a week, or that oom errors occur.
I noticed you need to restart xmrig-proxy ever now and then or it seems to act up
How many workers do you have? press w to see the list, you may need disable workers support or reduce count.
Thank you.
@ariadarkkkis I don't test V2.14 ,I guess it has the same problem. @xmrig 2K workers. I need workers function. In fact It has nothing to do with workers number，You'll find that memory keeps growing. This is a typical memory leak.
I noticed after running xmrig overnight my memory grew to fill my 32GB of RAM and 16GB of swap, but htop did not attribute memory use to any running process. Even after closing xmrig the memory remains in use. I wonder if my hugepages size is set too large? I will investigate more tomorrow.
and 16GB of swap
Huge pages never get into swap. You can check huge page allocation by running cat /proc/meminfo | grep -i huge on Linux.
Huge pages never get into swap
I think swap filled up because the other software running on the system had to move to swap as xmrig filled up RAM. The machine in question runs quite a lot of software, and usually consumes more than 20GB of RAM without running xmrig and xmrig-proxy.
In any case, I did more investigation today and... I am left with more questions than answers. Initially, I didn't think my hugepages were the cause. I inspected my current setup, and I had not adjusted the hugepages size (they remained at 2048kb), but I had adjusted the number of hugepages to 100,000. But this does not explain the extreme RAM usage, even if every page is used that only means about 200MB of RAM.
However, I reduced the number of hugepages to 3000 and let xmrig + xmrig-proxy run for about 12 hours and I do not see the same memory consumption issues that I was seeing before. So I am unable to reproduce the issue. Perhaps that means reducing nr_hugepages helped but I am not confident. I also noticed another parameter I had previously ignored, "Hugetlb". The linux kernel docs explain that this is "the total amount of memory (in kB), consumed by huge pages of all sizes. If huge pages of different sizes are in use, this number will exceed HugePages_Total * Hugepagesize". After reducing the number of hugepages, my hugetlb is still above 6GB. Perhaps that grew to consume all my RAM when the number of hugepages was at 100000?
I'll fiddle some more, try to reproduce the issue.