From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 19 Sep 2018 04:53:19 +0300 From: Konstantin Osipov Subject: Re: [PATCH v2 6/8] vinyl: keep track of compaction queue length Message-ID: <20180919015319.GL31150@chai> References: <53e58f3f5d87bc19f4690143720aa779fcd22ab5.1537115208.git.vdavydov.dev@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53e58f3f5d87bc19f4690143720aa779fcd22ab5.1537115208.git.vdavydov.dev@gmail.com> To: Vladimir Davydov Cc: tarantool-patches@freelists.org List-ID: * Vladimir Davydov [18/09/17 15:05]: > Currently, there's no way to figure out whether compaction keeps up > with dumps or not while this is essential for implementing transaction > throttling. This patch adds a metric that is supposed to help answer > this question. This is the compaction queue size. It is calculated per > range and per LSM tree as the total size of slices awaiting compaction. > We update the metric along with the compaction priority of a range, in > vy_range_update_compact_priority(), and account it to an LSM tree in > vy_lsm_acct_range(). For now, the new metric is reported only on per > index basis, in index.stat() under disk.compact.queue. OK to push. Accounting pages, rows and bytes seems to be a bit of overkill for now. All we need to throttle is dump bandwidth, which is in bytes. I assume you have plans for rows and pages. > -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov