2019-09-16 17:31:27 +00:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
|
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
|
|
// (found in the LICENSE.Apache file in the root directory).
|
|
|
|
//
|
|
|
|
// Copyright (c) 2011 The LevelDB Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
// found in the LICENSE file. See the AUTHORS file for names of contributors.
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
#include <atomic>
|
|
|
|
#include <sstream>
|
|
|
|
#include <string>
|
2020-06-29 21:51:57 +00:00
|
|
|
|
2020-08-27 18:20:08 +00:00
|
|
|
#include "env/file_system_tracer.h"
|
2019-09-16 17:31:27 +00:00
|
|
|
#include "port/port.h"
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
#include "rocksdb/file_system.h"
|
2019-09-16 17:31:27 +00:00
|
|
|
#include "rocksdb/listener.h"
|
2020-06-29 21:51:57 +00:00
|
|
|
#include "rocksdb/options.h"
|
2019-09-16 17:31:27 +00:00
|
|
|
#include "rocksdb/rate_limiter.h"
|
|
|
|
#include "util/aligned_buffer.h"
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
namespace ROCKSDB_NAMESPACE {
|
2019-09-16 17:31:27 +00:00
|
|
|
class Statistics;
|
|
|
|
class HistogramImpl;
|
2021-01-26 06:07:26 +00:00
|
|
|
class SystemClock;
|
2019-09-16 17:31:27 +00:00
|
|
|
|
2020-04-24 22:30:12 +00:00
|
|
|
using AlignedBuf = std::unique_ptr<char[]>;
|
Support direct IO in RandomAccessFileReader::MultiRead (#6446)
Summary:
By supporting direct IO in RandomAccessFileReader::MultiRead, the benefits of parallel IO (IO uring) and direct IO can be combined.
In direct IO mode, read requests are aligned and merged together before being issued to RandomAccessFile::MultiRead, so blocks in the original requests might share the same underlying buffer, the shared buffers are returned in `aligned_bufs`, which is a new parameter of the `MultiRead` API.
For example, suppose alignment requirement for direct IO is 4KB, one request is (offset: 1KB, len: 1KB), another request is (offset: 3KB, len: 1KB), then since they all belong to page (offset: 0, len: 4KB), `MultiRead` only reads the page with direct IO into a buffer on heap, and returns 2 Slices referencing regions in that same buffer. See `random_access_file_reader_test.cc` for more examples.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6446
Test Plan: Added a new test `random_access_file_reader_test.cc`.
Reviewed By: anand1976
Differential Revision: D20097518
Pulled By: cheng-chang
fbshipit-source-id: ca48a8faf9c3af146465c102ef6b266a363e78d1
2020-03-20 23:15:40 +00:00
|
|
|
|
2020-07-23 20:48:17 +00:00
|
|
|
// Align the request r according to alignment and return the aligned result.
|
|
|
|
FSReadRequest Align(const FSReadRequest& r, size_t alignment);
|
|
|
|
|
|
|
|
// Try to merge src to dest if they have overlap.
|
|
|
|
//
|
|
|
|
// Each request represents an inclusive interval [offset, offset + len].
|
|
|
|
// If the intervals have overlap, update offset and len to represent the
|
|
|
|
// merged interval, and return true.
|
|
|
|
// Otherwise, do nothing and return false.
|
|
|
|
bool TryMerge(FSReadRequest* dest, const FSReadRequest& src);
|
|
|
|
|
2022-06-22 22:45:21 +00:00
|
|
|
// RandomAccessFileReader is a wrapper on top of FSRandomAccessFile. It is
|
2019-09-16 17:31:27 +00:00
|
|
|
// responsible for:
|
|
|
|
// - Handling Buffered and Direct reads appropriately.
|
|
|
|
// - Rate limiting compaction reads.
|
|
|
|
// - Notifying any interested listeners on the completion of a read.
|
|
|
|
// - Updating IO stats.
|
|
|
|
class RandomAccessFileReader {
|
|
|
|
private:
|
2020-07-22 15:53:21 +00:00
|
|
|
void NotifyOnFileReadFinish(
|
|
|
|
uint64_t offset, size_t length,
|
|
|
|
const FileOperationInfo::StartTimePoint& start_ts,
|
|
|
|
const FileOperationInfo::FinishTimePoint& finish_ts,
|
|
|
|
const Status& status) const {
|
2020-07-08 01:19:32 +00:00
|
|
|
FileOperationInfo info(FileOperationType::kRead, file_name_, start_ts,
|
2022-02-18 18:26:45 +00:00
|
|
|
finish_ts, status, file_temperature_);
|
2019-09-16 17:31:27 +00:00
|
|
|
info.offset = offset;
|
|
|
|
info.length = length;
|
|
|
|
|
|
|
|
for (auto& listener : listeners_) {
|
|
|
|
listener->OnFileReadFinish(info);
|
|
|
|
}
|
2021-11-19 01:09:54 +00:00
|
|
|
info.status.PermitUncheckedError();
|
2019-09-16 17:31:27 +00:00
|
|
|
}
|
2021-11-19 01:09:54 +00:00
|
|
|
|
|
|
|
void NotifyOnIOError(const IOStatus& io_status, FileOperationType operation,
|
|
|
|
const std::string& file_path, size_t length,
|
|
|
|
uint64_t offset) const {
|
|
|
|
if (listeners_.empty()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
IOErrorInfo io_error_info(io_status, operation, file_path, length, offset);
|
|
|
|
|
|
|
|
for (auto& listener : listeners_) {
|
|
|
|
listener->OnIOError(io_error_info);
|
|
|
|
}
|
|
|
|
io_status.PermitUncheckedError();
|
|
|
|
}
|
|
|
|
|
2019-09-16 17:31:27 +00:00
|
|
|
|
|
|
|
bool ShouldNotifyListeners() const { return !listeners_.empty(); }
|
|
|
|
|
2020-08-27 18:20:08 +00:00
|
|
|
FSRandomAccessFilePtr file_;
|
2019-09-16 17:31:27 +00:00
|
|
|
std::string file_name_;
|
2021-03-15 11:32:24 +00:00
|
|
|
SystemClock* clock_;
|
2019-09-16 17:31:27 +00:00
|
|
|
Statistics* stats_;
|
|
|
|
uint32_t hist_type_;
|
|
|
|
HistogramImpl* file_read_hist_;
|
|
|
|
RateLimiter* rate_limiter_;
|
|
|
|
std::vector<std::shared_ptr<EventListener>> listeners_;
|
2022-02-18 21:35:36 +00:00
|
|
|
const Temperature file_temperature_;
|
|
|
|
const bool is_last_level_;
|
2019-09-16 17:31:27 +00:00
|
|
|
|
2022-04-06 21:26:53 +00:00
|
|
|
struct ReadAsyncInfo {
|
2024-02-16 17:14:55 +00:00
|
|
|
ReadAsyncInfo(std::function<void(FSReadRequest&, void*)> cb, void* cb_arg,
|
|
|
|
uint64_t start_time)
|
2022-07-06 18:42:59 +00:00
|
|
|
: cb_(cb),
|
|
|
|
cb_arg_(cb_arg),
|
|
|
|
start_time_(start_time),
|
|
|
|
user_scratch_(nullptr),
|
|
|
|
user_aligned_buf_(nullptr),
|
|
|
|
user_offset_(0),
|
|
|
|
user_len_(0),
|
|
|
|
is_aligned_(false) {}
|
|
|
|
|
2024-02-16 17:14:55 +00:00
|
|
|
std::function<void(FSReadRequest&, void*)> cb_;
|
2022-07-06 18:42:59 +00:00
|
|
|
void* cb_arg_;
|
|
|
|
uint64_t start_time_;
|
2022-04-06 21:26:53 +00:00
|
|
|
FileOperationInfo::StartTimePoint fs_start_ts_;
|
2022-07-06 18:42:59 +00:00
|
|
|
// Below fields stores the parameters passed by caller in case of direct_io.
|
|
|
|
char* user_scratch_;
|
|
|
|
AlignedBuf* user_aligned_buf_;
|
|
|
|
uint64_t user_offset_;
|
|
|
|
size_t user_len_;
|
|
|
|
Slice user_result_;
|
|
|
|
// Used in case of direct_io
|
|
|
|
AlignedBuffer buf_;
|
|
|
|
bool is_aligned_;
|
2022-04-06 21:26:53 +00:00
|
|
|
};
|
|
|
|
|
2019-09-16 17:31:27 +00:00
|
|
|
public:
|
|
|
|
explicit RandomAccessFileReader(
|
Support direct IO in RandomAccessFileReader::MultiRead (#6446)
Summary:
By supporting direct IO in RandomAccessFileReader::MultiRead, the benefits of parallel IO (IO uring) and direct IO can be combined.
In direct IO mode, read requests are aligned and merged together before being issued to RandomAccessFile::MultiRead, so blocks in the original requests might share the same underlying buffer, the shared buffers are returned in `aligned_bufs`, which is a new parameter of the `MultiRead` API.
For example, suppose alignment requirement for direct IO is 4KB, one request is (offset: 1KB, len: 1KB), another request is (offset: 3KB, len: 1KB), then since they all belong to page (offset: 0, len: 4KB), `MultiRead` only reads the page with direct IO into a buffer on heap, and returns 2 Slices referencing regions in that same buffer. See `random_access_file_reader_test.cc` for more examples.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6446
Test Plan: Added a new test `random_access_file_reader_test.cc`.
Reviewed By: anand1976
Differential Revision: D20097518
Pulled By: cheng-chang
fbshipit-source-id: ca48a8faf9c3af146465c102ef6b266a363e78d1
2020-03-20 23:15:40 +00:00
|
|
|
std::unique_ptr<FSRandomAccessFile>&& raf, const std::string& _file_name,
|
2021-03-15 11:32:24 +00:00
|
|
|
SystemClock* clock = nullptr,
|
2021-01-26 06:07:26 +00:00
|
|
|
const std::shared_ptr<IOTracer>& io_tracer = nullptr,
|
2023-04-21 16:07:18 +00:00
|
|
|
Statistics* stats = nullptr,
|
|
|
|
uint32_t hist_type = Histograms::HISTOGRAM_ENUM_MAX,
|
2019-09-16 17:31:27 +00:00
|
|
|
HistogramImpl* file_read_hist = nullptr,
|
|
|
|
RateLimiter* rate_limiter = nullptr,
|
2021-10-07 21:57:02 +00:00
|
|
|
const std::vector<std::shared_ptr<EventListener>>& listeners = {},
|
2022-02-18 21:35:36 +00:00
|
|
|
Temperature file_temperature = Temperature::kUnknown,
|
|
|
|
bool is_last_level = false)
|
2021-01-25 22:35:45 +00:00
|
|
|
: file_(std::move(raf), io_tracer, _file_name),
|
2019-09-16 17:31:27 +00:00
|
|
|
file_name_(std::move(_file_name)),
|
2021-01-26 06:07:26 +00:00
|
|
|
clock_(clock),
|
2019-09-16 17:31:27 +00:00
|
|
|
stats_(stats),
|
|
|
|
hist_type_(hist_type),
|
|
|
|
file_read_hist_(file_read_hist),
|
|
|
|
rate_limiter_(rate_limiter),
|
2021-10-07 21:57:02 +00:00
|
|
|
listeners_(),
|
2022-02-18 21:35:36 +00:00
|
|
|
file_temperature_(file_temperature),
|
|
|
|
is_last_level_(is_last_level) {
|
2019-09-16 17:31:27 +00:00
|
|
|
std::for_each(listeners.begin(), listeners.end(),
|
|
|
|
[this](const std::shared_ptr<EventListener>& e) {
|
|
|
|
if (e->ShouldBeNotifiedOnFileIO()) {
|
|
|
|
listeners_.emplace_back(e);
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2021-04-01 17:06:55 +00:00
|
|
|
static IOStatus Create(const std::shared_ptr<FileSystem>& fs,
|
|
|
|
const std::string& fname, const FileOptions& file_opts,
|
|
|
|
std::unique_ptr<RandomAccessFileReader>* reader,
|
|
|
|
IODebugContext* dbg);
|
2019-09-16 17:31:27 +00:00
|
|
|
RandomAccessFileReader(const RandomAccessFileReader&) = delete;
|
|
|
|
RandomAccessFileReader& operator=(const RandomAccessFileReader&) = delete;
|
|
|
|
|
2020-03-06 22:02:09 +00:00
|
|
|
// In non-direct IO mode,
|
|
|
|
// 1. if using mmap, result is stored in a buffer other than scratch;
|
|
|
|
// 2. if not using mmap, result is stored in the buffer starting from scratch.
|
|
|
|
//
|
Support direct IO in RandomAccessFileReader::MultiRead (#6446)
Summary:
By supporting direct IO in RandomAccessFileReader::MultiRead, the benefits of parallel IO (IO uring) and direct IO can be combined.
In direct IO mode, read requests are aligned and merged together before being issued to RandomAccessFile::MultiRead, so blocks in the original requests might share the same underlying buffer, the shared buffers are returned in `aligned_bufs`, which is a new parameter of the `MultiRead` API.
For example, suppose alignment requirement for direct IO is 4KB, one request is (offset: 1KB, len: 1KB), another request is (offset: 3KB, len: 1KB), then since they all belong to page (offset: 0, len: 4KB), `MultiRead` only reads the page with direct IO into a buffer on heap, and returns 2 Slices referencing regions in that same buffer. See `random_access_file_reader_test.cc` for more examples.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6446
Test Plan: Added a new test `random_access_file_reader_test.cc`.
Reviewed By: anand1976
Differential Revision: D20097518
Pulled By: cheng-chang
fbshipit-source-id: ca48a8faf9c3af146465c102ef6b266a363e78d1
2020-03-20 23:15:40 +00:00
|
|
|
// In direct IO mode, an aligned buffer is allocated internally.
|
|
|
|
// 1. If aligned_buf is null, then results are copied to the buffer
|
2020-03-06 22:02:09 +00:00
|
|
|
// starting from scratch;
|
Support direct IO in RandomAccessFileReader::MultiRead (#6446)
Summary:
By supporting direct IO in RandomAccessFileReader::MultiRead, the benefits of parallel IO (IO uring) and direct IO can be combined.
In direct IO mode, read requests are aligned and merged together before being issued to RandomAccessFile::MultiRead, so blocks in the original requests might share the same underlying buffer, the shared buffers are returned in `aligned_bufs`, which is a new parameter of the `MultiRead` API.
For example, suppose alignment requirement for direct IO is 4KB, one request is (offset: 1KB, len: 1KB), another request is (offset: 3KB, len: 1KB), then since they all belong to page (offset: 0, len: 4KB), `MultiRead` only reads the page with direct IO into a buffer on heap, and returns 2 Slices referencing regions in that same buffer. See `random_access_file_reader_test.cc` for more examples.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6446
Test Plan: Added a new test `random_access_file_reader_test.cc`.
Reviewed By: anand1976
Differential Revision: D20097518
Pulled By: cheng-chang
fbshipit-source-id: ca48a8faf9c3af146465c102ef6b266a363e78d1
2020-03-20 23:15:40 +00:00
|
|
|
// 2. Otherwise, scratch is not used and can be null, the aligned_buf owns
|
2020-03-06 22:02:09 +00:00
|
|
|
// the internally allocated buffer on return, and the result refers to a
|
Support direct IO in RandomAccessFileReader::MultiRead (#6446)
Summary:
By supporting direct IO in RandomAccessFileReader::MultiRead, the benefits of parallel IO (IO uring) and direct IO can be combined.
In direct IO mode, read requests are aligned and merged together before being issued to RandomAccessFile::MultiRead, so blocks in the original requests might share the same underlying buffer, the shared buffers are returned in `aligned_bufs`, which is a new parameter of the `MultiRead` API.
For example, suppose alignment requirement for direct IO is 4KB, one request is (offset: 1KB, len: 1KB), another request is (offset: 3KB, len: 1KB), then since they all belong to page (offset: 0, len: 4KB), `MultiRead` only reads the page with direct IO into a buffer on heap, and returns 2 Slices referencing regions in that same buffer. See `random_access_file_reader_test.cc` for more examples.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6446
Test Plan: Added a new test `random_access_file_reader_test.cc`.
Reviewed By: anand1976
Differential Revision: D20097518
Pulled By: cheng-chang
fbshipit-source-id: ca48a8faf9c3af146465c102ef6b266a363e78d1
2020-03-20 23:15:40 +00:00
|
|
|
// region in aligned_buf.
|
2021-04-01 17:06:55 +00:00
|
|
|
IOStatus Read(const IOOptions& opts, uint64_t offset, size_t n, Slice* result,
|
Group rocksdb.sst.read.micros stat by different user read IOActivity + misc (#11444)
Summary:
**Context/Summary:**
- Similar to https://github.com/facebook/rocksdb/pull/11288 but for user read such as `Get(), MultiGet(), DBIterator::XXX(), Verify(File)Checksum()`.
- For this, I refactored some user-facing `MultiGet` calls in `TransactionBase` and various types of `DB` so that it does not call a user-facing `Get()` but `GetImpl()` for passing the `ReadOptions::io_activity` check (see PR conversation)
- New user read stats breakdown are guarded by `kExceptDetailedTimers` since measurement shows they have 4-5% regression to the upstream/main.
- Misc
- More refactoring: with https://github.com/facebook/rocksdb/pull/11288, we complete passing `ReadOptions/IOOptions` to FS level. So we can now replace the previously [added](https://github.com/facebook/rocksdb/pull/9424) `rate_limiter_priority` parameter in `RandomAccessFileReader`'s `Read/MultiRead/Prefetch()` with `IOOptions::rate_limiter_priority`
- Also, `ReadAsync()` call time is measured in `SST_READ_MICRO` now
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11444
Test Plan:
- CI fake db crash/stress test
- Microbenchmarking
**Build** `make clean && ROCKSDB_NO_FBCODE=1 DEBUG_LEVEL=0 make -jN db_basic_bench`
- google benchmark version: https://github.com/google/benchmark/commit/604f6fd3f4b34a84ec4eb4db81d842fa4db829cd
- db_basic_bench_base: upstream
- db_basic_bench_pr: db_basic_bench_base + this PR
- asyncread_db_basic_bench_base: upstream + [db basic bench patch for IteratorNext](https://github.com/facebook/rocksdb/compare/main...hx235:rocksdb:micro_bench_async_read)
- asyncread_db_basic_bench_pr: asyncread_db_basic_bench_base + this PR
**Test**
Get
```
TEST_TMPDIR=/dev/shm ./db_basic_bench_{null_stat|base|pr} --benchmark_filter=DBGet/comp_style:0/max_data:134217728/per_key_size:256/enable_statistics:1/negative_query:0/enable_filter:0/mmap:1/threads:1 --benchmark_repetitions=1000
```
Result
```
Coming soon
```
AsyncRead
```
TEST_TMPDIR=/dev/shm ./asyncread_db_basic_bench_{base|pr} --benchmark_filter=IteratorNext/comp_style:0/max_data:134217728/per_key_size:256/enable_statistics:1/async_io:1/include_detailed_timers:0 --benchmark_repetitions=1000 > syncread_db_basic_bench_{base|pr}.out
```
Result
```
Base:
1956,1956,1968,1977,1979,1986,1988,1988,1988,1990,1991,1991,1993,1993,1993,1993,1994,1996,1997,1997,1997,1998,1999,2001,2001,2002,2004,2007,2007,2008,
PR (2.3% regression, due to measuring `SST_READ_MICRO` that wasn't measured before):
1993,2014,2016,2022,2024,2027,2027,2028,2028,2030,2031,2031,2032,2032,2038,2039,2042,2044,2044,2047,2047,2047,2048,2049,2050,2052,2052,2052,2053,2053,
```
Reviewed By: ajkr
Differential Revision: D45918925
Pulled By: hx235
fbshipit-source-id: 58a54560d9ebeb3a59b6d807639692614dad058a
2023-08-09 00:26:50 +00:00
|
|
|
char* scratch, AlignedBuf* aligned_buf) const;
|
Support direct IO in RandomAccessFileReader::MultiRead (#6446)
Summary:
By supporting direct IO in RandomAccessFileReader::MultiRead, the benefits of parallel IO (IO uring) and direct IO can be combined.
In direct IO mode, read requests are aligned and merged together before being issued to RandomAccessFile::MultiRead, so blocks in the original requests might share the same underlying buffer, the shared buffers are returned in `aligned_bufs`, which is a new parameter of the `MultiRead` API.
For example, suppose alignment requirement for direct IO is 4KB, one request is (offset: 1KB, len: 1KB), another request is (offset: 3KB, len: 1KB), then since they all belong to page (offset: 0, len: 4KB), `MultiRead` only reads the page with direct IO into a buffer on heap, and returns 2 Slices referencing regions in that same buffer. See `random_access_file_reader_test.cc` for more examples.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6446
Test Plan: Added a new test `random_access_file_reader_test.cc`.
Reviewed By: anand1976
Differential Revision: D20097518
Pulled By: cheng-chang
fbshipit-source-id: ca48a8faf9c3af146465c102ef6b266a363e78d1
2020-03-20 23:15:40 +00:00
|
|
|
|
|
|
|
// REQUIRES:
|
|
|
|
// num_reqs > 0, reqs do not overlap, and offsets in reqs are increasing.
|
|
|
|
// In non-direct IO mode, aligned_buf should be null;
|
|
|
|
// In direct IO mode, aligned_buf stores the aligned buffer allocated inside
|
|
|
|
// MultiRead, the result Slices in reqs refer to aligned_buf.
|
2021-04-01 17:06:55 +00:00
|
|
|
IOStatus MultiRead(const IOOptions& opts, FSReadRequest* reqs,
|
Group rocksdb.sst.read.micros stat by different user read IOActivity + misc (#11444)
Summary:
**Context/Summary:**
- Similar to https://github.com/facebook/rocksdb/pull/11288 but for user read such as `Get(), MultiGet(), DBIterator::XXX(), Verify(File)Checksum()`.
- For this, I refactored some user-facing `MultiGet` calls in `TransactionBase` and various types of `DB` so that it does not call a user-facing `Get()` but `GetImpl()` for passing the `ReadOptions::io_activity` check (see PR conversation)
- New user read stats breakdown are guarded by `kExceptDetailedTimers` since measurement shows they have 4-5% regression to the upstream/main.
- Misc
- More refactoring: with https://github.com/facebook/rocksdb/pull/11288, we complete passing `ReadOptions/IOOptions` to FS level. So we can now replace the previously [added](https://github.com/facebook/rocksdb/pull/9424) `rate_limiter_priority` parameter in `RandomAccessFileReader`'s `Read/MultiRead/Prefetch()` with `IOOptions::rate_limiter_priority`
- Also, `ReadAsync()` call time is measured in `SST_READ_MICRO` now
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11444
Test Plan:
- CI fake db crash/stress test
- Microbenchmarking
**Build** `make clean && ROCKSDB_NO_FBCODE=1 DEBUG_LEVEL=0 make -jN db_basic_bench`
- google benchmark version: https://github.com/google/benchmark/commit/604f6fd3f4b34a84ec4eb4db81d842fa4db829cd
- db_basic_bench_base: upstream
- db_basic_bench_pr: db_basic_bench_base + this PR
- asyncread_db_basic_bench_base: upstream + [db basic bench patch for IteratorNext](https://github.com/facebook/rocksdb/compare/main...hx235:rocksdb:micro_bench_async_read)
- asyncread_db_basic_bench_pr: asyncread_db_basic_bench_base + this PR
**Test**
Get
```
TEST_TMPDIR=/dev/shm ./db_basic_bench_{null_stat|base|pr} --benchmark_filter=DBGet/comp_style:0/max_data:134217728/per_key_size:256/enable_statistics:1/negative_query:0/enable_filter:0/mmap:1/threads:1 --benchmark_repetitions=1000
```
Result
```
Coming soon
```
AsyncRead
```
TEST_TMPDIR=/dev/shm ./asyncread_db_basic_bench_{base|pr} --benchmark_filter=IteratorNext/comp_style:0/max_data:134217728/per_key_size:256/enable_statistics:1/async_io:1/include_detailed_timers:0 --benchmark_repetitions=1000 > syncread_db_basic_bench_{base|pr}.out
```
Result
```
Base:
1956,1956,1968,1977,1979,1986,1988,1988,1988,1990,1991,1991,1993,1993,1993,1993,1994,1996,1997,1997,1997,1998,1999,2001,2001,2002,2004,2007,2007,2008,
PR (2.3% regression, due to measuring `SST_READ_MICRO` that wasn't measured before):
1993,2014,2016,2022,2024,2027,2027,2028,2028,2030,2031,2031,2032,2032,2038,2039,2042,2044,2044,2047,2047,2047,2048,2049,2050,2052,2052,2052,2053,2053,
```
Reviewed By: ajkr
Differential Revision: D45918925
Pulled By: hx235
fbshipit-source-id: 58a54560d9ebeb3a59b6d807639692614dad058a
2023-08-09 00:26:50 +00:00
|
|
|
size_t num_reqs, AlignedBuf* aligned_buf) const;
|
2019-09-16 17:31:27 +00:00
|
|
|
|
Group rocksdb.sst.read.micros stat by different user read IOActivity + misc (#11444)
Summary:
**Context/Summary:**
- Similar to https://github.com/facebook/rocksdb/pull/11288 but for user read such as `Get(), MultiGet(), DBIterator::XXX(), Verify(File)Checksum()`.
- For this, I refactored some user-facing `MultiGet` calls in `TransactionBase` and various types of `DB` so that it does not call a user-facing `Get()` but `GetImpl()` for passing the `ReadOptions::io_activity` check (see PR conversation)
- New user read stats breakdown are guarded by `kExceptDetailedTimers` since measurement shows they have 4-5% regression to the upstream/main.
- Misc
- More refactoring: with https://github.com/facebook/rocksdb/pull/11288, we complete passing `ReadOptions/IOOptions` to FS level. So we can now replace the previously [added](https://github.com/facebook/rocksdb/pull/9424) `rate_limiter_priority` parameter in `RandomAccessFileReader`'s `Read/MultiRead/Prefetch()` with `IOOptions::rate_limiter_priority`
- Also, `ReadAsync()` call time is measured in `SST_READ_MICRO` now
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11444
Test Plan:
- CI fake db crash/stress test
- Microbenchmarking
**Build** `make clean && ROCKSDB_NO_FBCODE=1 DEBUG_LEVEL=0 make -jN db_basic_bench`
- google benchmark version: https://github.com/google/benchmark/commit/604f6fd3f4b34a84ec4eb4db81d842fa4db829cd
- db_basic_bench_base: upstream
- db_basic_bench_pr: db_basic_bench_base + this PR
- asyncread_db_basic_bench_base: upstream + [db basic bench patch for IteratorNext](https://github.com/facebook/rocksdb/compare/main...hx235:rocksdb:micro_bench_async_read)
- asyncread_db_basic_bench_pr: asyncread_db_basic_bench_base + this PR
**Test**
Get
```
TEST_TMPDIR=/dev/shm ./db_basic_bench_{null_stat|base|pr} --benchmark_filter=DBGet/comp_style:0/max_data:134217728/per_key_size:256/enable_statistics:1/negative_query:0/enable_filter:0/mmap:1/threads:1 --benchmark_repetitions=1000
```
Result
```
Coming soon
```
AsyncRead
```
TEST_TMPDIR=/dev/shm ./asyncread_db_basic_bench_{base|pr} --benchmark_filter=IteratorNext/comp_style:0/max_data:134217728/per_key_size:256/enable_statistics:1/async_io:1/include_detailed_timers:0 --benchmark_repetitions=1000 > syncread_db_basic_bench_{base|pr}.out
```
Result
```
Base:
1956,1956,1968,1977,1979,1986,1988,1988,1988,1990,1991,1991,1993,1993,1993,1993,1994,1996,1997,1997,1997,1998,1999,2001,2001,2002,2004,2007,2007,2008,
PR (2.3% regression, due to measuring `SST_READ_MICRO` that wasn't measured before):
1993,2014,2016,2022,2024,2027,2027,2028,2028,2030,2031,2031,2032,2032,2038,2039,2042,2044,2044,2047,2047,2047,2048,2049,2050,2052,2052,2052,2053,2053,
```
Reviewed By: ajkr
Differential Revision: D45918925
Pulled By: hx235
fbshipit-source-id: 58a54560d9ebeb3a59b6d807639692614dad058a
2023-08-09 00:26:50 +00:00
|
|
|
IOStatus Prefetch(const IOOptions& opts, uint64_t offset, size_t n) const {
|
Set Read rate limiter priority dynamically and pass it to FS (#9996)
Summary:
### Context:
Background compactions and flush generate large reads and writes, and can be long running, especially for universal compaction. In some cases, this can impact foreground reads and writes by users.
### Solution
User, Flush, and Compaction reads share some code path. For this task, we update the rate_limiter_priority in ReadOptions for code paths (e.g. FindTable (mainly in BlockBasedTable::Open()) and various iterators), and eventually update the rate_limiter_priority in IOOptions for FSRandomAccessFile.
**This PR is for the Read path.** The **Read:** dynamic priority for different state are listed as follows:
| State | Normal | Delayed | Stalled |
| ----- | ------ | ------- | ------- |
| Flush (verification read in BuildTable()) | IO_USER | IO_USER | IO_USER |
| Compaction | IO_LOW | IO_USER | IO_USER |
| User | User provided | User provided | User provided |
We will respect the read_options that the user provided and will not set it.
The only sst read for Flush is the verification read in BuildTable(). It claims to be "regard as user read".
**Details**
1. Set read_options.rate_limiter_priority dynamically:
- User: Do not update the read_options. Use the read_options that the user provided.
- Compaction: Update read_options in CompactionJob::ProcessKeyValueCompaction().
- Flush: Update read_options in BuildTable().
2. Pass the rate limiter priority to FSRandomAccessFile functions:
- After calling the FindTable(), read_options is passed through GetTableReader(table_cache.cc), BlockBasedTableFactory::NewTableReader(block_based_table_factory.cc), and BlockBasedTable::Open(). The Open() needs some updates for the ReadOptions variable and the updates are also needed for the called functions, including PrefetchTail(), PrepareIOOptions(), ReadFooterFromFile(), ReadMetaIndexblock(), ReadPropertiesBlock(), PrefetchIndexAndFilterBlocks(), and ReadRangeDelBlock().
- In RandomAccessFileReader, the functions to be updated include Read(), MultiRead(), ReadAsync(), and Prefetch().
- Update the downstream functions of NewIndexIterator(), NewDataBlockIterator(), and BlockBasedTableIterator().
### Test Plans
Add unit tests.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9996
Reviewed By: anand1976
Differential Revision: D36452483
Pulled By: gitbw95
fbshipit-source-id: 60978204a4f849bb9261cb78d9bc1cb56d6008cf
2022-05-19 02:41:44 +00:00
|
|
|
return file_->Prefetch(offset, n, opts, nullptr);
|
2019-09-16 17:31:27 +00:00
|
|
|
}
|
|
|
|
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 22:47:08 +00:00
|
|
|
FSRandomAccessFile* file() { return file_.get(); }
|
2019-09-16 17:31:27 +00:00
|
|
|
|
2020-06-19 23:16:57 +00:00
|
|
|
const std::string& file_name() const { return file_name_; }
|
2019-09-16 17:31:27 +00:00
|
|
|
|
|
|
|
bool use_direct_io() const { return file_->use_direct_io(); }
|
2020-04-30 21:48:51 +00:00
|
|
|
|
2023-04-21 16:07:18 +00:00
|
|
|
IOStatus PrepareIOOptions(const ReadOptions& ro, IOOptions& opts) const;
|
2022-03-21 14:12:43 +00:00
|
|
|
|
|
|
|
IOStatus ReadAsync(FSReadRequest& req, const IOOptions& opts,
|
2024-02-16 17:14:55 +00:00
|
|
|
std::function<void(FSReadRequest&, void*)> cb,
|
2022-03-21 14:12:43 +00:00
|
|
|
void* cb_arg, void** io_handle, IOHandleDeleter* del_fn,
|
2022-07-06 18:42:59 +00:00
|
|
|
AlignedBuf* aligned_buf);
|
2022-04-06 21:26:53 +00:00
|
|
|
|
2024-02-16 17:14:55 +00:00
|
|
|
void ReadAsyncCallback(FSReadRequest& req, void* cb_arg);
|
2019-09-16 17:31:27 +00:00
|
|
|
};
|
2020-02-20 20:07:53 +00:00
|
|
|
} // namespace ROCKSDB_NAMESPACE
|