Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> Prewarming in-memory column families


Copy link to this message
-
Re: Prewarming in-memory column families
It's touchy... what if the data set doesn't fit in the in-memory's
part of the block cache (which is 25%)? Maybe the user only wants to
keep "in-memory" those edits that are being used? What about the IO
hit of assigning those regions at startup that would now need to read
X GBs all at once?

FWIW I've never been a fan of that setting.

J-D

On Tue, Feb 26, 2013 at 5:04 PM, Sergey Shelukhin
<[EMAIL PROTECTED]> wrote:
> should we make this built-in? Sounds like default user intent for in-memory.
>
> On Tue, Feb 26, 2013 at 2:13 PM, Stack <[EMAIL PROTECTED]> wrote:
>
>> On Fri, Feb 22, 2013 at 7:39 AM, Eric Czech <[EMAIL PROTECTED]> wrote:
>>
>> > Hi everyone,
>> >
>> > Are blocks for in-memory column families automatically loaded in to the
>> > block cache on restart?
>>
>>
>> No
>>
>>
>> >  If not, would anyone recommend running a scan with
>> > .setCacheBlocks(true) after a restart for in-memory column families?
>> >
>>
>> Yes.
>>
>> It should be easy verifying whether the above warmup had an effect.
>>
>> Good luck,
>> St.Ack
>>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB