Erlang / Erlang Advanced Interview questions
How do you troubleshoot slow ETS lookups on a heavily-used table?
A "fast" O(1) ETS set/bag lookup can still degrade under real load for a handful
of specific, diagnosable reasons rather than randomly — the first step is confirming which of these
actually applies before reaching for a fix.
ets:info(Tab, memory), %% table size, in words ets:info(Tab, size), %% row count ets:info(Tab, [read_concurrency, write_concurrency]).
- Lock contention — many concurrent writers without
write_concurrencyenabled serialize on the same lock; checkets:info/2for the current setting and enable it if writes are frequent and concurrent. - Oversized keys/values copied on every read — a lookup still copies the matched row into the caller; storing large blobs directly as values means every read pays that copy cost, so storing a reference (e.g. a binary handle) instead can help.
- Using ets:match/2 where ets:select/2 with a compiled match spec would filter more efficiently.
- An
ordered_setused where a plainsetwould do — ordered tables cost more per operation (tree-based) than hash-based ones when strict ordering isn't actually needed.
More Related questions...