[erlang-questions] Mnesia Reads and Writes

[Genti Bogu]

Hello everybody,

This is my first Erlang project and I was evaluating Mnesia's performance.

I wrote a simple erlang module for doing read and write tests to a disc_copies mnesia database.

So the data are stored in the disk but the database is loaded in memory.

 A write test consists of a number of records inserted per second in the Database, and a read test consists on a number of records that are read per second from the db. Each read or write operation is done inside a transaction. The read and write tests are performed separately.

Based on Mnesia's performance I define the appropriate load (number of reads/sec or number of writes/sec) that mnesia can handle.

Since transactional reads require only read locks (other reads can be done without requiring a lock), and transactional writes require write locks (exclusive access), I was expecting for mnesia to handle more load for read tests than for write tests. However, the supported load is the same in both the cases. Another observation of mine is the CPU usage, which is around 70% in the read tests (7 times higher than the write tests). Does anybody know why it can happen?

Since, I do the read tests separately from the write ones, and I have only one db node, I tried doing mnesia reads without using transactions at all. I got a read time that was more than 20 times faster than the time obtained when doing transactional reads. Why is it so huge the difference in performance in such a case? We have just read locks which allow simultaneous read requests to be performed in parallel without any exclusive lock.

How does the locking mechanism work for transactional reads and writes in Mnesia, and how are these operation handled?

I would be glad if somebody could help me understand some basic stuff about Mnesia IO operations.

Thanks,

Genti

[Jesper Louis Andersen]

On Jul 23, 2012, at 12:53 AM, Genti Bogu <gent...@yahoo.it> wrote:

> I would be glad if somebody could help me understand some basic stuff about Mnesia IO operations.
> Thanks,

Mnesia is in general optimistic about locking. So upon a possible conflict it will retry the transaction. I cannot explain why your read-load is 7 times higher, but I would advise that simple one-record reads are done in
a dirty fashion.

Note that a dirty read is still atomic for the record, but it runs outside the lock manager and is thus much faster. You only need a read transaction when you want a consistent view over multiple queries, and I've found that the places where this is needed is far in between and relatively few. At least for the main usage of mnesia, which is to provide very fast point-query in-memory lookup of a table which is kept in sync over multiple machines.

Essentially any other kind of desired storage property is better served with another system specifically built to store data of large size such that a considerable part of the data must be kept off-line on disk.

Be sure you are evaluating mnesia's performance for a scenario it was built to handle :) Otherwise you will just be sorry later on if your data cannot fit into main memory.

Jesper Louis Andersen
Erlang Solutions Ltd., Copenhagen

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Håkan Mattsson]

On Fri, Oct 19, 2012 at 1:26 PM, Jesper Louis Andersen
<jesper.lou...@erlang-solutions.com> wrote:
> On Jul 23, 2012, at 12:53 AM, Genti Bogu <gent...@yahoo.it> wrote:
>
>> I would be glad if somebody could help me understand some basic stuff
>> about Mnesia IO operations.
>> Thanks,
>
> Mnesia is in general optimistic about locking. So upon a possible
> conflict it will retry the transaction. I cannot explain why your
> read-load is 7 times higher, but I would advise that simple
> one-record reads are done in a dirty fashion.

Do not confuse this with optimistic locking. Mnesia uses
*pessimistic* locking combined with deadlock prevention. Newly
started transactions are restarted in favour to older ones in
case of potential deadlocks.

> Note that a dirty read is still atomic for the record, but it
> runs outside the lock manager and is thus much faster.

Dirty access is (of course) faster than access within
transactions. But 7 times seems to be an extreme case.
Transactional access does however involve communication with the
centralized lock manager (one lock manager per node). This may
cause a severe performance penalty on multi core systems. Perhaps
it can explain performance difference in your test. Remote dirty
access do suffer of a similar performance penalty as it also
involves communication with a centralized process (one on the
remote node).

/Håkan