https://i.minus.com/iwmmJsMV3BQnU.pngYou have the memory available. This is likely LevelDB using caches and write buffers to speed things up. Some may want Bitcoin to minimize it's RAM usage, while others may want Bitcoin to run as fast and low latency as possible, so there is no right answer; the default LevelDB memory parameter options are used.
dbcache is set to 25 mb by default, so this can't be the cause.
Where?
Write buffer=max 4mb (per file), 129 sst files currently...
src\src\leveldb\include\leveldb\options.h ->
// Amount of data to build up in memory (backed by an unsorted log
// on disk) before converting to a sorted on-disk file.
//
// Larger values increase performance, especially during bulk loads.
// Up to two write buffers may be held in memory at the same time,
// so you may wish to adjust this parameter to control memory usage.
// Also, a larger write buffer will result in a longer recovery time
// the next time the database is opened.
//
// Default: 4MB
size_t write_buffer_size;
// Number of open files that can be used by the DB. You may need to
// increase this if your database has a large working set (budget
// one open file per 2MB of working set).
//
// Default: 1000
int max_open_files;
a quote
There are other sources of memory usage:
8MB - the default cache
4MB - write buffer (though should only build up if you do 4MB worth of writing)
very large - Unix buffer cache usage for opened files (they are mmapped). If you want to trim this, try tweaking MmapLimiter in leveldb/util/env_posix.cc so it initializes the "allowed mmaps" to 0 instead of 1000. Though this is mostly an accounting issue. The files will be sitting in the buffer cache regardless I think.
I think Bitcoin instantly became one of the largest data sets of LevelDB, with 10GB x a
lot of users.
