[ https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16435998#comment-16435998 ]
Anoop Sam John commented on HBASE-20188: ---------------------------------------- I tried to test the write perf using PE RandomWrite tests. (Pure writes only). This is with not writing to WAL. (Mutations mark writeToWal = false). I see 2.0.0 perf much lower compared to 1.4.2. (It is DefaultMemstore only). On investigation further I can see that the flush operation takes too long time now. The initial flushes kicked off at ~128 MB mark only. But this takes much longer time than the 1.4.2 case. There are 5 flusher threads in my test. So later on the flush entries for regions are added at 128 MB mark only but when really the flush happens it will grow to 2x and 3x sizes.. Those flushes takes even more. This makes the region size to grow >4x mark and so writes failed and client to retry it. This makes the throughput at these time very low. For flush we make a StoreScanner instance on top of ImmutableSegment. Fetching cells from this Scanners seems to take time! (Added more logs to each op to each which takes time). Not sure what all changes happened in this area. SQM any significant changes? > [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-xac.sh, > HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 > performance evaluation - 8GB.pdf, 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, hbase-env.sh, hbase-site.xml, > hbase-site.xml, lock.127.workloadc.20180402T200918Z.svg, > lock.2.memsize2.c.20180403T160257Z.svg, run_ycsb.sh, tree.txt, workloadx, > workloadx > > > 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)