You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Bryan Duxbury (JIRA)" <ji...@apache.org> on 2008/02/04 22:25:08 UTC

[jira] Updated: (HBASE-70) [hbase] memory management

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

Bryan Duxbury updated HBASE-70:
-------------------------------

    Component/s: regionserver

> [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.