[erlang-questions] BEAM performance?
Wed May 24 15:41:27 CEST 2017
My "worst" Mnesia write collision I could fix by making a single transaction out of two. That was just bad coding. We also occasionally encounter slow writes but I think that's due to what you described.
Unfortunately due to a restriction that is completely our fault we're not running in embedded mode. But I call ensure_loaded on all BEAM modules I can find in our build directory... (There seems to be no easy way to extract all beam modules in the system or to enter embedded mode during runtime?)
I will still investigate whether I can get it to run in embedded mode.
Gesendet: Mittwoch, 24. Mai 2017 um 15:19 Uhr
Von: "Jesper Louis Andersen" <jesper.louis.andersen@REDACTED>
An: "Oliver Korpilla" <Oliver.Korpilla@REDACTED>, erlang-questions@REDACTED
Betreff: Re: [erlang-questions] BEAM performance?
On Wed, May 24, 2017 at 3:02 PM Oliver Korpilla <Oliver.Korpilla@REDACTED[mailto:Oliver.Korpilla@REDACTED]> wrote:
* Are there mechanisms internal to BEAM impacting this? Or is it purely a property of the CPU architecture?
If you experience latencies in the millisecond range, I don't think you are looking at a CPU caching problem. A DRAM hit is 300ns or 0.3us. So you'd need about 3000 of those to hit 1ms run time. The napkin math doesn't really pan out too well.
Do you run the ERTS in embedded mode? I'd look at code loading. Or perhaps ASN.1 loading initially if it compiles stuff the first time around.
As for the two DB writes to the same row in short order: Mnesia uses an optimistic locking strategy. If two transactions write to the same row at the same time, both will aborted, wait a bit and try again. If you're unlucky, those two writes will keep interfering with each other and you will get lag. A good way around this is a design which serializes such writes. Or perhaps you can make the write dirty (this can actually be safe in some situations, depending on your setup).
More information about the erlang-questions