[PATCH 8/8] vinyl: keep track of thread pool idle ratio

Konstantin Osipov kostja at tarantool.org
Thu Sep 6 13:57:42 MSK 2018


* Vladimir Davydov <vdavydov.dev at gmail.com> [18/09/06 13:53]:
> > > > > To understand whether the disk is fully utilized or can still handle
> > > > > more compaction load and make right decisions regarding transaction
> > > > > throttling, we need a metric that would report how much time worker
> > > > > threads spent being idle. So this patch adds two new metrics to global
> > > > > statistics, disk.dump_idle_ratio and compact_idle_ratio, which show how
> > > > > much time dump threads and compaction threads were idle, respectively.
> > > > > The metrics are updated using the following formula:
> > > > > 
> > > > >                        idle_time
> > > > >   idle_ratio = --------------------------
> > > > >                dump_period * worker_count
> > > > 
> > > > I don't understand the formula. There can be many workers.
> > > > Is idle time measured per worker or per entire pool? 
> > > > 
> > > > If it is measured per entire pool, how is idle time calculated if
> > > > some workers are busy and some not?
> > > 
> > > It is measured for entire pool - note that I divide the result by
> > > worker_count. E.g. if there were two workers and one of them were
> > > busy all the time between two last dumps while another were idle,
> > > idle_ratio would be 0.5.
> > 
> > This looks imprecise. Why not measure idle time of each worker and
> > then even it out over the total number of workers?
> 
> That's exactly what I do. I maintain the idle time for each worker
> thread and then divide it by the total number of workers.

This is not what you've written in the comment, though.

> > Besides, once again, how do you define the window over which you
> > measure?
> I use dump period for the window, i.e. time between two subsequent
> memory dumps. Respectively, I update the idle_ratio after each memory
> dump. I'm planning to update throttle rate limit there too.

This choice of time window looks arbitrary. Why do you think it's
a good choice? 


-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.io - www.twitter.com/kostja_osipov



More information about the Tarantool-patches mailing list