hardedcoded number of shards in ShardedLRUCache can cause file descriptor exhaustion

[GoogleCodeExporter]

If the minimum of 20 is used for options.max_open_files, each shard of the 
table cache will only have one entry. This can lead to a quick exhaustion of 
file descriptors when there are two L0 tables and many iterators opened at 
once. Each iterator effectively uses two file descriptors because the cache is 
constantly turning over.

I'm going to work around this problem in chrome by increasing max_open_files 
but it seems like accommodating 20 in this case wouldn't require much change to 
cache.cc.

There are more details in this comment:
https://code.google.com/p/chromium/issues/detail?id=227313#c11

I haven't yet looked into why the keys used by indexeddb end up in the same 
shard. It might just be the same key for every iterator.

Original issue reported on code.google.com by dgrogan@chromium.org on 22 Apr 2013 at 11:44

[GoogleCodeExporter]

Original comment by dgrogan@chromium.org on 22 Apr 2013 at 11:46

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

The floor of max_open_files was changed to 74 in leveldb 1.11.0. LevelDB 
reserves 10 files for non-sst purposes, leaving 64 for ssts.

Original comment by dgrogan@chromium.org on 13 Jun 2013 at 11:29

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****