Hi Sam, I think they are likely referring to the memory_ets Riak statistic. This is just a straight export of erlang:memory(ets). [1], [2]
You're probably right that they're using LevelDB, given the data (and presumably key) volumes they're talking about. However, LevelDB's various types of caching are done inside the C++ library itself (and vastly improved in Basho's fork), so this is not the ETS caching you are looking for. :o) Outside of the memory backend itself, ETS is used in many places inside Riak (and its dependencies). I thought at first it might be a metadata cache within the KV VNode itself [3], but it seems that's not used by default and is expected to be small (per-VNode) if enabled at all. If you pull down the Riak source [4] and 'rebar get-deps', you can 'grep -r ets:delete deps/*' for an idea of how many places data is being dropped from ETS tables. :o) Many places ETS is used to provide fast key-value lookup in memory (a common Erlang idiom), rather than as a large cache. An example of this is the routing table in webmachine. [5] Without combing through these uses (and/or doing some tracing on a system under load), I can't say which part of Riak exactly is eating up and then dropping a lot of ETS data on a regular basis - perhaps a developer can chime in? - but I hope this goes some way to answering your questions. Cian [1] http://www.erlang.org/doc/man/erlang.html#memory-0 [2] http://git.io/vLZQq [3] http://git.io/vLZ5j (cf. surrounding functions) [4] http://docs.basho.com/riak/latest/ops/building/installing/from-source/ [5] http://git.io/vLZAS _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
