4 ms·

Show HN: Memleax – detects memory leak of a running process

42 points by hellowub 10y ago

hellowub 10y ago
A short time before I met a memory leak problem in production environment. The process began memory leak after long-time running. So I need a tool to detect memory leak of a running process. I searched the web but didn't find one. Then I wrote such a tool myself. I wonder if the tool is useful for others. So I share it here, and wait for your advices.
- wazari972 10y ago
  Interesting idea, I'll give it a try tomorrow! Did you have any particular reason not to use GDB and its Python interface? I guess that the trick is to set a breakpoint on *alloc/free, and inc/decrement a counter on breakpoint hit? I'll try to implement it in my own tool, but in Python!
  - hellowub 10y ago
    I did not know GDB and its Python interface. I think it may be a better way. Expect for your tool!
jasone 10y ago
The fact that this can be used on a process even if you didn't plan at launch time to monitor memory usage is awesome. The main concern I'd have about using it in a production environment is performance impact. There may be no way around this (ptrace is expensive if gdb's impact on running applications is any indication), but the cost of backtracing all allocation sites is also very expensive. You may want to consider adding statistical sampling similar to what tcmalloc and jemalloc use for heap profiling, to reduce the performance impact and make it feasible to remain attached for longer periods of time.
- cyphar 10y ago
  You can attach GDB to running processes as well. Though I'm guessing you're making the comparison to valgrind. GDB could also be used to find memory leaks, but maybe not some of the more weird memory bugs.
  - hellowub 10y ago
    I did not know GDB well, and wrote this for fun. wazari972 is going to write a tool using GDB and its python interface. Let's expect for it.
- hellowub 10y ago
  Because target progress's each memory allocation/free API invokes a TRAP, the performance influence depends on how often the target program calls memory APIs. For example, it impacts lightly to nginx with HTTP, while heavily with HTTPS, because OpenSSL calls malloc seriously. Although performance influence is worthy of consideration, since `memleax` is run to attach the target progress only when you certain it is in memory leak, and stopped after real-time memory leak report, so it is not need to attach the target progress for long time. -- I have added the above to README.md in new version. Because you can stop memleax as soon as you get enough memory leak report, so the sampling idea will delay the stopping, which make the impact longer. -- My English is poor, and hope I can make myself understood.
honua 10y ago
Hm.. It'd be cool if I could run this on Heroku, though maybe that's a reason to switch to something like AWS?
- hellowub 10y ago
  Hm.. I do not know Heroku. Is there any problem that I could fix?

42 points by hellowub 10y ago

A short time before I met a memory leak problem in production environment. The process began memory leak after long-time running. So I need a tool to detect memory leak of a running process. I searched the web but didn't find one. Then I wrote such a tool myself. I wonder if the tool is useful for others. So I share it here, and wait for your advices.

wazari972 10y ago
Interesting idea, I'll give it a try tomorrow! Did you have any particular reason not to use GDB and its Python interface? I guess that the trick is to set a breakpoint on *alloc/free, and inc/decrement a counter on breakpoint hit? I'll try to implement it in my own tool, but in Python!
- hellowub 10y ago
  I did not know GDB and its Python interface. I think it may be a better way. Expect for your tool!

jasone 10y ago

The fact that this can be used on a process even if you didn't plan at launch time to monitor memory usage is awesome. The main concern I'd have about using it in a production environment is performance impact. There may be no way around this (ptrace is expensive if gdb's impact on running applications is any indication), but the cost of backtracing all allocation sites is also very expensive. You may want to consider adding statistical sampling similar to what tcmalloc and jemalloc use for heap profiling, to reduce the performance impact and make it feasible to remain attached for longer periods of time.

cyphar 10y ago
You can attach GDB to running processes as well. Though I'm guessing you're making the comparison to valgrind. GDB could also be used to find memory leaks, but maybe not some of the more weird memory bugs.
- hellowub 10y ago
  I did not know GDB well, and wrote this for fun. wazari972 is going to write a tool using GDB and its python interface. Let's expect for it.
hellowub 10y ago
Because target progress's each memory allocation/free API invokes a TRAP, the performance influence depends on how often the target program calls memory APIs. For example, it impacts lightly to nginx with HTTP, while heavily with HTTPS, because OpenSSL calls malloc seriously. Although performance influence is worthy of consideration, since `memleax` is run to attach the target progress only when you certain it is in memory leak, and stopped after real-time memory leak report, so it is not need to attach the target progress for long time. -- I have added the above to README.md in new version. Because you can stop memleax as soon as you get enough memory leak report, so the sampling idea will delay the stopping, which make the impact longer. -- My English is poor, and hope I can make myself understood.

honua 10y ago

Hm.. It'd be cool if I could run this on Heroku, though maybe that's a reason to switch to something like AWS?

hellowub 10y ago
Hm.. I do not know Heroku. Is there any problem that I could fix?