* No longer expose WT_SESSION into Erlang at all as WT's model is to
maintain one WT_SESSION per-thread and we don't know anything about
threads in Erlang.
* async_nif worker threads don't pull both mutexes on every loop
when processing requests, only one
* async_nif provides a worker_id (int, 0 - MAX_WORKERS) within the
work block scope which we use to find our per-worker WT_SESSIONs
* async_nif maintained a number of globals which I'm moving into
the NIF's priv_data so that on upgrade/reload we have a fighting
chance to "Do the Right Thing(TM)".
* NIF Upgrades/Reloads started to plumb this in.
* Use a khash to manage the cache of URI->WT_CURSORs per WT_SESSION.
* Added start/stop positions into truncate call to allow for truncating
sub-ranges data.
* Lots of other details I'm sure I've forgotten and more left undone.
Search for "TODO:" or try to compile to see what's left, and then
there is a need for a lot more tests given all this new complexity.
to avoid a) opening a large number of Sessions or Cursors and b) avoid
reusing a Session/Cursor pair in more than one thread. Each operation,
except folds, use the Session/Cursor pair corresponding to the scheduler
id (roughly "core") they are running on. Each vnode instance will have
(count(schedulers) + count(active folds)) Session/Cursor pairs in use so
be sure to set session_max large enough when opening the connection to
WiredTiger. This method will cause problems with scheduler threads going
to "sleep" so be sure to run schedmon to wake them up.
reasonable setting for the WiredTiger cache size at runtime. This cache
is shared across all vnodes regarless of how many are active at any
given time. The algorithm is: max(1GB, 1/3 (RAM - Beam RSS size)). We don't
enable direct_io on purpose and data will be double buffered in WiredTiger's
cache and the filesystem buffer cache. This turns out to be faster than
direct I/O despite wasting a bit of RAM.
answer is 'no'). So far there has been no effort to validate that these
settings are in fact the best for Riak/KV or CS data access patterns. These
particular settings are, at best, an educated guess based on past experience,
the docs and reading about the benchmark the WiredTiger team published here:
https://github.com/wiredtiger/wiredtiger/wiki/YCSB-Mapkeeper-benchmark
