[ 
https://issues.apache.org/jira/browse/KUDU-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Todd Lipcon updated KUDU-1972:
------------------------------
    Description: 
The current design of the maintenance manager includes a dedicated thread that 
wakes up every so often (default to 250 ms), looks for work to do, and 
schedules it to be done on helper threads. On a large tablet server, "look for 
work to do" can be very CPU intensive. We should explore ways to mitigate this.

Additionally, if we identify "cold" tablets (i.e. those not servicing any 
writes), we should be able to further reduce their scheduling load, perhaps by 
not running the compaction knapsack solver on them at all.

  was:
The current design of the maintenance manager includes a dedicated thread that 
wakes up every so often (default to 250 ms), looks for work to do, and 
schedules it to be done on helper threads. On a large cluster, "look for work 
to do" can be very CPU intensive. We should explore ways to mitigate this.

Additionally, if we identify "cold" tablets (i.e. those not servicing any 
writes), we should be able to further reduce their scheduling load, perhaps by 
not running the compaction knapsack solver on them at all.


> Explore ways to reduce maintenance manager CPU load
> ---------------------------------------------------
>
>                 Key: KUDU-1972
>                 URL: https://issues.apache.org/jira/browse/KUDU-1972
>             Project: Kudu
>          Issue Type: Sub-task
>          Components: tserver
>    Affects Versions: 1.4.0
>            Reporter: Adar Dembo
>              Labels: data-scalability
>
> The current design of the maintenance manager includes a dedicated thread 
> that wakes up every so often (default to 250 ms), looks for work to do, and 
> schedules it to be done on helper threads. On a large tablet server, "look 
> for work to do" can be very CPU intensive. We should explore ways to mitigate 
> this.
> Additionally, if we identify "cold" tablets (i.e. those not servicing any 
> writes), we should be able to further reduce their scheduling load, perhaps 
> by not running the compaction knapsack solver on them at all.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to