1. 29 5月, 2015 3 次提交
    • A
      Support saving history in memtable_list · c8153510
      agiardullo 提交于
      Summary:
      For transactions, we are using the memtables to validate that there are no write conflicts.  But after flushing, we don't have any memtables, and transactions could fail to commit.  So we want to someone keep around some extra history to use for conflict checking.  In addition, we want to provide a way to increase the size of this history if too many transactions fail to commit.
      
      After chatting with people, it seems like everyone prefers just using Memtables to store this history (instead of a separate history structure).  It seems like the best place for this is abstracted inside the memtable_list.  I decide to create a separate list in MemtableListVersion as using the same list complicated the flush/installalflushresults logic too much.
      
      This diff adds a new parameter to control how much memtable history to keep around after flushing.  However, it sounds like people aren't too fond of adding new parameters.  So I am making the default size of flushed+not-flushed memtables be set to max_write_buffers.  This should not change the maximum amount of memory used, but make it more likely we're using closer the the limit.  (We are now postponing deleting flushed memtables until the max_write_buffer limit is reached).  So while we might use more memory on average, we are still obeying the limit set (and you could argue it's better to go ahead and use up memory now instead of waiting for a write stall to happen to test this limit).
      
      However, if people are opposed to this default behavior, we can easily set it to 0 and require this parameter be set in order to use transactions.
      
      Test Plan: Added a xfunc test to play around with setting different values of this parameter in all tests.  Added testing in memtablelist_test and planning on adding more testing here.
      
      Reviewers: sdong, rven, igor
      
      Reviewed By: igor
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D37443
      c8153510
    • Y
      Rename EventLoggerHelpers EventHelpers · ec4ff4e9
      Yueh-Hsuan Chiang 提交于
      Summary:
      Rename EventLoggerHelpers EventHelpers, as it's going to include
      all event-related helper functions instead of EventLogger only stuffs.
      
      Test Plan: make
      
      Reviewers: sdong, rven, anthony
      
      Reviewed By: anthony
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D39093
      ec4ff4e9
    • Y
      [API Change] Move listeners from ColumnFamilyOptions to DBOptions · 672dda9b
      Yueh-Hsuan Chiang 提交于
      Summary: Move listeners from ColumnFamilyOptions to DBOptions
      
      Test Plan:
      listener_test
      compact_files_test
      
      Reviewers: rven, anthony, sdong
      
      Reviewed By: sdong
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D39087
      672dda9b
  2. 27 5月, 2015 4 次提交
  3. 23 5月, 2015 12 次提交
  4. 22 5月, 2015 6 次提交
  5. 21 5月, 2015 1 次提交
  6. 20 5月, 2015 7 次提交
  7. 19 5月, 2015 6 次提交
    • I
      Add an option wal_bytes_per_sync to control sync_file_range for WAL files · 4a855c07
      Igor Canadi 提交于
      Summary:
      sync_file_range is not always asyncronous and thus can block writes if we do this for WAL in the foreground thread. See more here: http://yoshinorimatsunobu.blogspot.com/2014/03/how-syncfilerange-really-works.html
      
      Some users don't want us to call sync_file_range on WALs. Some other do.
      Thus, I'm adding a separate option wal_bytes_per_sync to control calling
      sync_file_range on WAL files. bytes_per_sync will apply only to table
      files now.
      
      Test Plan: no more sync_file_range for WAL as evidenced by strace
      
      Reviewers: yhchiang, rven, sdong
      
      Reviewed By: sdong
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D38253
      4a855c07
    • I
      Allow flushes to run in parallel with manual compaction · b0fdda4f
      Igor Canadi 提交于
      Summary: As title. I spent some time thinking about it and I don't think there should be any issue with running manual compaction and flushes in parallel
      
      Test Plan: make check works
      
      Reviewers: rven, yhchiang, sdong
      
      Reviewed By: yhchiang, sdong
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D38355
      b0fdda4f
    • Y
      Fixed compile errors due to some gcc does not have std::map::emplace · 74f3832d
      Yueh-Hsuan Chiang 提交于
      Summary:
      Fixed the following compile errors due to some gcc does not have std::map::emplace
      
      util/thread_status_impl.cc: In static member function ‘static std::map<std::basic_string<char>, long unsigned int> rocksdb::ThreadStatus::InterpretOperationProperties(rocksdb::ThreadStatus::OperationType, const uint64_t*)’:
      util/thread_status_impl.cc:88:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
      util/thread_status_impl.cc:90:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
      util/thread_status_impl.cc:94:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
      util/thread_status_impl.cc:96:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
      util/thread_status_impl.cc:98:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
      util/thread_status_impl.cc:101:20: error: ‘class std::map<std::basic_string<char>, long unsigned int>’ has no member named ‘emplace’
      make: *** [util/thread_status_impl.o] Error 1
      
      Test Plan: make db_bench
      
      Reviewers: igor
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D38643
      74f3832d
    • S
      Remove duplicated code · 0c8017db
      stash93 提交于
      Summary: Call Flush() function instead
      
      Test Plan: make all check
      
      Reviewers: igor
      
      Reviewed By: igor
      
      Subscribers: dhruba
      
      Differential Revision: https://reviews.facebook.net/D38583
      0c8017db
    • S
      DBTest.DynamicLevelMaxBytesCompactRange: make sure L0 is not empty before running compact range · fb5bdbf9
      sdong 提交于
      Summary: DBTest.DynamicLevelMaxBytesCompactRange needs to make sure L0 is not empty to properly cover the code paths we want to cover. However, current codes have a bug that might leave the condition not held. Improve the test to ensure it.
      
      Test Plan: Run the test in an environment that is used to fail. Also run it many times.
      
      Subscribers: leveldb, dhruba
      
      Differential Revision: https://reviews.facebook.net/D38631
      fb5bdbf9
    • S
      CompactRange skips levels 1 to base_level -1 for dynamic level base size · 6fa70851
      sdong 提交于
      Summary: CompactRange() now is much more expensive for dynamic level base size as it goes through all the levels. Skip those not used levels between level 0 an base level.
      
      Test Plan: Run all unit tests
      
      Reviewers: yhchiang, rven, anthony, kradhakrishnan, igor
      
      Reviewed By: igor
      
      Subscribers: leveldb, dhruba
      
      Differential Revision: https://reviews.facebook.net/D37125
      6fa70851
  8. 16 5月, 2015 1 次提交
    • Y
      Allow GetThreadList to report Flush properties. · 3f0867c0
      Yueh-Hsuan Chiang 提交于
      Summary:
      Allow GetThreadList to report Flush properties, which includes:
      * job id
      * number of bytes that has been written since flush started.
      * total size of input mem-tables
      
      Test Plan:
      ./db_bench --threads=30 --num=1000000 --benchmarks=fillrandom --thread_status_per_interval=100 --value_size=1000
      
      Sample output from db_bench which tracks same flush job
      
                ThreadID ThreadType       cfName            Operation   ElapsedTime                                         Stage        State OperationProperties
         140213879898240   High Pri      default                Flush       5789 us                    FlushJob::WriteLevel0Table              BytesMemtables 4112835 | BytesWritten 577104 | JobID 8 |
      
                ThreadID ThreadType       cfName            Operation   ElapsedTime                                         Stage        State OperationProperties
         140213879898240   High Pri      default                Flush     30.634 ms                    FlushJob::WriteLevel0Table              BytesMemtables 4112835 | BytesWritten 1734865 | JobID 8 |
      
      Reviewers: rven, igor, sdong
      
      Reviewed By: sdong
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D38505
      3f0867c0