rethinkdbdash: High memory usage with pool and rethink feeds
I discovered that one of my services has a rather high memory usage which grows over time. Did a bit of testing and found that when using rethinkdbdash pooling the closing changefeeds to rethinkdb doesn’t seem to release the related memory. For example when using pooling vs no pooling:
- Both start of with 1000 rethinkdb feeds which evaluates to ~100mb memory usage.
- I trigger some updates for the feed which increases mem usage by another ~100mb.
- After that I GC clean up small amounts ~0-20mb. It doesn’t seem to clean up any more however long I wait.
- After that I close all the cursors.
cursor.close()for each one: - POOLING: memory usage stays the same as with feeds running, nothing is released
- NO POOL: memory usage drops to ~0-20mb over the baseline.
For no pooling I create a new connection for each feed and after closing the cursor I also close the connections with connection.close().
I tried looking at the amount of connections with r.getPoolMaster().getLength(); and r.getPoolMaster().getAvailableLength();, the latter was showing -110 after closing all the feeds.
Would it be possible to purge the connections somehow? Also long-running feeds memory usage will eventually go rather high as no memory seems to be released and every message from rethink seems to increase mem usage. Could this be cleaned up somehow as well?
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 1
- Comments: 19 (11 by maintainers)
Commits related to this issue
- Cut call stack in asyncEach - Second attempt for #263 — committed to neumino/rethinkdbdash by neumino 8 years ago
- Another stab at #263 — committed to neumino/rethinkdbdash by neumino 8 years ago
Thanks @analytik for digging a bit more into it. Rethinkdbdash used to call the callstack in
eachbefore, but for some reason it’s not doing it anymore - I somehow can’t remember when I stopped doing that. I just pushed 2.3.13 with a fix.Script
Result:
2.3.19 should fix the issue. I guess there’s really no way to build a long chain of promises…
Amazing, thank you for your patience with this ticket, and solving it so quickly 😃
Just for the joy of it, here are two services listening to the same changefeed, the climbing one with 2.3.12, the sawtooth one with 2.3.13 -
Again, thanks for rethinkdbdash! (Now only if you had a twin brother who would do the same for python 😄 )
Hi,
I’m sorry, I’ve realized I haven’t explained myself correctly previously. The memory leaks occurs when the changefeed is open a long time and gets a lot of changes and
eachAsyncis used - it just keeps ballooning up with every change. For me, it releases the memory correctly if the connection is closed (I haven’t tested closing and reopening the changefeed without closing the connection, but it seems to be the case based on this output)I’ve modified the script slightly and made a gist here, and this is the output for 15 minutes -
Basically, for every 100k changes, I get ~100MB of leaked memory. The above was run using Node.js 6.2.1 on Windows 8.1 x64, but production servers are on Debian x64, I think it happened on both Node.js 4 and 6.
Thanks for the thorough response. Sorry for the delay in responding on my part. I see that you actually drain the pool. When I use this then all of the memory seemed to be released as expected. Though it seems a bit like a hack to drain the pool. Should using drain() be something done regularly on a production server then? And how would one come back from that? Create a new pool that would initialize new connections?