<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 16, 2016 at 3:38 PM, Danil Zagoskin <span dir="ltr"><<a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello!<div><br></div><div>We have a system which uses only 20—25% of available CPU. After that we see:</div><div>  * increased run_queue</div><div>  * increased scheduler active time (from erlang:statistics(<wbr>scheduler_wall_time))</div><div>  * decreased CPU usage</div><div><br></div><div>At first there were some problems visible with lcnt, but now (after fixes) there aren't.</div><div><br></div><div></div><div>While the system is in troubled state, msacc shows in cumulative scheduler stats:</div><div>  * 19.3% alloc</div><div>  * 19.3% gc</div><div>  * 25.3% ets</div><div>  * 12.3% emulator</div><div>  * 10.0% bif</div><div>  * (other times are quite low)</div><div><br></div><div>The system is 2x 10-core Xeon E5-2660 (with hyperthreading), so we have 40 schedulers there.</div><div>We use OTP 19.0 with +MBas aoffcaobf +MBacul 0</div><div><br></div><div>Switching scheduler binding from unbound (no option) to default (thread_no_node_processor_<wbr>spread according to documentation) sligtly increases the throughput, but the alloc/gc/ets times are still very high.</div><div><br></div><div>How do we inspect high alloc/gc scheduler times?</div></div></blockquote><div><br></div><div>For garbage collection I would maybe look at using tracing to see if you can figure out which process it is that is doing all the garbage collections. Also from msacc you should be able to figure out if most of the time is spent doing major or minor gc.</div><div><br></div><div>The alloc is harder to figure out. I would recommend using perf to dig deeper and see if any C functions stick out and try to understand what they do. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Is there a way to select the most suitable allocation strategies without bruteforcing every option on every allocator type?</div></div></blockquote><div><br></div><div>There is a tool called erts_alloc_config that may be useful to you. It was designed to solve this type of problem, although I don't think it has been updated in a long time so it may be outdated with what has happened with the allocated the last releases.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Maybe we are missing something? Any advice?</div><span class="HOEnZb"><font color="#888888"><div><div><br></div></div></font></span></div></blockquote></div><br></div><div class="gmail_extra">msacc is a new tool that we've not used that much yet. Every time I've used it I've had to add a bunch of new states and kind of bisect my way down into the code to figure out what it is that is taking all the time. As I've mentioned in the other mail, linxu perf is also a good help here to figure out what is taking time.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Lukas</div></div>