
<html>


<head>


<meta http-equiv="Content-Type" content="text/html; charset=utf-8">


</head>


<body>


<div>On fre, 2020-02-21 at 15:44 +0000, Vans S wrote:</div>


<blockquote type="cite">


<div class="yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;">


<div dir="ltr" data-setdir="false">Anyone have any ideas for improvements in mind to mach_object, perhaps maybe a way to have it provide 0 consistency? <br>


<br>


It seems to be a reoccurring problem, the code runs great locally with light load. As soon as you scale up, 64+ cores 50k+ sessions. All of the sudden your schedulers are capped out at 100% utilization, runqueues are maxing out, but the physical cpu usage is


 50%<.  <br>


<br>


This is because match_object waits for locks on the table and does not yield the scheduler.  As soon as the concurrent access increases to the table, the problem exponentially gets worse.  <br>


<br>


It kind of makes match_object unusable at scale, and something to be reserved for very specific use cases.<br>


<br>


Maybe theres a way to make it yield or return inconsistent results (if deletes going on, it could return a hole that itl discard for example)?</div>


</div>


</blockquote>


<div><br>


</div>


<div><br>


</div>


<div>ets:match_object does yield and return (potentially) inconsistent results.</div>


<div><br>


</div>


<div>But maybe it doesn't yield frequent enough.</div>


<div>Have you tried match_object/3 and limit number of returned objects per call?</div>


<div><br>


</div>


<div>/Sverker</div>


<div><br>


</div>


<div><br>


</div>


</body>


</html>