You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Xu Yao (Jira)" <ji...@apache.org> on 2019/08/29 06:09:00 UTC

[jira] [Comment Edited] (KUDU-2929) Don't starve compactions under memory pressure

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

Xu Yao edited comment on KUDU-2929 at 8/29/19 6:08 AM:
-------------------------------------------------------

Yes, while writing continuously (including insert and update), if memory pressure occurs. The tablet server will create more DRSs, and the DMSs will take up a lot of memory. This may cause the tablet server to keep dealing with memory pressures.


was (Author: oclarms):
Yes, while writing continuously (including insert and update), if memory pressure occurs. The tablet server will create more DRS, and the DMS will take up a lot of memory. This may cause the tablet server to keep dealing with memory pressures.

> Don't starve compactions under memory pressure
> ----------------------------------------------
>
>                 Key: KUDU-2929
>                 URL: https://issues.apache.org/jira/browse/KUDU-2929
>             Project: Kudu
>          Issue Type: Improvement
>          Components: perf, tablet
>            Reporter: Andrew Wong
>            Priority: Major
>
> When a server is under memory pressure, the maintenance manager exclusively will look for the maintenance op that frees up the most memory. Some operations, like compactions, do not register any amount of "anchored memory" and effectively don't qualify for consideration.
> This means that when a tablet server is under memory pressure, compactions will never be scheduled, even though compacting may actually end up reducing memory (e.g. combining many rowsets-worth of CFileReaders into a single rowset). While it makes sense to prefer flushes to compactions, it probably doesn't make sense to do nothing vs compact.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)