Skip to main content

Browse the archive

Revision 33323f21117e5bb8cf72569302f109aabb387bb9 authored by Mark Callaghan on 14 September 2012, 19:35:02 UTC, committed by Mark Callaghan on 14 September 2012, 23:43:50 UTC 
Remove use of mmap for random reads
 
Summary:
Reads via mmap on concurrent workloads are much slower than pread.
For example on a 24-core server with storage that can do 100k IOPS or more
I can get no more than 10k IOPS with mmap reads and 32+ threads.

Test Plan: db_bench benchmarks

Reviewers: dhruba, heyongqiang

Reviewed By: heyongqiang

Differential Revision: https://reviews.facebook.net/D5433
1 parent fa29f82
Raw File
TODO 
ss
- Stats

db
- Maybe implement DB::BulkDeleteForRange(start_key, end_key)
  that would blow away files whose ranges are entirely contained
  within [start_key..end_key]?  For Chrome, deletion of obsolete
  object stores, etc. can be done in the background anyway, so
  probably not that important.

After a range is completely deleted, what gets rid of the
corresponding files if we do no future changes to that range.  Make
the conditions for triggering compactions fire in more situations?
back to top