From: Vladimir Davydov <vdavydov.dev@gmail.com>
To: kostja@tarantool.org
Cc: tarantool-patches@freelists.org
Subject: [PATCH 16/18] vinyl: confine quota watermark within sane value range
Date: Thu, 16 Aug 2018 19:12:10 +0300 [thread overview]
Message-ID: <473f93f9e1df4f1a6ddbfe5319a80ac3088ab37b.1534432819.git.vdavydov.dev@gmail.com> (raw)
In-Reply-To: <cover.1534432819.git.vdavydov.dev@gmail.com>
In-Reply-To: <cover.1534432819.git.vdavydov.dev@gmail.com>
Make sure the watermark is within 50 .. 90% of the memory limit.
See the comment in the code for the rationale.
---
src/box/vy_quota.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 53 insertions(+), 8 deletions(-)
diff --git a/src/box/vy_quota.c b/src/box/vy_quota.c
index c22a8519..43fc645a 100644
--- a/src/box/vy_quota.c
+++ b/src/box/vy_quota.c
@@ -69,6 +69,51 @@ static const size_t VY_DEFAULT_DUMP_BANDWIDTH = 10 * 1024 * 1024;
enum { VY_DUMP_BANDWIDTH_PCT = 10 };
/**
+ * Min and max values of watermark, in percentage of limit.
+ *
+ * We set the watermark so that we can dump all memory below it
+ * before we hit the hard limit:
+ *
+ * limit - watermark watermark
+ * ----------------- = --------------
+ * use_rate dump_bandwidth
+ *
+ * This is done that way, because due to the log structured
+ * nature of the allocator we cannot free memory in arbitrary
+ * chunks, only in whole generations, and we bump the generation
+ * counter only when a dump is triggered. We could probably
+ * maintain more than two generations (active and the one being
+ * dumped), but that would make memory lookups more expensive
+ * (as we would have to maintain more than two in-memory trees
+ * for each index) and would also resulted in producing smaller
+ * run files, thus intensifying compaction.
+ *
+ * With such a memory dumping algorithm, setting the watermark to
+ * a value less than 50% doesn't make much sense. For instance,
+ * suppose the quota consumption rate is 3 times greater than the
+ * dump bandwidth. Then according to the formula we are supposed
+ * to set the watermark to 25%. If we did that, then by the time
+ * memory dump is complete we would have 75% of memory used up
+ * and hence would have to throttle the quota consumption rate
+ * down to one third of the dump bandwidth to avoid long stalls
+ * due to exhausted quota. Never setting watermark below 50%
+ * will give us a consistent RPS equal to the dump bandwidth.
+ *
+ * Setting the watermark to very high values (say 99%) is also
+ * not good, because in case the quota consumption rate suddenly
+ * raises we will have to throttle it to avoid stalls, and the
+ * higher the watermark the more repressive throttling we will
+ * have to exert until memory dump is complete. Limiting the max
+ * watermark to 90% can result in throttling to 1/10th of the
+ * dump bandwidth at worst, which is harsh, but tolerable (think
+ * of 1/100th for 99% watermark).
+ */
+enum {
+ VY_QUOTA_WATERMARK_MIN = 50,
+ VY_QUOTA_WATERMARK_MAX = 90,
+};
+
+/**
* Wake up the next fiber in the line waiting for quota
* provided quota is available.
*/
@@ -115,18 +160,18 @@ vy_quota_timer_cb(ev_loop *loop, ev_timer *timer, int events)
q->use_curr = 0;
/*
- * Due to log structured nature of the lsregion allocator,
- * which is used for allocating statements, we cannot free
- * memory in chunks, only all at once. Therefore we should
- * configure the watermark so that by the time we hit the
- * limit, all memory have been dumped, i.e.
+ * Update the quota watermark and trigger memory dump
+ * if the watermark is exceeded.
*
- * limit - watermark watermark
- * ----------------- = --------------
- * use_rate dump_bandwidth
+ * See the comment to VY_QUOTA_WATERMARK_MIN/MAX for
+ * more details about the formula.
*/
q->watermark = ((double)q->limit * q->dump_bw /
(q->dump_bw + q->use_rate + 1));
+ q->watermark = MAX(q->limit * VY_QUOTA_WATERMARK_MIN / 100,
+ q->watermark);
+ q->watermark = MIN(q->limit * VY_QUOTA_WATERMARK_MAX / 100,
+ q->watermark);
vy_quota_check_watermark(q);
}
--
2.11.0
next prev parent reply other threads:[~2018-08-16 16:12 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-16 16:11 [PATCH 00/18] Implement write throttling for vinyl Vladimir Davydov
2018-08-16 16:11 ` [PATCH 01/18] vinyl: rework internal quota API Vladimir Davydov
2018-08-20 11:07 ` Konstantin Osipov
2018-08-24 8:32 ` Vladimir Davydov
2018-08-27 18:29 ` Vladimir Davydov
2018-08-16 16:11 ` [PATCH 02/18] vinyl: move quota methods implementation to vy_quota.c Vladimir Davydov
2018-08-20 11:07 ` Konstantin Osipov
2018-08-27 18:30 ` Vladimir Davydov
2018-08-16 16:11 ` [PATCH 03/18] vinyl: move quota related methods and variables from vy_env to vy_quota Vladimir Davydov
2018-08-20 11:08 ` Konstantin Osipov
2018-08-27 18:33 ` Vladimir Davydov
2018-08-16 16:11 ` [PATCH 04/18] vinyl: implement vy_quota_wait using vy_quota_try_use Vladimir Davydov
2018-08-20 11:09 ` Konstantin Osipov
2018-08-27 18:36 ` Vladimir Davydov
2018-08-16 16:11 ` [PATCH 05/18] vinyl: wake up fibers waiting for quota one by one Vladimir Davydov
2018-08-20 11:11 ` Konstantin Osipov
2018-08-24 8:33 ` Vladimir Davydov
2018-08-28 13:19 ` Vladimir Davydov
2018-08-28 14:04 ` Konstantin Osipov
2018-08-28 14:39 ` Vladimir Davydov
2018-08-16 16:12 ` [PATCH 06/18] vinyl: do not wake up fibers waiting for quota if quota is unavailable Vladimir Davydov
2018-08-20 11:13 ` Konstantin Osipov
2018-08-16 16:12 ` [PATCH 07/18] vinyl: tune dump bandwidth histogram buckets Vladimir Davydov
2018-08-20 11:15 ` Konstantin Osipov
2018-08-28 15:37 ` Vladimir Davydov
2018-08-16 16:12 ` [PATCH 08/18] vinyl: rename vy_quota::dump_bw to dump_bw_hist Vladimir Davydov
2018-08-20 11:15 ` Konstantin Osipov
2018-08-28 16:04 ` Vladimir Davydov
2018-08-16 16:12 ` [PATCH 09/18] vinyl: cache dump bandwidth for timer invocation Vladimir Davydov
2018-08-20 11:21 ` Konstantin Osipov
2018-08-28 16:10 ` Vladimir Davydov
2018-08-16 16:12 ` [PATCH 10/18] vinyl: do not add initial guess to dump bandwidth histogram Vladimir Davydov
2018-08-20 11:23 ` Konstantin Osipov
2018-08-23 20:15 ` Konstantin Osipov
2018-08-28 16:15 ` Vladimir Davydov
2018-08-16 16:12 ` [PATCH 11/18] vinyl: use snap_io_rate_limit for initial dump bandwidth estimate Vladimir Davydov
2018-08-20 11:24 ` Konstantin Osipov
2018-08-24 8:31 ` Vladimir Davydov
2018-08-28 16:18 ` Vladimir Davydov
2018-08-16 16:12 ` [PATCH 12/18] histogram: add function for computing lower bound percentile estimate Vladimir Davydov
2018-08-20 11:29 ` [tarantool-patches] " Konstantin Osipov
2018-08-24 8:30 ` Vladimir Davydov
2018-08-28 16:39 ` Vladimir Davydov
2018-08-16 16:12 ` [PATCH 13/18] vinyl: use lower bound percentile estimate for dump bandwidth Vladimir Davydov
2018-08-28 16:51 ` Vladimir Davydov
2018-08-16 16:12 ` [PATCH 14/18] vinyl: do not try to trigger dump if it is already in progress Vladimir Davydov
2018-08-16 16:12 ` [PATCH 15/18] vinyl: improve dump start/stop logging Vladimir Davydov
2018-08-23 20:18 ` Konstantin Osipov
2018-08-16 16:12 ` Vladimir Davydov [this message]
2018-08-16 16:12 ` [PATCH 17/18] vinyl: set quota timer period to 100 ms Vladimir Davydov
2018-08-23 20:49 ` Konstantin Osipov
2018-08-24 8:18 ` Vladimir Davydov
2018-08-16 16:12 ` [PATCH 18/18] vinyl: throttle tx rate if dump does not catch up Vladimir Davydov
2018-08-23 20:54 ` Konstantin Osipov
2018-08-23 20:58 ` [tarantool-patches] " Konstantin Osipov
2018-08-24 8:21 ` Vladimir Davydov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=473f93f9e1df4f1a6ddbfe5319a80ac3088ab37b.1534432819.git.vdavydov.dev@gmail.com \
--to=vdavydov.dev@gmail.com \
--cc=kostja@tarantool.org \
--cc=tarantool-patches@freelists.org \
--subject='Re: [PATCH 16/18] vinyl: confine quota watermark within sane value range' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox