82b81dc8b5
Summary: `GenericRateLimiter` slow path handles requests that cannot be satisfied immediately. Such requests enter a queue, and their thread stays in `Request()` until they are granted or the rate limiter is stopped. These threads are responsible for unblocking themselves. The work to do so is split into two main duties. (1) Waiting for the next refill time. (2) Refilling the bytes and granting requests. Prior to this PR, the slow path logic involved a leader election algorithm to pick one thread to perform (1) followed by (2). It elected the thread whose request was at the front of the highest priority non-empty queue since that request was most likely to be granted. This algorithm was efficient in terms of reducing intermediate wakeups, which is a thread waking up only to resume waiting after finding its request is not granted. However, the conceptual complexity of this algorithm was too high. It took me a long time to draw a timeline to understand how it works for just one edge case yet there were so many. This PR drops the leader election to reduce conceptual complexity. Now, the two duties can be performed by whichever thread acquires the lock first. The risk of this change is increasing the number of intermediate wakeups, however, we took steps to mitigate that. - `wait_until_refill_pending_` flag ensures only one thread performs (1). This\ prevents the thundering herd problem at the next refill time. The remaining\ threads wait on their condition variable with an unbounded duration -- thus we\ must remember to notify them to ensure forward progress. - (1) is typically done by a thread at the front of a queue. This is trivial\ when the queues are initially empty as the first choice that arrives must be\ the only entry in its queue. When queues are initially non-empty, we achieve\ this by having (2) notify a thread at the front of a queue (preferring higher\ priority) to perform the next duty. - We do not require any additional wakeup for (2). Typically it will just be\ done by the thread that finished (1). Combined, the second and third bullet points above suggest the refill/granting will typically be done by a request at the front of its queue. This is important because one wakeup is saved when a granted request happens to be in an already running thread. Note there are a few cases that still lead to intermediate wakeup, however. The first two are existing issues that also apply to the old algorithm, however, the third (including both subpoints) is new. - No request may be granted (only possible when rate limit dynamically\ decreases). - Requests from a different queue may be granted. - (2) may be run by a non-front request thread causing it to not be granted even\ if some requests in that same queue are granted. It can happen for a couple\ (unlikely) reasons. - A new request may sneak in and grab the lock at the refill time, before the\ thread finishing (1) can wake up and grab it. - A new request may sneak in and grab the lock and execute (1) before (2)'s\ chosen candidate can wake up and grab the lock. Then that non-front request\ thread performing (1) can carry over to perform (2). Pull Request resolved: https://github.com/facebook/rocksdb/pull/8602 Test Plan: - Use existing tests. The edge cases listed in the comment are all performance\ related; I could not really think of any related to correctness. The logic\ looks the same whether a thread wakes up/finishes its work early/on-time/late,\ or whether the thread is chosen vs. "steals" the work. - Verified write throughput and CPU overhead are basically the same with and\ without this change, even in a rate limiter heavy workload: Test command: ``` $ rm -rf /dev/shm/dbbench/ && TEST_TMPDIR=/dev/shm /usr/bin/time ./db_bench -benchmarks=fillrandom -num_multi_db=64 -num_low_pri_threads=64 -num_high_pri_threads=64 -write_buffer_size=262144 -target_file_size_base=262144 -max_bytes_for_level_base=1048576 -rate_limiter_bytes_per_sec=16777216 -key_size=24 -value_size=1000 -num=10000 -compression_type=none -rate_limiter_refill_period_us=1000 ``` Results before this PR: ``` fillrandom : 108.463 micros/op 9219 ops/sec; 9.0 MB/s 7.40user 8.84system 1:26.20elapsed 18%CPU (0avgtext+0avgdata 256140maxresident)k ``` Results after this PR: ``` fillrandom : 108.108 micros/op 9250 ops/sec; 9.0 MB/s 7.45user 8.23system 1:26.68elapsed 18%CPU (0avgtext+0avgdata 255688maxresident)k ``` Reviewed By: hx235 Differential Revision: D30048013 Pulled By: ajkr fbshipit-source-id: 6741bba9d9dfbccab359806d725105817fef818b
115 lines
3.4 KiB
C++
115 lines
3.4 KiB
C++
// 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 <algorithm>
|
|
#include <atomic>
|
|
#include <chrono>
|
|
#include <deque>
|
|
|
|
#include "port/port.h"
|
|
#include "rocksdb/env.h"
|
|
#include "rocksdb/rate_limiter.h"
|
|
#include "rocksdb/system_clock.h"
|
|
#include "util/mutexlock.h"
|
|
#include "util/random.h"
|
|
|
|
namespace ROCKSDB_NAMESPACE {
|
|
|
|
class GenericRateLimiter : public RateLimiter {
|
|
public:
|
|
GenericRateLimiter(int64_t refill_bytes, int64_t refill_period_us,
|
|
int32_t fairness, RateLimiter::Mode mode,
|
|
const std::shared_ptr<SystemClock>& clock,
|
|
bool auto_tuned);
|
|
|
|
virtual ~GenericRateLimiter();
|
|
|
|
// This API allows user to dynamically change rate limiter's bytes per second.
|
|
virtual void SetBytesPerSecond(int64_t bytes_per_second) override;
|
|
|
|
// Request for token to write bytes. If this request can not be satisfied,
|
|
// the call is blocked. Caller is responsible to make sure
|
|
// bytes <= GetSingleBurstBytes()
|
|
using RateLimiter::Request;
|
|
virtual void Request(const int64_t bytes, const Env::IOPriority pri,
|
|
Statistics* stats) override;
|
|
|
|
virtual int64_t GetSingleBurstBytes() const override {
|
|
return refill_bytes_per_period_.load(std::memory_order_relaxed);
|
|
}
|
|
|
|
virtual int64_t GetTotalBytesThrough(
|
|
const Env::IOPriority pri = Env::IO_TOTAL) const override {
|
|
MutexLock g(&request_mutex_);
|
|
if (pri == Env::IO_TOTAL) {
|
|
return total_bytes_through_[Env::IO_LOW] +
|
|
total_bytes_through_[Env::IO_HIGH];
|
|
}
|
|
return total_bytes_through_[pri];
|
|
}
|
|
|
|
virtual int64_t GetTotalRequests(
|
|
const Env::IOPriority pri = Env::IO_TOTAL) const override {
|
|
MutexLock g(&request_mutex_);
|
|
if (pri == Env::IO_TOTAL) {
|
|
return total_requests_[Env::IO_LOW] + total_requests_[Env::IO_HIGH];
|
|
}
|
|
return total_requests_[pri];
|
|
}
|
|
|
|
virtual int64_t GetBytesPerSecond() const override {
|
|
return rate_bytes_per_sec_;
|
|
}
|
|
|
|
private:
|
|
void RefillBytesAndGrantRequests();
|
|
int64_t CalculateRefillBytesPerPeriod(int64_t rate_bytes_per_sec);
|
|
Status Tune();
|
|
|
|
uint64_t NowMicrosMonotonic() { return clock_->NowNanos() / std::milli::den; }
|
|
|
|
// This mutex guard all internal states
|
|
mutable port::Mutex request_mutex_;
|
|
|
|
const int64_t kMinRefillBytesPerPeriod = 100;
|
|
|
|
const int64_t refill_period_us_;
|
|
|
|
int64_t rate_bytes_per_sec_;
|
|
// This variable can be changed dynamically.
|
|
std::atomic<int64_t> refill_bytes_per_period_;
|
|
std::shared_ptr<SystemClock> clock_;
|
|
|
|
bool stop_;
|
|
port::CondVar exit_cv_;
|
|
int32_t requests_to_wait_;
|
|
|
|
int64_t total_requests_[Env::IO_TOTAL];
|
|
int64_t total_bytes_through_[Env::IO_TOTAL];
|
|
int64_t available_bytes_;
|
|
int64_t next_refill_us_;
|
|
|
|
int32_t fairness_;
|
|
Random rnd_;
|
|
|
|
struct Req;
|
|
std::deque<Req*> queue_[Env::IO_TOTAL];
|
|
bool wait_until_refill_pending_;
|
|
|
|
bool auto_tuned_;
|
|
int64_t num_drains_;
|
|
int64_t prev_num_drains_;
|
|
const int64_t max_bytes_per_sec_;
|
|
std::chrono::microseconds tuned_time_;
|
|
};
|
|
|
|
} // namespace ROCKSDB_NAMESPACE
|