[
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16424993#comment-16424993
]
ramkrishna.s.vasudevan commented on HBASE-20188:
------------------------------------------------
What was the config that was missing for short circuit reads in hbase-2? In our
recent R + W experiments we had to enable short circuit reads for our tests
because without that we had Port issues because the underlying drives were
faster and so every local read trying to establiish the TCP was failing and
retrying. (thus adding to latency).
When the number of threads were lesser we did not get this issue. With short
circuit reads this problem was not there but we had to explicitly enable it. We
have done some detalied study on the effect of short circuit reads and have our
analysis on it.
How is hbase1 running with short circuit by itself?
Another important thing Anoop found while doing those test was this config
{code:java}
<property>
<name>dfs.client.read.shortcircuit.skip.checksum</name>
<value>true</value>
</property>
{code}
We had to enable it because in hbase we does its own checksums.
Also we increased the '>dfs.client.read.shortcircuit.streams.cache.size' and
'dfs.client.socketcache.capacity'
> [TESTING] Performance
> ---------------------
>
> Key: HBASE-20188
> URL: https://issues.apache.org/jira/browse/HBASE-20188
> Project: HBase
> Issue Type: Umbrella
> Components: Performance
> Reporter: stack
> Assignee: stack
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: CAM-CONFIG-V01.patch, HBASE-20188.sh, HBase 2.0
> performance evaluation - Basic vs None_ system settings.pdf,
> ITBLL2.5B_1.2.7vs2.0.0_cpu.png, ITBLL2.5B_1.2.7vs2.0.0_gctime.png,
> ITBLL2.5B_1.2.7vs2.0.0_iops.png, ITBLL2.5B_1.2.7vs2.0.0_load.png,
> ITBLL2.5B_1.2.7vs2.0.0_memheap.png, ITBLL2.5B_1.2.7vs2.0.0_memstore.png,
> ITBLL2.5B_1.2.7vs2.0.0_ops.png,
> ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png,
> YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png,
> YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png,
> flamegraph-1072.1.svg, flamegraph-1072.2.svg,
> lock.127.workloadc.20180402T200918Z.svg,
> lock.2.memsize2.c.20180403T160257Z.svg, tree.txt
>
>
> How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor
> that it is much slower, that the problem is the asyncwal writing. Does
> in-memory compaction slow us down or speed us up? What happens when you
> enable offheaping?
> Keep notes here in this umbrella issue. Need to be able to say something
> about perf when 2.0.0 ships.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
