* [PATCH] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby @ 2018-07-20 9:25 Eric Wong 2018-07-20 9:34 ` [ANN] " Eric Wong 0 siblings, 1 reply; 7+ messages in thread From: Eric Wong @ 2018-07-20 9:25 UTC (permalink / raw) To: ruby-talk, mwrap-public mwrap is designed to answer the question: Which lines of Ruby are hitting malloc the most? mwrap wraps all malloc-family calls to trace the Ruby source location of such calls and bytes allocated at each callsite. As of mwrap 2.0.0, it can also function as a leak detector and show live allocations at every call site. Depending on your application and workload, the overhead is roughly a 50% increase memory and runtime. It works best for allocations under GVL, but tries to track numeric caller addresses for allocations made without GVL so you can get an idea of how much memory usage certain extensions and native libraries use. It requires the concurrent lock-free hash table from the Userspace RCU project: https://liburcu.org/ It does not require recompiling or rebuilding Ruby, but only supports Ruby trunk (2.6.0dev+) on a few platforms: * GNU/Linux * FreeBSD (tested 11.1) It may work on NetBSD, OpenBSD and DragonFly BSD. Changes in 2.0.0: This release includes significant changes to track live allocations and frees. It can find memory leaks from malloc with less overhead than valgrind's leakchecker and there is a new Rack endpoint (MwrapRack) which can display live allocation stats. API additions: * Mwrap#[] - https://80x24.org/mwrap/Mwrap.html#method-c-5B-5D * Mwrap::SourceLocation - https://80x24.org/mwrap/Mwrap/SourceLocation.html * MwrapRack - https://80x24.org/mwrap/MwrapRack.html Incompatible changes: * Mwrap.clear now an alias to Mwrap.reset; as it's unsafe to implement the new Mwrap#[] API otherwise: https://80x24.org/mwrap-public/20180716211933.5835-12-e@80x24.org/ 26 changes since v1.0.0: README: improve usage example MANIFEST: add .document add benchmark use __attribute__((weak)) instead of dlsym Mwrap.dump: do not segfault on invalid IO arg bin/mwrap: support LISTEN_FDS env from systemd support per-allocation headers for per-alloc tracking mwrap: use malloc to do our own memalign hold RCU read lock to insert each allocation realloc: do not copy if allocation failed internal_memalign: do not assume real_malloc succeeds ensure ENOMEM is preserved in errno when appropriate memalign: check alignment on all public functions reduce stack usage from file names resolve real_malloc earlier for C++ programs allow analyzing live allocations via Mwrap[location] alias Mwrap.clear to Mwrap.reset implement accessors for SourceLocation mwrap_aref: quiet -Wshorten-64-to-32 warning fixes for FreeBSD 11.1... use memrchr to extract address under glibc do not track allocations for constructor and Init_ disable memalign tracking by default support Mwrap.quiet to temporarily disable allocation tracking mwrap_rack: Rack app to track live allocations documentation updates for 2.0.0 release ^ permalink raw reply [flat|nested] 7+ messages in thread
* [ANN] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby 2018-07-20 9:25 [PATCH] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby Eric Wong @ 2018-07-20 9:34 ` Eric Wong 2018-07-26 1:36 ` Sam Saffron 0 siblings, 1 reply; 7+ messages in thread From: Eric Wong @ 2018-07-20 9:34 UTC (permalink / raw) To: ruby-talk, mwrap-public Oops, forgot to include links, and title is [ANN] :x Mailing list: https://80x24.org/mwrap-public/ nntp://80x24.org/inbox.comp.lang.ruby.mwrap mailto:mwrap-public@80x24.org (no HTML mail, please) git clone https://80x24.org/mwrap.git homepage + rdoc: https://80x24.org/mwrap/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANN] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby 2018-07-20 9:34 ` [ANN] " Eric Wong @ 2018-07-26 1:36 ` Sam Saffron 2018-07-26 1:37 ` Sam Saffron 0 siblings, 1 reply; 7+ messages in thread From: Sam Saffron @ 2018-07-26 1:36 UTC (permalink / raw) To: Ruby users; +Cc: mwrap-public I am using mwrap to debug a little leak at the moment, one feature request I do have though is a tally of totals. It would be nice if it could keep track of total allocated and total released. That way if my RSS is bloating I can tell if it is due to fragmentation or if it is due to a genuine leak really quick. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANN] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby 2018-07-26 1:36 ` Sam Saffron @ 2018-07-26 1:37 ` Sam Saffron 2018-07-26 2:46 ` Eric Wong 0 siblings, 1 reply; 7+ messages in thread From: Sam Saffron @ 2018-07-26 1:37 UTC (permalink / raw) To: Ruby users; +Cc: mwrap-public Just to clarify here, I mean 2 single global totals, not a per row kind of thing. On Thu, Jul 26, 2018 at 11:36 AM, Sam Saffron <sam.saffron@gmail.com> wrote: > I am using mwrap to debug a little leak at the moment, one feature > request I do have though is a tally of totals. > > It would be nice if it could keep track of total allocated and total > released. That way if my RSS is bloating I can tell if it is due to > fragmentation or if it is due to a genuine leak really quick. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANN] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby 2018-07-26 1:37 ` Sam Saffron @ 2018-07-26 2:46 ` Eric Wong 2018-07-26 5:02 ` Sam Saffron 0 siblings, 1 reply; 7+ messages in thread From: Eric Wong @ 2018-07-26 2:46 UTC (permalink / raw) To: Sam Saffron; +Cc: ruby-talk, mwrap-public Sam Saffron <sam.saffron@gmail.com> wrote: > Just to clarify here, I mean 2 single global totals, not a per row > kind of thing. > > On Thu, Jul 26, 2018 at 11:36 AM, Sam Saffron <sam.saffron@gmail.com> wrote: > > I am using mwrap to debug a little leak at the moment, one feature > > request I do have though is a tally of totals. > > > > It would be nice if it could keep track of total allocated and total > > released. That way if my RSS is bloating I can tell if it is due to > > fragmentation or if it is due to a genuine leak really quick. Something like the patch below? (Barely tested) Since mwrap doesn't track its own memory usage; this might be useful if you have a lot of cold code paths doing allocations, since RSS might not stabilize quickly in that case. Also, if there's a leaker using a malloc wrapper like Ruby's xmalloc (e.g. https://bugs.ruby-lang.org/issues/14929 ) ; mwrap won't make it easy to track down since it can only safely see the one level up the call stack (using GCC's __builtin_return_address with a non-zero level isn't safe) diff --git a/ext/mwrap/mwrap.c b/ext/mwrap/mwrap.c index acc8960..9bb44d0 100644 --- a/ext/mwrap/mwrap.c +++ b/ext/mwrap/mwrap.c @@ -32,6 +32,8 @@ extern size_t __attribute__((weak)) rb_gc_count(void); extern VALUE __attribute__((weak)) rb_cObject; extern VALUE __attribute__((weak)) rb_yield(VALUE); +static size_t total_bytes_inc, total_bytes_dec; + /* true for glibc/dlmalloc/ptmalloc, not sure about jemalloc */ #define ASSUMED_MALLOC_ALIGNMENT (sizeof(void *) * 2) @@ -327,6 +329,8 @@ static struct src_loc *update_stats_rcu_lock(size_t size, uintptr_t caller) if (caa_unlikely(!totals)) return 0; if (locating++) goto out; /* do not recurse into another *alloc */ + uatomic_add(&total_bytes_inc, size); + rcu_read_lock(); if (has_ec_p()) { int line; @@ -390,6 +394,7 @@ void free(void *p) if (l) { size_t age = generation - h->as.live.gen; + uatomic_add(&total_bytes_dec, h->size); uatomic_set(&h->size, 0); uatomic_add(&l->frees, 1); uatomic_add(&l->age_total, age); @@ -710,12 +715,16 @@ static VALUE mwrap_dump(int argc, VALUE * argv, VALUE mod) return Qnil; } +/* The whole operation is not remotely atomic... */ static void *totals_reset(void *ign) { struct cds_lfht *t; struct cds_lfht_iter iter; struct src_loc *l; + uatomic_set(&total_bytes_inc, 0); + uatomic_set(&total_bytes_dec, 0); + rcu_read_lock(); t = rcu_dereference(totals); cds_lfht_for_each_entry(t, &iter, l, hnode) { @@ -1033,6 +1042,16 @@ static VALUE mwrap_quiet(VALUE mod) return rb_ensure(rb_yield, SIZET2NUM(cur), reset_locating, 0); } +static VALUE total_inc(VALUE mod) +{ + return SIZET2NUM(total_bytes_inc); +} + +static VALUE total_dec(VALUE mod) +{ + return SIZET2NUM(total_bytes_dec); +} + /* * Document-module: Mwrap * @@ -1084,6 +1103,8 @@ void Init_mwrap(void) rb_define_singleton_method(mod, "each", mwrap_each, -1); rb_define_singleton_method(mod, "[]", mwrap_aref, 1); rb_define_singleton_method(mod, "quiet", mwrap_quiet, 0); + rb_define_singleton_method(mod, "total_bytes_allocated", total_inc, 0); + rb_define_singleton_method(mod, "total_bytes_freed", total_dec, 0); rb_define_method(cSrcLoc, "each", src_loc_each, 0); rb_define_method(cSrcLoc, "frees", src_loc_frees, 0); rb_define_method(cSrcLoc, "allocations", src_loc_allocations, 0); diff --git a/test/test_mwrap.rb b/test/test_mwrap.rb index 8425c35..d112b4e 100644 --- a/test/test_mwrap.rb +++ b/test/test_mwrap.rb @@ -272,4 +272,15 @@ class TestMwrap < Test::Unit::TestCase res == :foo or abort 'Mwrap.quiet did not return block result' end; end + + def test_total_bytes + assert_separately(+"#{<<~"begin;"}\n#{<<~'end;'}") + begin; + require 'mwrap' + Mwrap.total_bytes_allocated > 0 or abort 'nothing allocated' + Mwrap.total_bytes_freed > 0 or abort 'nothing freed' + Mwrap.total_bytes_allocated > Mwrap.total_bytes_freed or + abort 'freed more than allocated' + end; + end end ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [ANN] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby 2018-07-26 2:46 ` Eric Wong @ 2018-07-26 5:02 ` Sam Saffron 2018-07-26 6:21 ` Eric Wong 0 siblings, 1 reply; 7+ messages in thread From: Sam Saffron @ 2018-07-26 5:02 UTC (permalink / raw) To: Eric Wong; +Cc: Ruby users, mwrap-public Yes, this patch looks right to me. Even if we don't have perfect fidelity here it will give absolute clarity on "leak" vs "fragmentation related bloat". Even though jemalloc tries hard to compensate for fragmentation bloat is still possible. For full context here is a dump when I started the process (it was 500meg rss) https://transfer.sh/Q9zQS/start.txt Here is how it looks now (1.2G rss): https://transfer.sh/14fokY/now.txt The script I use to generate this stuff is: https://github.com/discourse/discourse/blob/master/script/mwrap_sidekiq ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANN] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby 2018-07-26 5:02 ` Sam Saffron @ 2018-07-26 6:21 ` Eric Wong 0 siblings, 0 replies; 7+ messages in thread From: Eric Wong @ 2018-07-26 6:21 UTC (permalink / raw) To: Sam Saffron; +Cc: ruby-talk, mwrap-public Sam Saffron <sam.saffron@gmail.com> wrote: > Yes, this patch looks right to me. OK, I've just pushed it out to RubyGems.org as a prerelease: mwrap-2.0.0.4.gd1ea.gem > Even if we don't have perfect fidelity here it will give absolute > clarity on "leak" vs "fragmentation related bloat". Even though > jemalloc tries hard to compensate for fragmentation bloat is still > possible. Just wondering, are you still on jemalloc 3.6.0 or one of the newer versions? I seem to remember 3.6.0 interacting badly with cross-thread frees (from another project years ago); and mwrap relies on call_rcu to free memory which is in another thread... Maybe narenas:1 or even using MALLOC_ARENA_MAX=1 glibc malloc might make it easier to discern a real leak from fragmentation. In any case; one technique I've used in the past which never required special debugging tools (aside from source access) was to use a bisection search over the code path. I disabled/skipped over half the remaining code until the leak could no longer be reproduced to narrow down where it did happen. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-07-26 6:21 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-20 9:25 [PATCH] mwrap 2.0.0 mwrap - LD_PRELOAD malloc wrapper for Ruby Eric Wong 2018-07-20 9:34 ` [ANN] " Eric Wong 2018-07-26 1:36 ` Sam Saffron 2018-07-26 1:37 ` Sam Saffron 2018-07-26 2:46 ` Eric Wong 2018-07-26 5:02 ` Sam Saffron 2018-07-26 6:21 ` Eric Wong
Code repositories for project(s) associated with this public inbox https://80x24.org/mwrap.git/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).