Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov.dev@gmail.com>
To: Konstantin Osipov <kostja@tarantool.org>
Cc: tarantool-patches@freelists.org
Subject: Re: [PATCH] memtx: free tuples asynchronously when primary index is dropped
Date: Mon, 21 May 2018 10:17:52 +0300	[thread overview]
Message-ID: <20180521071752.cy7c5bqupfqs5mvx@esperanza> (raw)
In-Reply-To: <20180520213118.GA14364@atlas>

On Mon, May 21, 2018 at 12:31:18AM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev@gmail.com> [18/05/20 18:07]:
> > When a memtx space is dropped or truncated, we have to unreference all
> > tuples stored in it. Currently, we do it synchronously, thus blocking
> > the tx thread. If a space is big, tx thread may remain blocked for
> > several seconds, which is unacceptable. This patch makes drop/truncate
> > hand actual work to a background fiber.
> > 
> > Before this patch, drop of a space with 10M 64-byte records took more
> > than 0.5 seconds. After this patch, it takes less than 1 millisecond.
> > 
> > Closes #3408
> 
> This is a duplicate of https://github.com/tarantool/tarantool/issues/444
> 
> It's OK to push.
> 
> You can test it either using error injection or by adding metrics.

I'll add error injection.

> 
> Choice of the constant - 128 iterations of the iterator loop per
> yield - is puzzling. Did you do any math? How much does a fiber
> yield cost?

Choice of 128 was arbitrary. After you noticed that, I did some testing.
If we want to keep max latency < 0.1 ms, which seems to be reasonable,
it's enough to yield every 1000 tuples. The diff is below.

diff --git a/src/box/memtx_hash.c b/src/box/memtx_hash.c
index 7e4c0474..55131740 100644
--- a/src/box/memtx_hash.c
+++ b/src/box/memtx_hash.c
@@ -139,7 +139,8 @@ memtx_hash_index_free(struct memtx_hash_index *index)
 static void
 memtx_hash_index_destroy_f(struct memtx_gc_task *task)
 {
-	enum { YIELD_LOOPS = 128 };
+	/* Yield every 1K tuples to keep latency < 0.1 ms. */
+	enum { YIELD_LOOPS = 1000 };
 
 	struct memtx_hash_index *index = container_of(task,
 			struct memtx_hash_index, gc_task);
diff --git a/src/box/memtx_tree.c b/src/box/memtx_tree.c
index 97452c5f..c72b8fa8 100644
--- a/src/box/memtx_tree.c
+++ b/src/box/memtx_tree.c
@@ -311,7 +311,8 @@ memtx_tree_index_free(struct memtx_tree_index *index)
 static void
 memtx_tree_index_destroy_f(struct memtx_gc_task *task)
 {
-	enum { YIELD_LOOPS = 128 };
+	/* Yield every 1K tuples to keep latency < 0.1 ms. */
+	enum { YIELD_LOOPS = 1000 };
 
 	struct memtx_tree_index *index = container_of(task,
 			struct memtx_tree_index, gc_task);

      reply	other threads:[~2018-05-21  7:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-20 15:06 Vladimir Davydov
2018-05-20 21:31 ` Konstantin Osipov
2018-05-21  7:17   ` Vladimir Davydov [this message]

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=20180521071752.cy7c5bqupfqs5mvx@esperanza \
    --to=vdavydov.dev@gmail.com \
    --cc=kostja@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='Re: [PATCH] memtx: free tuples asynchronously when primary index is dropped' \
    /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