CBD-771: Stats archiver uses ETS to replace Mnesia

Stats are stored in memory resident ETS tables and are dumped to
backup files periodically. Cascade and truncate happen in memory
now. Stats backup files are saved in data/<node>/stats directory
which is parallel to data/<node>/mnesia.

Using ETS to replace mnesia certainly saves CPU usage. On idle
2-node cluster with 3~5 buckets, I see the CPU% drops at least
10%.

Based on work of Liang Guo.

Change-Id: If57932e0caae6e28e9b57b6317ba87e0b870b422
Reviewed-on: http://review.couchbase.org/22545
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-5307 run_on_subset doesn't crash when there are no stats.

If there are no stats samples we'll default to running on a subset
which seems safe and not too disturbing.

Change-Id: Ie3f5cc58b42b73d05d5d963164a3c2bb5445be9f
Reviewed-on: http://review.couchbase.org/24210
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-5307 Fix typo in ns_node_disco.

Change-Id: I77861d0eb48845f0d6c1f6a90e1b4cb8349865c9
Reviewed-on: http://review.couchbase.org/24253
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-5307 Don't log useless message about changed config.

During rebalance we change 'buckets' key a lot which results in lots
of these messages in the log file. At the same time, they are
completely useless.

Change-Id: I478ec80f0e89042792ef554698107bacd6a5275f
Reviewed-on: http://review.couchbase.org/24258
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-5307 Log less when deciding if compaction is needed.

Basically all we need to log is data and disk sizes. Everything else
about resulting decision can be easily inferred from this data.

Change-Id: I60cf6cdc1f9b4b293abd8c9f7c1f95e22a7fd0a7
Reviewed-on: http://review.couchbase.org/24279
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
MB-7671 Check fragmentation before compacting vbucket.

When we decide to compact or not to compact a bucket we just take a
random sample of vbuckets and check aggregated fragmentation of these
vbuckets. Although not very likely, it's possible that we'll decide to
compact entire bucket when only few vbuckets have high
fragmentation. To avoid an overhead of compacting vbuckets that don't
really need thie, now we check fragmentation of every single vbucket
before compacting it.

Change-Id: Iaa719c45800caf46c726cd06eb8afb2113b47887
[alk@tut.by: added jira ticket]
Signed-off-by: Aliaksey Kandratsenka <alk@tut.by>
Reviewed-on: http://review.couchbase.org/24280
Tested-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Reviewed-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>