[
https://issues.apache.org/jira/browse/HBASE-19389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16274786#comment-16274786
]
Chance Li commented on HBASE-19389:
-----------------------------------
bq. In the solution - abt the concurrent max #columns . So this is the max
number of different columns for same CF but across rows?
1. for same CF maybe across rows, on test the row is random.
2. when the PUT's cell more than
#parallelPutToStoreThreadLimitCheckMinColumnNum, and the concurrency of adding
to the CSLM exceed the #parallelPutToStoreThreadLimit, then result in
RegionTooBusyException. We want to protected RS avoiding do such slow call (
see the CSLM's concurrency writing test number above), I'd say this is a part
of RS self-protected (improve the reliability of RS) under some extreme case
like as the abused client.
> Limit concurrency of put with dense (hundreds) columns to prevent write
> hander exhausted
> ----------------------------------------------------------------------------------------
>
> Key: HBASE-19389
> URL: https://issues.apache.org/jira/browse/HBASE-19389
> Project: HBase
> Issue Type: Improvement
> Components: Performance
> Affects Versions: 2.0.0
> Environment: 2000+ Region Servers
> PCI-E ssd
> Reporter: Chance Li
> Assignee: Chance Li
> Fix For: 2.0.0, 3.0.0
>
> Attachments: CSLM-concurrent-write.png, metrics-1.png, ycsb-result.png
>
>
> In a large cluster, with a large number of clients, we found the RS's
> handlers are all busy sometimes. And after investigation we found the root
> cause is about CSLM, such as compare function heavy load. We reviewed the
> related WALs, and found that there were many columns (more than 1000 columns)
> were writing at that time.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
