I will certainly investigate. FYI that 512KB limit is only for the read block cache, not the write buffer, or other transient memory usage by leveldb.

Ping

And of course even for the read block cache it is always possible to have either more blocks in active use than fit in the cache, or have blocks that are just bigger than the cache size (if large values are stored they aren't split up into multiple blocks, blocks are just made bigger).

ojan@ still haven't looked into this yet, but am getting closer to getting to this as my task.

Three observations to report here.

1) All of these databases open a leveldb with a leveldb::Options instance created by leveldb_proto::CreateSimpleOptions(). The options values used for these db's are:

	comparator = BytewiseComparator()
	create_if_missing = true
	error_if_exists = false
	paranoid_checks = false
	env = Env::Default()
	info_log = NULL
	write_buffer_size = 4<<20
	max_open_files = 0
	block_cache = leveldb_chrome::GetSharedBrowserBlockCache()
	block_size = 4096
	block_restart_interval = 16
	max_file_size = 2<<20
	compression = kSnappyCompression
	reuse_logs = true
	filter_policy = NULL

So the maximum quiescent (i.e. no background compaction) memory use should be somewhere around:

	  write buffer: 4 MB
	+ block cache : 1 MB (shared amongst all db's)
	--------------------
	  Total       : 5 MB

The block cache is shared, so in this example (with 7 db's open) it should really be:

	4 + (1 / 7) = 4.14 MB.

As mek@ mentioned in #c5 the size can be still larger for many other reasons (in-flight iterators, etc.).

The write buffer size should be lowered, but it's probably not best to have a single size for all users. The smaller the size the more frequent the background compactions.

2) The block cache attribution is not yet in Chrome's memory-infra. That CL (https://crrev.com/c/667916) is still in flight. So instead of 4.14 MB we're seeing 5 MB.

3) I find it suspicious that every single database has the *exact* same size (1,332.2 KiB). It's possible they have all just been opened without having been written to yet, but still worth looking into.

I will test further after https://crrev.com/c/667916 lands.

One (new) UMA metric to look at is LevelDB.SharedCache.BytesUsed.Unified. About 55% of Android devices (when sampled) have an empty read cache. When not empty the distribution seems uniform up to a maximum of about 3.5 MiB.

Is there anything else we want to do here? Avoiding the 3.5MB case on low-end would be a nice to have, if we're able to control this.

ericrk@ Sorry for the very long delay. The Android block size is currently set to 1MiB. I tested with instagram.com/badgalriri and with drive (in offline mode) and never saw a block cache above 1MiB. Not saying that there isn't some excessive use somewhere, but so far it doesn't appear to be related to the block cache. Can you still reproduce this with a current build?

This is out of date at this point, and probably not worth continued investment. Closing out.