[
https://issues.apache.org/jira/browse/HBASE-20520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16461468#comment-16461468
]
stack commented on HBASE-20520:
-------------------------------
bq. You think the too-early log roll maybe had perf impact on our write loads?
There's a hiccup each time we roll where writes are blocked for a short while
so yes, this will have had some impact but small in the scheme of things I'd
say given the new WAL is made ahead of the roll and dealing with the old is
backgrounded.... but let me remeasure (There is also our blocking when too many
WALs but in my perf tests I'd turned that off).
bq. In the logs I noticed that WAL A gets renamed to WAL B and in the immediate
second WAL B gets renamed to WAL C. Is that because of the issue mentioned here?
Example please [~ram_krish] (HBASE-20503 ? Where Archiving seems to cut in
prematurely?)
> Failed effort upping default HDFS blocksize, hbase.regionserver.hlog.blocksize
> ------------------------------------------------------------------------------
>
> Key: HBASE-20520
> URL: https://issues.apache.org/jira/browse/HBASE-20520
> Project: HBase
> Issue Type: Sub-task
> Components: conf
> Reporter: stack
> Priority: Major
>
> Good one found by our [~mdrob]. Problem in the parent issue where failed
> attempt doubling default block size but halving the size at which roll -- so
> we end up in roughly same place only we make less small WALs in those cases
> where we are writing furiously and fail to roll before starting a new block.
> From Drob: ".../we drop default log roll to 0.5, but we don't actually
> increase the block size... AbstractProtobufLogWriter.java:164 still uses
> default HDFS block sizing and AbstractFSWAL.java:408 block size is only used
> in a log message, never actually makes it to files...".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
