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);
prev parent 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