Hi Andrey,
Thanks for these explanations, really useful for me when I will migrate
to plocal...
Not sure to well understand these points (in bold) :
The size of a1in queue is*25%* of read cache size, size of a1out
is*50%* of cache size and size of am is* 75%* of cache size.
At the initial state the cache is empty, so all accessed pages are
put in a1in queue, and size of this queue is 100% of size of read cache.
But then, when there are no room for new pages in a1in, old pages
removed from a1in and put in a1out.
Eventually when a1out contains requested pages we need room for am queue
pages, so we once again remove a1in pages and put them in a1out queue,
*a1m* queue is truncated till it is reached 25% size of read cache.
Percentages and queue name "a1m" seems strange...
I'm looking forward to read your next article ;)
Sylvain
Le 20/12/2013 19:19, Andrey Lomakin a écrit :
Hi,
We have added description of design of storage disk cache. May it will
be interesting for you to look into OrientDB internals
https://github.com/orientechnologies/orientdb/wiki/plocal-storage-disk-cache
Next time we will provide description of WAL design and plocal cluster.
--
Best regards,
Andrey Lomakin.
Orient Technologies
the Company behind OrientDB
--
---
You received this message because you are subscribed to the Google
Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--
---
You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
