hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17408) Introduce per request limit by number of mutations
Date Tue, 03 Jan 2017 22:09:58 GMT

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

stack commented on HBASE-17408:
-------------------------------

bq. Ted, giving more context definitely helps others to follow along.

Yep.

bq. The server would have to buffer up all the responses causing OOM on the server side.

We need to chunk multiget as we do Scans? HBASE-15414

bq. On the second instance (which is the same reason Ted logged this issue), the application
was doing multi requests with Increment. In this case, it was doing 15K increments in a single
RPC, which would take longer than RPC timeout. 

Thats a good one. Thats broke. Yeah, a bound would help piecemealing in increments in batches
< 15k. Thanks makes sense.

> Introduce per request limit by number of mutations
> --------------------------------------------------
>
>                 Key: HBASE-17408
>                 URL: https://issues.apache.org/jira/browse/HBASE-17408
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Ted Yu
>
> HBASE-16224 introduced hbase.client.max.perrequest.heapsize to limit the amount of data
sent from client.
> We should consider adding per request limit through the number of mutations in a batch.
> In recent troubleshooting sessions, customer had to do this in their application code
to avoid OOME on the server side.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message