[erlang-questions] mnesia lookup weirdness
Thu Jul 14 11:41:41 CEST 2011
On 14 July 2011 10:36, Sverker Eriksson <sverker@REDACTED> wrote:
> I have to confess...
> ets:first is not supposed to behave like that, returning already deleted
> even if the table is fixated. You can of course have a race with a deleting
> but the key should have existed in the table some time during the execution
> of ets:first().
> I think you suffer from this bug, fixed in R13B01:
> OTP-8040 Various fixes in ETS: ets:first could return a deleted key in
> a fixated table. ets:lookup could return objects out of order
> if a deleted object was re-inserted into a fixed bag.
> ets:delete_object could fail to delete duplicate objects in a
> The irony being that you probably wouldn't had found the bug of
> the leaking ets:safe_fixtable now if ets:first had behaved like it should.
> Leaking ets:safe_fixtable can be a nasty thing as it might result in
> gradual performance degradation,
> both memory and cpu wise. Deleted objects are not deallocated and the table
> is not allowed
> to adjust its size (rehash) until it is "unfixated".
Yes, you are right about this. The reason I stumbled upon this was because
the erlang node was gradually eating up all available memory and crashing. I
could find no obvious culprit, until I came across this!
> For the record, I've found out what was causing this.
> A process was regularly executing ets:safe_fixtable(true) on this table,
> not finishing off with ets:safe_fixtable(false).
> This meant that the behaviour of mnesia:dirty_first was affected, and was
> also causing increased memory consumption.
> Thanks to Håkan and Sverker for helping me find the root cause.
> On 1 July 2011 14:44, Chandru <chandrashekhar.mullaparthi@REDACTED>
>> One of my production nodes running R12B-5 is exhibiting some strange
>> mnesia:dirty_read(gtp_tid, mnesia:dirty_first(gtp_tid)).
>> gives me an empty list. The table has 39K entries. How do I find out what
>> is happening? I tried using ets operations directly and get the same
>> (which is what mnesia is doing behind the scenes anyway). I get the same
>> empty result using a transaction to read. Any clues?
>> 96> ets:info(gtp_tid).
>> The same operation works ok on other tables.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions