Tarantool development patches archive
 help / color / mirror / Atom feed
From: Nikita Pettik <korablev@tarantool.org>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH] vinyl: unthrottle scheduler on checkpoint
Date: Mon, 27 Apr 2020 12:17:01 +0000	[thread overview]
Message-ID: <20200427121701.GA30870@tarantool.org> (raw)
In-Reply-To: <3f1e18cc-cc18-b586-825b-3e4e3a9c8e3f@tarantool.org>

On 22 Apr 01:13, Vladislav Shpilevoy wrote:
> Hi! Thanks for the patch!
> 
> >  
> >  	/*
> > -	 * If the scheduler is throttled due to errors, do not wait
> > -	 * until it wakes up as it may take quite a while. Instead
> > -	 * fail checkpoint immediately with the last error seen by
> > -	 * the scheduler.
> > +	 * It makes no sense throttling checkpoint process since
> > +	 * it can be either ran manually or due to timeout. At this
> > +	 * point let's ignore it.
> 
> Kostja's questio is fair. Can it be done for manual snapshots only?
> Automated checkpoints already have problems with killing the disk,
> when multiple instances on the same machine start them at the same
> time. With unthrotled scheduler it is going to get worse.
> 
> However, if this is hard to detect, then it is ok. Just do a quick
> check if it is possible.

Checkpoint daemon uses directly box.snapshot(), so now we can't tell
whether checkpoint is launched manually or automatically. To differ
these scenarious we can make checkpoint daemon call sort of
box.__scheduled_snapshot() (which won't be part of public API ofc).
Then we will be able to pass boolean parameter to begin_checkpoint()
indicating manual/auto mode. Or simply close issue as wont fix :)
 
> >  	 */
> >  	if (scheduler->is_throttled) {
> > -		struct error *e = diag_last_error(&scheduler->diag);
> > -		diag_add_error(diag_get(), e);
> > -		say_error("cannot checkpoint vinyl, "
> > -			  "scheduler is throttled with: %s", e->errmsg);
> > -		return -1;
> > +		say_info("scheduler is unthrottled due to checkpoint process");
> > +		scheduler->is_throttled = false;
> 
> Is there a simple way to let the throttling continue after the
> checkpoint is finished?

Hm, not simple but..For instance, we can introduce another one flag
"is_checkpoint_aborted" alonside with workaround (tests seem to pass):

diff --git a/src/box/vy_scheduler.c b/src/box/vy_scheduler.c
index f57f10119..666d0a008 100644
--- a/src/box/vy_scheduler.c
+++ b/src/box/vy_scheduler.c
@@ -615,7 +615,8 @@ vy_scheduler_dump(struct vy_scheduler *scheduler)
 
        /* Wait for dump to complete. */
        while (vy_scheduler_dump_in_progress(scheduler)) {
-               if (scheduler->is_throttled) {
+               if (scheduler->is_throttled &&
+                   !scheduler->checkpoint_in_progress) {
                        /* Dump error occurred. */
                        struct error *e = diag_last_error(&scheduler->diag);
                        diag_add_error(diag_get(), e);
@@ -692,8 +693,7 @@ vy_scheduler_begin_checkpoint(struct vy_scheduler *scheduler)
         * point let's ignore it.
         */
        if (scheduler->is_throttled) {
-               say_info("scheduler is unthrottled due to checkpoint process");
-               scheduler->is_throttled = false;
+               say_info("scheduler is temporary unthrottled due to checkpoint process");
        }
 
        if (!vy_scheduler_dump_in_progress(scheduler)) {
@@ -707,6 +707,7 @@ vy_scheduler_begin_checkpoint(struct vy_scheduler *scheduler)
        }
        scheduler->generation++;
        scheduler->checkpoint_in_progress = true;
+       scheduler->is_checkpoint_aborted = false;
        fiber_cond_signal(&scheduler->scheduler_cond);
        say_info("vinyl checkpoint started");
        return 0;
@@ -723,7 +724,7 @@ vy_scheduler_wait_checkpoint(struct vy_scheduler *scheduler)
         * checkpoint started have been dumped.
         */
        while (vy_scheduler_dump_in_progress(scheduler)) {
-               if (scheduler->is_throttled) {
+               if (scheduler->is_checkpoint_aborted) {
                        /* A dump error occurred, abort checkpoint. */
                        struct error *e = diag_last_error(&scheduler->diag);
                        diag_add_error(diag_get(), e);
@@ -2104,7 +2105,10 @@ error:
                        scheduler->timeout = inj->dparam;
                say_warn("throttling scheduler for %.0f second(s)",
                         scheduler->timeout);
-               scheduler->is_throttled = true;
+               if (scheduler->checkpoint_in_progress)
+                       scheduler->is_checkpoint_aborted = true;
+               else
+                       scheduler->is_throttled = true;
                fiber_sleep(scheduler->timeout);
                scheduler->is_throttled = false;
        }

  parent reply	other threads:[~2020-04-27 12:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31 14:42 Nikita Pettik
2020-03-31 14:53 ` Konstantin Osipov
2020-04-21 23:13 ` Vladislav Shpilevoy
2020-04-22  0:32   ` Konstantin Osipov
2020-04-27 12:17   ` Nikita Pettik [this message]
2020-04-27 12:39     ` Konstantin Osipov
2020-04-27 15:18       ` Nikita Pettik
2020-04-27 15:20         ` Konstantin Osipov
2020-04-27 15:37           ` Nikita Pettik
2020-04-27 15:48             ` Konstantin Osipov
2020-04-27 15:52               ` Nikita Pettik

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=20200427121701.GA30870@tarantool.org \
    --to=korablev@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH] vinyl: unthrottle scheduler on checkpoint' \
    /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