Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jason Frey
    @Fryguy
    @NickLaMuro oh yeah?
    rails.bad 2018-01-17 12-04-44.png
    Nick LaMuro
    @NickLaMuro
    but do you have multiple windows of chrome open?
    also, shameless self plug for my S***ty javascript: gist
    Jason Frey
    @Fryguy
    haha I had one of those pop-up gmail windows open..does that count?
    Nick LaMuro
    @NickLaMuro
    well, with that, I have 6 windows open, and 123 tabs open
    Jason Frey
    @Fryguy
    ༼ ༎ຶ ෴ ༎ຶ༽ you win
    Nick LaMuro
    @NickLaMuro
    I have been close to 300 at one point :cry:
    the reason I close is mostly because of "hey, I am really using a lot of swap huh... probably should fix that..."
    Keenan Brock
    @kbrock
    I sometimes bookmark all tabs (put a date in it -knowing I'll never come back)
    best way of declaring tab bankrupcy with fooling myself that I'm not doing that
    Nick LaMuro
    @NickLaMuro
    a lot of it ends up being documentation, which I am trying to push down into my terminal when possible
    Keenan Brock
    @kbrock
    @NickLaMuro so I'm looking at an appliance that is reusing PIDs 3times / day
    Any suggestions for removing false pid dups?
    Nick LaMuro
    @NickLaMuro
    (using ri for ruby documentation, and recently info for gdb docs (or in my case https://github.com/vim-scripts/info.vim ))
    Keenan Brock
    @kbrock
    I was thinkng about reading a "exiting worker" and then removing the entry from the hash of hash[PID] => {} (in my logs)
    Nick LaMuro
    @NickLaMuro
    @kbrock with a lot of my scripts, the regexp usually includes a --worker-type pass in
    Jason Frey
    @Fryguy
    really useful for tag bankruptcy is the OneTab extension
    Keenan Brock
    @kbrock
    k - when reading the PIDs from evm.log, not totally known until a little bit
    hmm - will look into that. thanks
    Nick LaMuro
    @NickLaMuro
    we use a lot of sys calls for general things in our app, which doesn't help the problem
    NickLaMuro @NickLaMuro is a big stickler for avoiding using syscalls in applications, mind you
    Jason Frey
    @Fryguy
    @NickLaMuro did you try your linux_admin require patch on an appliance?
    there is some caveats with the above, and hopefully I can get some more needed info in a bit
    Jason Frey
    @Fryguy
    talking with @tenderlove separately, and he hadn't heard of require leaking elsewhere
    You could try using malloc stack logging on MacOS. It logs every malloc / free and the stack for that malloc / free.
    Nick LaMuro
    @NickLaMuro
    now you tell me...
    Jason Frey
    @Fryguy
    ¯\_(ツ)_/¯
    Nick LaMuro
    @NickLaMuro

    talking with @tenderlove separately, and he hadn't heard of require leaking elsewhere

    This doesn't surprise me though, since we did see that a vanilla rails app didn't seem to leak with require (ref: LJ's tests)

    Jason Frey
    @Fryguy
    yeah, I was hoping against hope
    Nick LaMuro
    @NickLaMuro
    appreciate you checking though, thanks!
    Jason Frey
    @Fryguy

    if you set the MallocStackLogging environment variable, you can use the malloc_history commandline tool.

    I would either 1) wait until memory grows really huge, then run malloc_history -callTree and find the offender, or 2) take a snapshot before, then run for a bit, and take a second snapshot and compare

    Nick LaMuro
    @NickLaMuro
    heh, this is pretty much what I ended up doing with gdb
    Jason Frey
    @Fryguy
    yeah it sounded similar
    Nick LaMuro
    @NickLaMuro
    except I was taking memdumps based on the smaps location of the heap, after forcing some leaks using
    (gdb) p rb_eval_string("MiqSystem.num_cpus")
    Joe Rafaniello
    @jrafanie
    @NickLaMuro so, sampling in osx shows similar behavior for the "require empty.rb" test in a loop(I started sampling after the process loaded rails (reached 145 or so MB)
    blob
    Jason Frey
    @Fryguy
    I'm not sure what I am looking at there (or what I am supposed to see)
    Nick LaMuro
    @NickLaMuro

    @Fryguy the call stack is the inverse of what I was showing here in my screenshot:

    https://gitter.im/ManageIQ/manageiq/performance?at=5a5ecc316117191e6175158b

    Jason Frey
    @Fryguy
    right, but I don't know what either of those mean
    Joe Rafaniello
    @jrafanie
    It's interesting, I don't see rb_feature_p in the vanilla rails top samples
    0.441s above :point_up:
    Jason Frey
    @Fryguy
    ok?
    Nick LaMuro
    @NickLaMuro

    well, mine specifically is one invocation of malloc and the stacktrace at the point of the malloc call, and that shows that it is mostly happening in c. @jrafanie's screen shot at least shows that he is getting the same callstack as well.

    What that means, to me at least, is that it is somehow how the strings and our environment is setup that is messing with the ruby internals to cause the leak. At least that is the conclusion that I am at currently

    Joe Rafaniello
    @jrafanie
    note rb_find_file_safe in the "vanilla rails"
    Nick LaMuro
    @NickLaMuro
    need to do more digging
    Joe Rafaniello
    @jrafanie
    blob
    that's vanilla rails :point_up: