1. 03 6月, 2015 2 次提交
  2. 02 6月, 2015 5 次提交
    • M
      more times in perf_context and iostats_context · ec7a9443
      Mike Kolupaev 提交于
      Summary:
      We occasionally get write stalls (>1s Write() calls) on HDD under read load. The following timers explain almost all of the stalls:
       - perf_context.db_mutex_lock_nanos
       - perf_context.db_condition_wait_nanos
       - iostats_context.open_time
       - iostats_context.allocate_time
       - iostats_context.write_time
       - iostats_context.range_sync_time
       - iostats_context.logger_time
      
      In my experiments each of these occasionally takes >1s on write path under some workload. There are rare cases when Write() takes long but none of these takes long.
      
      Test Plan: Added code to our application to write the listed timings to log for slow writes. They usually add up to almost exactly the time Write() call took.
      
      Reviewers: rven, yhchiang, sdong
      
      Reviewed By: sdong
      
      Subscribers: march, dhruba, tnovak
      
      Differential Revision: https://reviews.facebook.net/D39177
      ec7a9443
    • S
      Allow users to migrate to options.level_compaction_dynamic_level_bytes=true using CompactRange() · 4266d4fd
      sdong 提交于
      Summary: In DB::CompactRange(), change parameter "reduce_level" to "change_level". Users can compact all data to the last level if needed. By doing it, users can migrate the DB to options.level_compaction_dynamic_level_bytes=true.
      
      Test Plan: Add a unit test for it.
      
      Reviewers: yhchiang, anthony, kradhakrishnan, igor, rven
      
      Reviewed By: rven
      
      Subscribers: leveldb, dhruba
      
      Differential Revision: https://reviews.facebook.net/D39099
      4266d4fd
    • Y
      Removed DBImpl::notifying_events_ · d333820b
      Yueh-Hsuan Chiang 提交于
      Summary:
      DBImpl::notifying_events_ is a internal counter in DBImpl which is
      used to prevent DB close when DB is notifying events.  However, as
      the current events all rely on either compaction or flush which
      already have similar counters to prevent DB close, it is safe to
      remove notifying_events_.
      
      Test Plan:
      listener_test
      examples/compact_files_example
      
      Reviewers: igor, anthony, kradhakrishnan, rven, sdong
      
      Reviewed By: sdong
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D39315
      d333820b
    • Y
      Fixed compile warning in compact_files_example.cc · 495ce601
      Yueh-Hsuan Chiang 提交于
      Summary: Fixed compile warning in compact_files_example.cc
      
      Test Plan: compact_files_example
      
      Reviewers: sdong, igor
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D39309
      495ce601
    • M
      add rocksdb::WritableFileWrapper similar to rocksdb::EnvWrapper · 2ecac9f9
      Mike Kolupaev 提交于
      Summary: It used to be no good (known to me) non-intrusive way to wrap WritableFile - you can't call protected virtual methods of the wrapped pointer to WritableFile. This diff adds a convenience class WritableFileWrapper that makes wrapping WritableFile both possible and easy.
      
      Test Plan: `make clean; make -j release`, `make clean; OPT=-DROCKSDB_LITE make release`, `make clean; USE_CLANG=1 make -j all`.
      
      Reviewers: sdong, yhchiang, rven
      
      Reviewed By: rven
      
      Subscribers: dhruba, tnovak, march
      
      Differential Revision: https://reviews.facebook.net/D39147
      2ecac9f9
  3. 01 6月, 2015 1 次提交
  4. 31 5月, 2015 2 次提交
  5. 30 5月, 2015 7 次提交
  6. 29 5月, 2015 4 次提交
    • R
      WriteBatch.Merge w/ SliceParts support · a0635ba3
      Reed Allman 提交于
      also hooked up WriteBatchInternal
      a0635ba3
    • 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
  7. 27 5月, 2015 4 次提交
  8. 23 5月, 2015 12 次提交
  9. 22 5月, 2015 3 次提交
    • Y
      Allow EventLogger to directly log from a JSONWriter. · 7fee8775
      Yueh-Hsuan Chiang 提交于
      Summary:
      Allow EventLogger to directly log from a JSONWriter.  This allows
      the JSONWriter to be shared by EventLogger and potentially EventListener,
      which is an important step to integrate EventLogger and EventListener.
      
      This patch also rewrites EventLoggerHelpers::LogTableFileCreation(),
      which uses the new API to generate identical log.
      
      Test Plan:
      Run db_bench in debug mode and make sure the log is correct and no
      assertions fail.
      
      Reviewers: sdong, anthony, igor
      
      Reviewed By: igor
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D38709
      7fee8775
    • I
      Don't artificially inflate L0 score · 7a357751
      Igor Canadi 提交于
      Summary:
      This turns out to be pretty bad because if we prioritize L0->L1 then L1 can grow artificially large, which makes L0->L1 more and more expensive. For example:
      256MB @ L0 + 256MB @ L1 --> 512MB @ L1
      256MB @ L0 + 512MB @ L1 --> 768MB @ L1
      256MB @ L0 + 768MB @ L1 --> 1GB @ L1
      
      ....
      
      256MB @ L0 + 10GB @ L1 --> 10.2GB @ L1
      
      At some point we need to start compacting L1->L2 to speed up L0->L1.
      
      Test Plan:
      The performance improvement is massive for heavy write workload. This is the benchmark I ran: https://phabricator.fb.com/P19842671. Before this change, the benchmark took 47 minutes to complete. After, the benchmark finished in 2minutes. You can see full results here: https://phabricator.fb.com/P19842674
      
      Also, we ran this diff on MongoDB on RocksDB on one replicaset. Before the change, our initial sync was so slow that it couldn't keep up with primary writes. After the change, the import finished without any issues
      
      Reviewers: dynamike, MarkCallaghan, rven, yhchiang, sdong
      
      Reviewed By: sdong
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D38637
      7a357751
    • I
      Set stats_dump_period_sec to 600 by default · 4cb4d546
      Igor Canadi 提交于
      Summary: Having stats in our LOG more often will help a lot with perf debugging.
      
      Test Plan: none
      
      Reviewers: sdong, MarkCallaghan
      
      Reviewed By: MarkCallaghan
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D38781
      4cb4d546