From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 06B3D2A9F0 for ; Tue, 25 Sep 2018 19:19:26 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgTba41vw0mG for ; Tue, 25 Sep 2018 19:19:25 -0400 (EDT) Received: from smtp59.i.mail.ru (smtp59.i.mail.ru [217.69.128.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id B7FB92A925 for ; Tue, 25 Sep 2018 19:19:25 -0400 (EDT) Received: by smtp59.i.mail.ru with esmtpa (envelope-from ) id 1g4wbz-0006ZR-RU for tarantool-patches@freelists.org; Wed, 26 Sep 2018 02:19:24 +0300 Date: Wed, 26 Sep 2018 02:19:22 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 00/11] vinyl: prepare for transaction throttling Message-ID: <20180925231922.GE3137@chai> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org * Vladimir Davydov [18/09/20 12:34]: > This patch set contains preparatory patches necessary for implementing > transaction throttling. It does some refactoring, introduces basic > throttling based on dump bandwidth, and splits the rate limit in soft > and hard, which is necessary for compaction based throttling. The only > thing left is invent such a throttling policy that guarantees that > compaction always keeps up with dumps. Re refactoring of vy_quota: I continue to believe that there is an underlying low-level quota object, encapsulating the logic of a limit and the current consumption rate. Before throttling, we had a single resource we consume: vinyl.memory, there was no logical limit on disk bandwidth. Throttling is essentially an introduction and enforcement of a logical limit on disk bandwidth. I disagree that with addition of this new logical limit the quota API should be changed. The current API is conceptually very simple. A quota is two variables: a limit and the current consumption rate. So there are two sets of methods: to change/adjust the limit, and to consume/release the use rate, in other words, use/release the associated resource. Introduction of a new resource type changes nothing about the way we work with the quota. We simply get a new pair of limit and use rate, and begin working with it in addition to the pair related to memory. So I believe that introduction of a new resource does not mandate the changes in the focus of quota-api from working with the internal state of the quota (limit and use rate) to essentially the life cycle of the LSM tree, i.e. handling of the events such as a dump or a compaction. We may have one set of events which lead to consumption and release of the quota today, and another tomorrow. Basically, the throttling task has two subtasks: - introduction of disk bandwidth as a separate resource which usage is accounted for across the code base This is this patch set's concern. This should have nothing to do with LSM details. The main consumer of the bandwidth is DML, since it essentially leads to level 0 dump. - introduction of a separate entity, which is then part of our LSM implementation which tracks events in LSM tree life cycle, such as compaction and dump, and dynamically adjusts the limit based on predicted implications of these events on the available disk bandwidth (or actually the remainder of it, since we assume that compaction's use of disk bandwidth is not limited with the quota). We still have no simple solution for the second part, "the predictor". It's therefore best, I agree, to separate the two stacks of patches, since we may want to change the predictive model in the future without changing the rate limiting logic itself > > https://github.com/tarantool/tarantool/issues/1862 > https://github.com/tarantool/tarantool/tree/dv/gh-1862-vy-throttling > > Vladimir Davydov (11): > vinyl: merge vy_quota_release and vy_quota_update_dump_bandwidth > vinyl: refactor quota use/unuse methods > vinyl: do not try to trigger dump if it is already in progress > vinyl: don't start quota timer until local recovery is complete > vinyl: add helper to start scheduler and enable quota on startup > vinyl: zap vy_env::memory, read_threads, and write_threads > vinyl: do not account zero dump bandwidth > vinyl: set quota timer period to 100 ms > vinyl: implement basic transaction throttling > vinyl: implement quota wait queue without fiber_cond > vinyl: split quota consumption rate limit into soft and hard > > src/box/vinyl.c | 79 +++++----- > src/box/vy_quota.c | 340 +++++++++++++++++++++++++++++++++---------- > src/box/vy_quota.h | 146 +++++++++++++++---- > src/box/vy_run.c | 12 +- > src/box/vy_run.h | 17 ++- > test/unit/vy_point_lookup.c | 2 +- > test/vinyl/suite.ini | 2 +- > test/vinyl/throttle.result | 102 +++++++++++++ > test/vinyl/throttle.test.lua | 54 +++++++ > 9 files changed, 601 insertions(+), 153 deletions(-) > create mode 100644 test/vinyl/throttle.result > create mode 100644 test/vinyl/throttle.test.lua > > -- > 2.11.0 > -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov