[
https://issues.apache.org/jira/browse/HBASE-17910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17226438#comment-17226438
]
Karthik Palanisamy commented on HBASE-17910:
--------------------------------------------
[~anoop.hbase] [~zhangduo] [~busbey] [~elserj]
Recently, one of our user reported high CPU usage in namenode. On our
troubleshooting, found millions of OPEN and GetFileInfo calls continuously to
namenode, is because of readType STREAM which creates multiple scanners. I
understand we switch readType to STREAM automatically but I don't find any flag
to disable STREAM. I am curious if that is the expected design?
If the scan become get.
if the scan with startrow and stoprow.
if the scan keeps running for long time. I.e kv bytesRead > preadMaxBytes.
(Default preadMaxBytes is 4*blockSize, which is 4*64KB).
Maybe this spike could be at every cluster but the user might not be noticed
yet. At this moment, I am trying to work around with
"hbase.storescanner.pread.max.bytes" and
"hbase.cells.scanned.per.heartbeat.check". Will post more updates next week
with the root cause.
{code:java}
this(family, minVersions, maxVersions, ttl, keepDeletedCells,
timeToPurgeDeletes, comparator,
conf.getLong(HConstants.TABLE_MAX_ROWSIZE_KEY,
HConstants.TABLE_MAX_ROWSIZE_DEFAULT),
conf.getBoolean("hbase.storescanner.use.pread", false),
getCellsPerTimeoutCheck(conf),
conf.getBoolean(StoreScanner.STORESCANNER_PARALLEL_SEEK_ENABLE, false),
conf.getLong(StoreScanner.STORESCANNER_PREAD_MAX_BYTES, 4 * blockSize),
newVersionBehavior);{code}
> Use separated StoreFileReader for streaming read
> ------------------------------------------------
>
> Key: HBASE-17910
> URL: https://issues.apache.org/jira/browse/HBASE-17910
> Project: HBase
> Issue Type: Improvement
> Components: regionserver, Scanners
> Affects Versions: 2.0.0
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Priority: Major
> Fix For: 2.0.0
>
>
> For now we have already supportted using private readers for compaction, by
> creating a new StoreFile copy. I think a better way is to allow creating
> multiple readers from a single StoreFile instance, thus we can avoid the ugly
> cloning, and the reader can also be used for streaming scan, not only for
> compaction.
> The reason we want to do this is that, we found a read amplification when
> using short circult read. {{BlockReaderLocal}} will use an internal buffer to
> read data first, the buffer size is based on the configured buffer size and
> the readahead option in CachingStrategy. For normal pread request, we should
> just bypass the buffer, this can be achieved by setting readahead to 0. But
> for streaming read I think the buffer is somehow still useful? So we need to
> use different FSDataInputStream for pread and streaming read.
> And one more thing is that, we can also remove the streamLock if streaming
> read always use its own reader.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
