By default LevelDB will only mmap() up to 1000 ldb files for reading, this default is arbitrarily small.
Once the first 1000 files are mmap()ed, it falls back to using file descriptor based IO which eventually causes problems for handling new sockets due to the use of select(). Increasing the number of mmaps() used will hold off running into the 1024 file descriptor (default) limit for select().
By default LevelDB will only mmap() up to 1000 ldb files for reading, this default is arbitrarily small.
Once the first 1000 files are mmap()ed, it falls back to using file descriptor based IO which eventually
causes problems for handling new sockets due to the use of select(). Increasing the number of mmaps() used
will hold off running into the 1024 file descriptor (default) limit for select().
You’ll also want to send this PR to our upstream leveldb repo. Then it can be merged here next time we update the subtree. The tests will fail here because a subtree is being edited.
You might also be interested in reviewing #13741.
As far as I can tell, the limit was added to leveldb in the first place due to a largely misguided effort to avoid VM exhaustion on 32-bit hosts. Now, we don’t use mmap on 32-bit at all– the only reason I see to not eliminate the limit entirely is because there is a OS map limit, and the software wouldn’t handle hitting it gracefully. 4096 is more than enough to cover our current needs and still tiny compared to the OS limits on Linux.
Not upping this limit is almost certainly bad for performance, and it’s also causing us to run out of FDs due to additional FD use (which was made worse by other recent PRs that changed the FD limits under the false assumption that leveldb wouldn’t actually use that many FDs– false due to running into the map limit). We should fix the FD constraints by switching to poll, but even with that fixed we’re still left with worse performance due to hitting the map limit.
I ACKed this in the upstream repo.
