<div dir="ltr"><div>Hello,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 25, 2020 at 9:26 AM Pablo Polvorin <<a href="mailto:pablo.polvorin@nextroll.com">pablo.polvorin@nextroll.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
we recently migrated our systems from OTP21 to OTP22. On one of them, performance noticeable degraded when switched to OTP22 (20% drop).<br>
After some investigation, we found the apparent cause was the madvice() call when returning the carriers to the carrier pool, that lead to lots of<br>
minor page faults, ultimately killing our performance. We run in a virtualised cloud, not sure how much that affects the minor page fault overhead.<br></blockquote><div><br></div><div>Do you know if you have access to MADV_FREE or use MADV_DONTNEED?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So we spend some time tweaking the allocator' settings (that haven't been touched in many years, with the system itself evolved a lot since that time) and got<br>
to a good improvement. But for carrier migration ultimately the thing that worked best for us was just disable it entirely. Is this a terrible idea?<br>
our load is a fairly stable flow of homogenous requests, that lead to several short-lived (milliseconds) processes being spawned. Have plenty of memory, so I'm not too worried about a badly utilised carrier being stuck within a scheduler.<br>
<br>
Got a few questions regarding this:<br>
<br>
* Wonder, it's something common out there to disable carrier migration? Feels a bit strange that nobody hit the same problem when updating to OTP22, I’m<br>
assuming there are lots of not-so-great allocator settings out there, like was our case. (disabling it was our last try actually, we tried the settings suggested by<br>
erts_alloc_config, and then make the +M<S>acul and +M<S>acfml settings significantly stricter as well, and while that helps, still had too many page faults).<br>
<br></blockquote><div><br></div><div>Carrier migration can help a lot to deal with memory fragmentation issues. It is however not free as you have noticed. I know that other people have disabled it with some success, but as far as I remember that was to work around bugs in the migration logic, not because of the performance overhead.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* What's the tradeoff on having large multiblock carriers, other than the memory overhead when they aren't fully used?.<br>
<br>
* Do it make sense to make a config flag to allow carrier migration but disable the madvice() on free blocks?<br></blockquote><div><br></div><div>Given your experiences with it, I think that would make sense. We did not notice any degradation when testing madvise ourselves, but it is not possible to test all scenarios in all environments.</div><div><br></div><div>Lukas</div></div></div>