[ 
https://issues.apache.org/jira/browse/KUDU-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16719839#comment-16719839
 ] 

jiaqiyang edited comment on KUDU-2638 at 12/13/18 7:08 AM:
-----------------------------------------------------------

from the source code i see that :[MaintenanceManager::FindBestOp()]
 * If there's an Op that we can run quickly that frees log retention, we run it.
 // - If we've hit the overall process memory limit (note: this includes memory 
that the Ops cannot
 // free), we run the Op with the highest RAM usage.
 // - If there are Ops that are retaining logs past our target replay size, we 
run the one that has
 // the highest retention (and if many qualify, then we run the one that also 
frees up the
 // most RAM).
 // - Finally, if there's nothing else that we really need to do, we run the Op 
that will improve
 // performance the most.

 

i think the op find use the last rule:Finally, if there's nothing else that we 
really need to do, we run the Op that will improve performance the most.

 

if this is true ,the restart cluster when there is many {{delta}} data fille 
will cost very long time to avalible the table


was (Author: jiaqiyang):
from the source code i see that :[MaintenanceManager::FindBestOp()]
 * If there's an Op that we can run quickly that frees log retention, we run it.
// - If we've hit the overall process memory limit (note: this includes memory 
that the Ops cannot
// free), we run the Op with the highest RAM usage.
// - If there are Ops that are retaining logs past our target replay size, we 
run the one that has
// the highest retention (and if many qualify, then we run the one that also 
frees up the
// most RAM).
// - Finally, if there's nothing else that we really need to do, we run the Op 
that will improve
// performance the most.

 

i think the op find use the last rule:Finally, if there's nothing else that we 
really need to do, we run the Op that will improve performance the most.

 

if this is true ,the restart cluster when there is many detel data fille will 
cost very long time to avalible the table

> kudu cluster restart very long time to reused
> ---------------------------------------------
>
>                 Key: KUDU-2638
>                 URL: https://issues.apache.org/jira/browse/KUDU-2638
>             Project: Kudu
>          Issue Type: Improvement
>            Reporter: jiaqiyang
>            Priority: Major
>
> when restart my kudu cluster ;all tablet not avalible:
> run kudu cluster ksck show that:
> Table Summary                                                                 
>                                                                               
>    
> Name | Status | Total Tablets | Healthy | Under-replicated | Unavailable
> --------------------------------------------------------------------------------+------------
> t1 | HEALTHY | 1 | 1 | 0 | 0
> t2 | UNAVAILABLE | 5 | 0 | 1 | 4
> t3 | UNAVAILABLE | 6 | 2 | 0 | 4
> t3 | UNAVAILABLE | 3 | 0 | 0 | 3



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to