<div dir="ltr">That is how bag tables in ets are implemented, which is why index is slow if your secondary keys are equal,<div>the same thing applies to ordinary bag-tables, if many primary keys are identical.</div><div><br>
</div><div>/Dan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 15, 2014 at 6:57 AM, Karolis Petrauskas <span dir="ltr"><<a href="mailto:k.petrauskas@gmail.com" target="_blank">k.petrauskas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Recently this problem reappeared: my mnesia DB started to load very<br>
slowly. The main problem was single disc_copies table with ~500k small<br>
records. This time it was loading for 35 minutes. This table is of<br>
type "bag" and has one secondary index.<br>
<br>
Based on previous emails, I assumed that the problems are caused by<br>
the index. I dropped the index, altrough observed no notable<br>
improvement (in startup time). Then I changed table to<br>
disc_only_copies. The DB started to load fast (<1min) event with<br>
secondary index (I have recreated it).<br>
<br>
Another strange thing here is that the mnesia:foldl/3 for this table<br>
was very slow. I was just copying several fields from this table to<br>
another table. I have aborted this operation after waiting for several<br>
hours. The foldl operation completed in ~2 minutes after i changed the<br>
source table type from disc_copies to disc_only_copies.<br>
<br>
Currently I think the problem is related to uniqueness of the key in<br>
the table. For some time the application worked so, that each key had<br>
not more than 100 records per key (the table is of type "bag").<br>
Recently the application started to generate more records (1k or event<br>
10k) per key.<br>
<br>
Is it normal/expected behaviour of Mnesia, or should I try to create<br>
scripts for reproducing this problem and report it as a bug?<br>
<br>
The application is running on Erlang R16B02 on Debian OS.<br>
<span class="HOEnZb"><font color="#888888"><br>
Karolis<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Sun, Jul 14, 2013 at 10:59 PM, Karolis Petrauskas<br>
<<a href="mailto:k.petrauskas@gmail.com">k.petrauskas@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
>     Thanks for your response. I have 1 secondary index in the entire<br>
> DB. I will try to load the DB with the index dropped.<br>
><br>
> Karolis<br>
><br>
> On Fri, Jul 12, 2013 at 10:12 AM, Ignas Vyšniauskas <<a href="mailto:baliulia@gmail.com">baliulia@gmail.com</a>> wrote:<br>
>> On 07/09/2013 07:16 PM, Karolis Petrauskas wrote:<br>
>>> After the DB become available, I stopped the node by invoking<br>
>>> init:stop(). Then I repeated the test. It is still running, but<br>
>>> timings look the same (2 cores were busy for 2.5 hours, and after<br>
>>> that 1 core is loaded fully, expected for ~5.5 hours). For the second<br>
>>> start up attempt the DB has no DCL files, only DCD are left after<br>
>>> first load.<br>
>><br>
>> A poke in the dark: do you maybe have lots of secondary indices? These<br>
>> will not be stored on disk and so will be recreated each time the tables<br>
>> are loaded, I've experienced very long mnesia startup times in such<br>
>> cases. Otherwise -- no idea.<br>
>><br>
>> --<br>
>> Ignas<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>