[
https://issues.apache.org/jira/browse/KUDU-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186286#comment-17186286
]
ASF subversion and git services commented on KUDU-1587:
-------------------------------------------------------
Commit fc8615c37eb4e28f3cc6bea0fcd5a8732451e883 in kudu's branch
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=fc8615c ]
KUDU-1587 part 1: load meter for ThreadPool
This patch introduces a load meter for ThreadPool, aiming to use
active queue management techniques (AQM) such as CoDel [1] in scenarios
where thread pool queue load metrics are applicable (e.g., KUDU-1587).
[1] https://en.wikipedia.org/wiki/CoDel
Change-Id: I640716dc32f193e68361ca623ee7b9271e661d8b
Reviewed-on: http://gerrit.cloudera.org:8080/16332
Tested-by: Kudu Jenkins
Reviewed-by: Andrew Wong <[email protected]>
> Memory-based backpressure is insufficient on seek-bound workloads
> -----------------------------------------------------------------
>
> Key: KUDU-1587
> URL: https://issues.apache.org/jira/browse/KUDU-1587
> Project: Kudu
> Issue Type: Bug
> Components: tserver
> Affects Versions: 0.10.0
> Reporter: Todd Lipcon
> Assignee: Alexey Serbin
> Priority: Critical
> Labels: roadmap-candidate
> Attachments: graph.png, queue-time.png
>
>
> I pushed a uniform random insert workload from a bunch of clients to the
> point that the vast majority of bloom filters no longer fit in buffer cache,
> and the compaction had fallen way behind. Thus, every inserted row turns into
> 40+ seeks (due to non-compact data) and takes 400-500ms. In this kind of
> workload, the current backpressure (based on memory usage) is insufficient to
> prevent ridiculously long queues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
