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 D2A952DB02 for ; Fri, 31 May 2019 06:11:21 -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 N3jMNqCOWlrK for ; Fri, 31 May 2019 06:11:21 -0400 (EDT) Received: from smtp37.i.mail.ru (smtp37.i.mail.ru [94.100.177.97]) (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 007382DAF1 for ; Fri, 31 May 2019 06:11:20 -0400 (EDT) Received: by smtp37.i.mail.ru with esmtpa (envelope-from ) id 1hWeVK-0008TD-Os for tarantool-patches@freelists.org; Fri, 31 May 2019 13:11:19 +0300 Date: Fri, 31 May 2019 13:11:17 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH] vinyl: don't throttle DDL Message-ID: <20190531101117.GA10100@atlas> References: <6a44ac6225255600cdc0ab8c082c04c9e98f89f8.1559296816.git.vdavydov.dev@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6a44ac6225255600cdc0ab8c082c04c9e98f89f8.1559296816.git.vdavydov.dev@gmail.com> 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 [19/05/31 13:01]: > Since DDL is triggered by the admin, it can be deliberately initiated > when the workload is known to be low. Throttling it along with DML > requests would only cause exasperation in this case. So we don't apply > disk-based rate limit to DDL. This should be fine, because the > disk-based limit is set rather strictly to let the workload some space > to grow, see vy_regulator_update_rate_limit(), and in contrast to the > memory-based limit, exceeding the disk-based limit doesn't result in > abrupt stalls - it may only lead to a gradual accumulation of disk space > usage and read latency. > > Closes #4238 Nice that you provisioned for this in advance. LGTM. -- Konstantin Osipov, Moscow, Russia