improving match_object for ets tables?

Vans S vans_163@REDACTED
Fri Feb 21 16:44:37 CET 2020


Anyone have any ideas for improvements in mind to mach_object, perhaps maybe a way to have it provide 0 consistency? 

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%<.  

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.  

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

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)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200221/5b412e70/attachment.htm>


More information about the erlang-questions mailing list