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 >> Slow Get Performance (or how many disk I/O does it take for one non-cached read?)


Copy link to this message
-
Re: Slow Get Performance (or how many disk I/O does it take for one non-cached read?)
Actually there are 2 read aheads in linux (from what I learned last time, I
did benchmarking on random reads). One is the filesystem readahead which
linux does and then there is also a disk level read ahead which can be
modified by using the hdparm command. IIRC, there is no sure way of
removing filesystem level readaheads but disk level read aheads can be
modified.

For regular HDDs, if you are reading small keys, don't think changing the
disk level read ahead will make a big difference because the seek latency
will dominate. However, for SSDs, it did help to reduce the disk level read
ahead in my tests - because the seek latency is small and reading a lot of
unnecessary data is relatively expensive.
On Sat, Feb 1, 2014 at 11:07 PM, Vladimir Rodionov
<[EMAIL PROTECTED]>wrote:

> Block size does not matter on Linux . 256KB on read prefetch (read ahead).
>
> Best regards,
> Vladimir Rodionov
> Principal Platform Engineer
> Carrier IQ, www.carrieriq.com
> e-mail: [EMAIL PROTECTED]
>
> ________________________________________
> From: lars hofhansl [[EMAIL PROTECTED]]
> Sent: Saturday, February 01, 2014 10:33 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Slow Get Performance (or how many disk I/O does it take for
> one non-cached read?)
>
> Hmm... Interesting. I expected there to be a better improvement from
> smaller blocks.
>
> So it's really just IOPS (and block size does not matter), in which case,
> yes, HBase checksum will save you 50% IOPS for each data block (and since
> index blocks are cache) it'll save 50% total IOPS.
>
>
>
> ________________________________
>  From: Jan Schellenberger <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Saturday, February 1, 2014 9:38 PM
> Subject: Re: Slow Get Performance (or how many disk I/O does it take for
> one non-cached read?)
>
>
> I've experimented with the block size.  Here are results:
> 4k - 60reads/sec  - 1.2GB totalStaticIndexSize
> 8k - 80reads/sec  - 660MB totalStaticIndexSize
> 16k - 90reads/sec  - 330MB totalStaticIndexSize
> and previously
> 64k - 80reads/sec - ~100mb totalStaticIndexSize
>
>
> Also, I turned off caching and you are correct, the index blocks seem to be
> cached always - the blockCachedSize grows until it reaches
> totalStaticIndexSize and then stops growing.  If you turn caching on, it
> will grow until the maxHeap * blockCacheSize (.4 in my case).
>
> I saw no performance difference between caching off/on so I guess off is
> fine.
>
> Yes, I always do a major_compact before testing.
>
> I think this probably concludes my question - I will try to upgrade to a
> newer hbase version to get the CRC32/HDFS check fix and we will probably
> have to evaluate SSD's.
>
> Cheers, everyone.
>
>
>
>
> --
> 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-tp4055545p4055582.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 [EMAIL PROTECTED] and
> delete or destroy any copy of this message and its attachments.
>

 
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