[
https://issues.apache.org/jira/browse/HBASE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565981#action_12565981
]
stack commented on HBASE-70:
----------------------------
Moving accounting of space up to the region level sounds fine by me. Can you
say more how it'd work? And why it'd make for less contention?
By the way, I fail to see how the "3 serious drawbacks" are (serious
drawbacks). Please say a few words on why things are more efficient done at
store level than when done at region level? It was just a single map in
memory. Profiling it was never a problem. Pain moving the memcaches doesn't
count as a drawback (if we're moving it in the wrong direction -- smile). And
was there contention when it was at the region level? And true, we didn't know
when filled, how much belonged to each family but was this a problem?
> [hbase] memory management
> -------------------------
>
> Key: HBASE-70
> URL: https://issues.apache.org/jira/browse/HBASE-70
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: stack
>
> Each Store has a Memcache of edits that is flushed on a fixed period (It used
> to be flushed when it grew beyond a limit). A Region can be made up of N
> Stores. A regionserver has no upper bound on the number of regions that can
> be deployed to it currently. Add to this that per mapfile, we have read the
> index into memory. We're also talking about adding caching of blocks and
> cells.
> We need a means of keeping an account of memory usage adjusting cache sizes
> and flush rates (or sizes) dynamically -- using References where possible --
> to accomodate deployment of added regions. If memory is strained, we should
> reject regions proffered by the master with a resouce-constrained, or some
> such, message.
> The manual sizing we currently do ain't going to cut it for clusters of any
> decent size.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
