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

Alexey Serbin updated KUDU-1587:
--------------------------------
    Fix Version/s: 1.13.0
       Resolution: Fixed
           Status: Resolved  (was: In Review)

With this 
[commit|https://github.com/apache/kudu/commit/ee3bb83575a051c2feade1f8c159b2902a7160d5],
 it's now possible to specify a threshold for the op apply times.  While not 
yet enabled by default with some safe threshold for the apply queue times, this 
allows to engage this new behavior of rejecting write requests, if needed.  To 
do so, set the {{\-\-tablet_apply_pool_overload_threshold_ms}} tablet server's 
flag to the desired value (anything greater than 0 turns on the new behavior).

> 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, 1.0.0, 1.0.1, 1.1.0, 1.2.0, 1.3.0, 1.3.1, 1.4.0, 
> 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.7.1, 1.9.0, 1.10.0, 1.10.1, 1.11.0, 1.12.0, 
> 1.11.1
>            Reporter: Todd Lipcon
>            Assignee: Alexey Serbin
>            Priority: Critical
>              Labels: roadmap-candidate
>             Fix For: 1.13.0
>
>         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)

Reply via email to