hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <la...@apache.org>
Subject Re: Slow Get Performance (or how many disk I/O does it take for one non-cached read?)
Date Sat, 01 Feb 2014 06:20:35 GMT
You cannot disable the cache for the index block. The index blocks are always cached.

Well maybe you can by setting the block cache size to 0, would have to try :)

 From: Vladimir Rodionov <vrodionov@carrieriq.com>
To: "user@hbase.apache.org" <user@hbase.apache.org>; lars hofhansl <larsh@apache.org>

Sent: Friday, January 31, 2014 10:05 PM
Subject: RE: Slow Get Performance (or how many disk I/O does it take for one non-cached read?)

Lars wrote:
>> You can also try disabling the block cache, as it does not help in your scenario

It helps with caching INDEX blocks.? Or you suggest relying on OS page cache?  BLOOM blocks
are useless, I think, therefore Bloom filter can be disabled.

Best regards,
Vladimir Rodionov
Principal Platform Engineer
Carrier IQ, www.carrieriq.com
e-mail: vrodionov@carrieriq.com


From: lars hofhansl [larsh@apache.org]
Sent: Friday, January 31, 2014 9:25 PM
To: user@hbase.apache.org
Subject: Re: Slow Get Performance (or how many disk I/O does it take for one non-cached read?)

If you data does not fit into cache and your request patter is essentially random then each
GET will likely cause an entirely new HFile block to be read from disk (since that block was
likely evicted due to other random GETs).

This is somewhat of a worst case for HBase. The default block size if 64k.
That is why the cache hit ratio is low and your disk IO is high. For each GET even reading
just a single KV of a few hundred bytes, HBase needs to bring in 64k worth of data from disk.

With your load you can set the block size as low as 4k (or even lower).
That way HBase would still need to bring in a new block for each GET, but that block will
only be 4k.
You can also try disabling the block cache, as it does not help in your scenario anyway.

Note that I mean the HFile block size, not the HDFS block (which is typically 64, 128, or
256 mb).

You can set this via the HBase as a column family parameter: BLOCKSIZE => '4906'
I'd start with 4k and then vary up and down and do some testing.

Truly random reads are very hard for any caching system.
Is your load really truly random, or is it just for testing?

-- Lars

----- Original Message -----
From: Jan Schellenberger <leipzig3@gmail.com>
To: user@hbase.apache.org
Sent: Friday, January 31, 2014 3:12 PM
Subject: Slow Get Performance (or how many disk I/O does it take for one non-cached read?)

I am running a cluster and getting slow performance - about 50 reads/sec/node
or about 800 reads/sec for the cluster.  The data is too big to fit into
memory and my access pattern is completely random reads which is presumably
difficult for hbase.  Is my read speed reasonable?  I feel like typical read
speeds I've seen reported are much higher?

Hardware/Software Configuration:
17 nodes + 1 master
8 cores
24 gigs ram
4x1TB 3.5" hard drives (I know this is low for hbase - we're working on
getting more disks)
running Cloudera CDH 4.3 with hbase .94.6
Most configurations are default except I'm using 12GB heap space/region
server and the block cache is .4 instead of .25 but neither of these two
things makes much of a difference.   I am NOT having a GC issue.  Latencies
are around 40ms and 99% is 200ms.

Dataset Description:
6 tables ~300GB each (uncompressed) or 120GB each compressed <- compression
speeds things up a bit.
I just ran a major compaction so block locality is 100%
Each Table has a single column family and a single column ("c:d").
keys are short strigs ~10-20 characters.
values are short json ~500 characters
100% Gets.  No Puts
I am heavily using time stamping.  maxversions is set to Integer.MAXINT.  My
gets have a maxretrieved of 200.  A typical row would have < 10 versions on
average though.  <1% of queries would max out at 200 versions returned.

Here are table configurations (I've also tried Snappy compression)
ESSION => 'NONE', MIN_VERSIONS => '0', TTL => '2147483647',
  'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', ENCODE_ON_DISK =>
'true', BLOCKCACHE => 'true'}]}

I am using the master node to query (with 20 threads) and get about 800
Gets/second.  Each worker node is completely swamped by disk i/o - I'm
seeing 80 io/sec with iostat for each of the 4 disk with a throughput of
about 10MB/sec each.  So this means it's reading roughly 120kB/transfer and
it's taking about 8 Hard Disk I/O's per Get request.  Does that seem
reasonable?  I've read the HFILE specs and I feel if the block index is
loaded into memory, it should take 1 hard disk read to read the proper block
with my row.

The region servers have a blockCacheHitRatio of about 33% (no compression)
or 50% (snappy compression)

Here are some regionserver stats while I'm running queries.  This is the
uncompressed table version and queries are only 38/sec

requestsPerSecond=38, numberOfOnlineRegions=212,
numberOfStores=212, numberOfStorefiles=212, storefileIndexSizeMB=0,
rootIndexSizeKB=190, totalStaticIndexSizeKB=172689,
totalStaticBloomSizeKB=79692, memstoreSizeMB=0, mbInMemoryWithoutWAL=0,
numberOfPutsWithoutWAL=0, readRequestsCount=1865459,
writeRequestsCount=0, compactionQueueSize=0, flushQueueSize=0,
usedHeapMB=4565, maxHeapMB=12221, blockCacheSizeMB=4042.53,
blockCacheFreeMB=846.07, blockCacheCount=62176,
blockCacheHitCount=5389770, blockCacheMissCount=9909385,
blockCacheEvictedCount=2744919, blockCacheHitRatio=35%,
blockCacheHitCachingRatio=65%, hdfsBlocksLocalityIndex=99,
slowHLogAppendCount=0, fsReadLatencyHistogramMean=1570049.34,

View this message in context: http://apache-hbase.679495.n3.nabble.com/Slow-Get-Performance-or-how-many-disk-I-O-does-it-take-for-one-non-cached-read-tp4055545.html
Sent from the HBase User mailing list archive at Nabble.com.

Confidentiality Notice:  The information contained in this message, including any attachments
hereto, may be confidential and is intended to be read only by the individual or entity to
whom this message is addressed. If the reader of this message is not the intended recipient
or an agent or designee of the intended recipient, please note that any review, use, disclosure
or distribution of this message or its attachments, in any form, is strictly prohibited. 
If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com
and delete or destroy any copy of this message and its attachments.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message