[jira] [Updated] (HBASE-22496) UnsafeAccess.unsafeCopy should not copy more than UNSAFE_COPY_THRESHOLD on each iteration

[ https://issues.apache.org/jira/browse/HBASE-22496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22496: - Fix Version/s: 1.3.5 2.1.5 2.0.6 1.4.10

[jira] [Commented] (HBASE-22496) UnsafeAccess.unsafeCopy should not copy more than UNSAFE_COPY_THRESHOLD on each iteration

[ https://issues.apache.org/jira/browse/HBASE-22496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16851458#comment-16851458 ] Zheng Hu commented on HBASE-22496: -- +1, Let me commit. > UnsafeAccess.unsafeCopy should not copy more

[jira] [Updated] (HBASE-22491) Separate the heap HFileBlock and offheap HFileBlock because the heap block won't need refCnt and save into prevBlocks list before shipping

[ https://issues.apache.org/jira/browse/HBASE-22491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22491: - Attachment: HBASE-22491.HBASE-21879.v02.patch > Separate the heap HFileBlock and offheap HFileBlock

[jira] [Updated] (HBASE-22491) Separate the heap HFileBlock and offheap HFileBlock because the heap block won't need refCnt and save into prevBlocks list before shipping

[ https://issues.apache.org/jira/browse/HBASE-22491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22491: - Attachment: HBASE-22491.HBASE-21879.v01.patch > Separate the heap HFileBlock and offheap HFileBlock

[jira] [Created] (HBASE-22491) Separate the heap HFileBlock and offheap HFileBlock because the heap block won't need refCnt and save into prevBlocks list before shipping

Zheng Hu created HBASE-22491: Summary: Separate the heap HFileBlock and offheap HFileBlock because the heap block won't need refCnt and save into prevBlocks list before shipping Key: HBASE-22491 URL:

[jira] [Commented] (HBASE-15867) Move HBase replication tracking from ZooKeeper to HBase

[ https://issues.apache.org/jira/browse/HBASE-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850297#comment-16850297 ] Zheng Hu commented on HBASE-15867: -- bq. will we track peer changes in table or we only keep the current

[jira] [Commented] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850290#comment-16850290 ] Zheng Hu commented on HBASE-22387: -- After enable the short-circuit read feature, the throughtput

[jira] [Comment Edited] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850290#comment-16850290 ] Zheng Hu edited comment on HBASE-22387 at 5/29/19 1:48 AM: --- After enable the

[jira] [Updated] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22387: - Attachment: G1GC-stw.case02-with-buffer-size-64KB.png > Evaluate the get/scan performance after reading

[jira] [Updated] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22387: - Attachment: G1GC-stage-stw.case02-with-buffer-size-64KB.png > Evaluate the get/scan performance after

[jira] [Updated] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22387: - Attachment: QPS-latency.case02-with-buffer-size-64KB.png > Evaluate the get/scan performance after

[jira] [Commented] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849551#comment-16849551 ] Zheng Hu commented on HBASE-22387: -- I think the periodic QPS dropping in

[jira] [Comment Edited] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849446#comment-16849446 ] Zheng Hu edited comment on HBASE-22387 at 5/28/19 9:20 AM: --- bq. Did u config

[jira] [Updated] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22387: - Attachment: QPS-latency.case01.png > Evaluate the get/scan performance after reading HFile block into

[jira] [Commented] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849472#comment-16849472 ] Zheng Hu commented on HBASE-22387: -- Attached two pictures from my testing cluster with 5 nodes, each

[jira] [Updated] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22387: - Attachment: test-cluster-configuration-details.png > Evaluate the get/scan performance after reading

[jira] [Updated] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22387: - Attachment: G1GC-stage-stw.case01.png > Evaluate the get/scan performance after reading HFile block

[jira] [Updated] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22387: - Attachment: G1GC-stw.case01.png > Evaluate the get/scan performance after reading HFile block into

[jira] [Commented] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849461#comment-16849461 ] Zheng Hu commented on HBASE-22387: -- bq. In some other issue I was trying to even get rid of this. We

[jira] [Commented] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849446#comment-16849446 ] Zheng Hu commented on HBASE-22387: -- bq. Did u config the SCR correctly in RS and DN side? The RS could

[jira] [Commented] (HBASE-22480) Get block from BlockCache once and return this block to BlockCache twice make ref count error.

[ https://issues.apache.org/jira/browse/HBASE-22480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849298#comment-16849298 ] Zheng Hu commented on HBASE-22480: -- There're several place where we did not consider the release or

[jira] [Commented] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849294#comment-16849294 ] Zheng Hu commented on HBASE-22463: -- After run about 12 hours in my test cluster with patch.v4, the

[jira] [Updated] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22463: - Attachment: allocation-after-running-12h-with-patch-v4.png > Some paths in HFileScannerImpl did not

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849286#comment-16849286 ] Zheng Hu commented on HBASE-22422: -- Pushed to HBASE-21879 branch, Thanks [~Apache9] & [~ram_krish] for

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) >

[jira] [Updated] (HBASE-22483) Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22483: - Description: There're some reason why it's better to choose 64KB as the default buffer size: 1. Almost

[jira] [Updated] (HBASE-22483) Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22483: - Description: There're some reason why it's better to choose 64KB as the default buffer size: 1. Almost

[jira] [Updated] (HBASE-22483) Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22483: - Attachment: BucketCacheWriter-is-busy.png > Maybe it's better to use 65KB as the default buffer size in

[jira] [Commented] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848989#comment-16848989 ] Zheng Hu commented on HBASE-22387: -- I found anther problem : seems always use the BlockReaderRemote to

[jira] [Updated] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22387: - Attachment: blockReaderRemote.png > Evaluate the get/scan performance after reading HFile block into

[jira] [Commented] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848982#comment-16848982 ] Zheng Hu commented on HBASE-22387: -- I caught a jstack (see

[jira] [Updated] (HBASE-22387) Evaluate the get/scan performance after reading HFile block into offheap directly

[ https://issues.apache.org/jira/browse/HBASE-22387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22387: - Attachment: blocksByHFile-stack-trace.png > Evaluate the get/scan performance after reading HFile block

[jira] [Updated] (HBASE-22483) Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22483: - Attachment: 121240.stack > Maybe it's better to use 65KB as the default buffer size in

[jira] [Updated] (HBASE-22483) Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22483: - Description: There're some reason why it's better to choose 64KB as the default buffer size: 1.

[jira] [Updated] (HBASE-22483) Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22483: - Description: There're some reason why it's better to choose 64KB as the default buffer size: 1.

[jira] [Updated] (HBASE-22483) Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22483: - Description: There're some reason why it's better to choose 64KB as the default buffer size: 1.

[jira] [Updated] (HBASE-22483) Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22483: - Description: There're some reason why it's better to choose 64KB as the default buffer size: 1.

[jira] [Updated] (HBASE-22483) Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22483: - Attachment: checksum-stacktrace.png > Maybe it's better to use 65KB as the default buffer size in

[jira] [Created] (HBASE-22483) Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator

Zheng Hu created HBASE-22483: Summary: Maybe it's better to use 65KB as the default buffer size in ByteBuffAllocator Key: HBASE-22483 URL: https://issues.apache.org/jira/browse/HBASE-22483 Project: HBase

[jira] [Updated] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22463: - Attachment: HBASE-22463.HBASE-21879.v4.patch > Some paths in HFileScannerImpl did not consider

[jira] [Updated] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22463: - Attachment: HBASE-22463.HBASE-21879.v3.patch > Some paths in HFileScannerImpl did not consider

[jira] [Commented] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848854#comment-16848854 ] Zheng Hu commented on HBASE-22463: -- After applied the patch.v2 in my test cluster, the usedBufferCount

[jira] [Updated] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22463: - Attachment: allocation-after-applied-patch-v2.png > Some paths in HFileScannerImpl did not consider

[jira] [Commented] (HBASE-22480) Get block from BlockCache once and return this block to BlockCache twice make ref count error.

[ https://issues.apache.org/jira/browse/HBASE-22480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848814#comment-16848814 ] Zheng Hu commented on HBASE-22480: -- Could we simplify the patch as the above I attached before ?

[jira] [Commented] (HBASE-22480) Get block from BlockCache once and return this block to BlockCache twice make ref count error.

[ https://issues.apache.org/jira/browse/HBASE-22480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848768#comment-16848768 ] Zheng Hu commented on HBASE-22480: -- [~aoxiang], Nice finding, Thanks for your work. I'm also working

[jira] [Comment Edited] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848724#comment-16848724 ] Zheng Hu edited comment on HBASE-22463 at 5/27/19 8:38 AM: --- Upload the

[jira] [Updated] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22463: - Attachment: use-share-type-memory.png > Some paths in HFileScannerImpl did not consider block#release

[jira] [Comment Edited] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848724#comment-16848724 ] Zheng Hu edited comment on HBASE-22463 at 5/27/19 8:35 AM: --- Upload the

[jira] [Commented] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848724#comment-16848724 ] Zheng Hu commented on HBASE-22463: -- Upload the patch.v2 to address the unreleased block issue.  > Some

[jira] [Updated] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22463: - Attachment: HBASE-22463.HBASE-21879.v2.patch > Some paths in HFileScannerImpl did not consider

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Status: Patch Available (was: Open) > Retain an ByteBuff with refCnt=0 when getBlock from LRUCache >

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Attachment: HBASE-22422.HBASE-21879.v02.patch > Retain an ByteBuff with refCnt=0 when getBlock from

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848024#comment-16848024 ] Zheng Hu commented on HBASE-22422: -- Upload a picture to show the current YCSB result ( see

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Attachment: HBASE-22422-qps-after-fix-the-zero-retain-bug.png > Retain an ByteBuff with refCnt=0 when

[jira] [Commented] (HBASE-15867) Move HBase replication tracking from ZooKeeper to HBase

[ https://issues.apache.org/jira/browse/HBASE-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16848020#comment-16848020 ] Zheng Hu commented on HBASE-15867: -- [~xucang], Thanks for your attention. For this feature, the core

[jira] [Updated] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22463: - Attachment: HBASE-22463.HBASE-21879.v1.patch > Some paths in HFileScannerImpl did not consider

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847199#comment-16847199 ] Zheng Hu commented on HBASE-22422: -- Data block reading failure will lead to an extra index-block

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847185#comment-16847185 ] Zheng Hu commented on HBASE-22422: -- Understand now, it's a cnocurrent bug in RAMCache, say if thread1

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847172#comment-16847172 ] Zheng Hu commented on HBASE-22422: -- After running some hours, the bug reproduced in my pressure

[jira] [Commented] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846732#comment-16846732 ] Zheng Hu commented on HBASE-22463: -- Upload an initial patch.v1, will provide UT in the next version.

[jira] [Updated] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22463: - Attachment: HBASE-22463.HBASE-21879.v1.patch > Some paths in HFileScannerImpl did not consider

[jira] [Updated] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22463: - Attachment: HBASE-22463.HBASE-21879.v1.patch > Some paths in HFileScannerImpl did not consider

[jira] [Created] (HBASE-22463) Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator

Zheng Hu created HBASE-22463: Summary: Some paths in HFileScannerImpl did not consider block#release which will exhaust the ByteBuffAllocator Key: HBASE-22463 URL: https://issues.apache.org/jira/browse/HBASE-22463

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846593#comment-16846593 ] Zheng Hu commented on HBASE-22422: -- Attached the debug4 as said above, let's see what happen in my

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Attachment: 0001-debug4.patch > Retain an ByteBuff with refCnt=0 when getBlock from LRUCache >

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846518#comment-16846518 ] Zheng Hu commented on HBASE-22422: -- The bug never happened since applied debug3.patch, it's some

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Attachment: HBASE-22422.HBASE-21879.v01.patch > Retain an ByteBuff with refCnt=0 when getBlock from

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Attachment: (was: HBASE-22422.HBASE-21879.v1.patch) > Retain an ByteBuff with refCnt=0 when

[jira] [Resolved] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu resolved HBASE-22448. -- Resolution: Won't Fix > Scan is slow for Multiple Column prefixes >

[jira] [Commented] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846481#comment-16846481 ] Zheng Hu commented on HBASE-22448: -- Hi, [~Karthick], There's a very nice suggestion from

[jira] [Commented] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846406#comment-16846406 ] Zheng Hu commented on HBASE-22448: -- For a cell , we either have a comparision with the preivous next

[jira] [Comment Edited] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846396#comment-16846396 ] Zheng Hu edited comment on HBASE-22448 at 5/23/19 3:25 AM: --- To show the

[jira] [Comment Edited] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846396#comment-16846396 ] Zheng Hu edited comment on HBASE-22448 at 5/23/19 3:07 AM: --- To show the

[jira] [Updated] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22448: - Attachment: (was: filter-list-with-or-internal.png) > Scan is slow for Multiple Column prefixes >

[jira] [Comment Edited] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846396#comment-16846396 ] Zheng Hu edited comment on HBASE-22448 at 5/23/19 3:05 AM: --- To show the

[jira] [Commented] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846396#comment-16846396 ] Zheng Hu commented on HBASE-22448: -- To show the desgin, I draw a picture (see

[jira] [Updated] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22448: - Attachment: filter-list-with-or-internal-2.png > Scan is slow for Multiple Column prefixes >

[jira] [Updated] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22448: - Attachment: filter-list-with-or-internal.png > Scan is slow for Multiple Column prefixes >

[jira] [Commented] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845901#comment-16845901 ] Zheng Hu commented on HBASE-22448: -- Thanks for your work [~ram_krish]. Yeah, I think its here: {code}

[jira] [Updated] (HBASE-22435) Add a UT to address the HFileBlock#heapSize() in TestHeapSize

[ https://issues.apache.org/jira/browse/HBASE-22435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22435: - Resolution: Fixed Assignee: Zheng Hu Hadoop Flags: Reviewed Status: Resolved

[jira] [Commented] (HBASE-22435) Add a UT to address the HFileBlock#heapSize() in TestHeapSize

[ https://issues.apache.org/jira/browse/HBASE-22435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845611#comment-16845611 ] Zheng Hu commented on HBASE-22435: -- Addressed [~ram_krish] 's comment and pushed to HBASE-21879

[jira] [Commented] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845584#comment-16845584 ] Zheng Hu commented on HBASE-22448: -- bq. Is it because of the changes did in AND/ OR FilterList (For the

[jira] [Commented] (HBASE-22412) Improve the metrics in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845580#comment-16845580 ] Zheng Hu commented on HBASE-22412: -- bq. Now in UI it says the heap allocation ration is 100%. I think

[jira] [Commented] (HBASE-22412) Improve the metrics in ByteBuffAllocator

[ https://issues.apache.org/jira/browse/HBASE-22412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845577#comment-16845577 ] Zheng Hu commented on HBASE-22412: -- > Also it would be good to show the number of heap allocations

[jira] [Commented] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845489#comment-16845489 ] Zheng Hu commented on HBASE-22448: -- I run the benchmark-UT in my branch-1.2 (rev-id: af250d2). OK,

[jira] [Commented] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845481#comment-16845481 ] Zheng Hu commented on HBASE-22448: -- [~KarthickRam], Thanks for your report. I created a benchmark UT

[jira] [Updated] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22448: - Attachment: 0001-benchmark-UT.patch > Scan is slow for Multiple Column prefixes >

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845433#comment-16845433 ] Zheng Hu commented on HBASE-22422: -- After runing about 12 hours in my pressure cluster, still no

[jira] [Updated] (HBASE-22435) Add a UT to address the HFileBlock#heapSize() in TestHeapSize

[ https://issues.apache.org/jira/browse/HBASE-22435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22435: - Status: Patch Available (was: Open) > Add a UT to address the HFileBlock#heapSize() in TestHeapSize >

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844851#comment-16844851 ] Zheng Hu commented on HBASE-22422: -- I've applied the debug3.patch into my test cluster, still waiting

[jira] [Updated] (HBASE-22435) Add a UT to address the HFileBlock#heapSize() in TestHeapSize

[ https://issues.apache.org/jira/browse/HBASE-22435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22435: - Attachment: HBASE-22435.HBASE-21879.v2.patch > Add a UT to address the HFileBlock#heapSize() in

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Attachment: 0001-debug3.patch > Retain an ByteBuff with refCnt=0 when getBlock from LRUCache >

[jira] [Assigned] (HBASE-22448) Scan is slow for Multiple Column prefixes

[ https://issues.apache.org/jira/browse/HBASE-22448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu reassigned HBASE-22448: Assignee: Zheng Hu > Scan is slow for Multiple Column prefixes >

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Attachment: 0001-debug2.patch > Retain an ByteBuff with refCnt=0 when getBlock from LRUCache >

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Attachment: 0001-debug2.patch > Retain an ByteBuff with refCnt=0 when getBlock from LRUCache >

[jira] [Updated] (HBASE-22435) Add a UT to address the HFileBlock#heapSize() in TestHeapSize

[ https://issues.apache.org/jira/browse/HBASE-22435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22435: - Attachment: HBASE-22435.HBASE-21879.v1.patch > Add a UT to address the HFileBlock#heapSize() in

[jira] [Commented] (HBASE-21620) Problem in scan query when using more than one column prefix filter in some cases.

[ https://issues.apache.org/jira/browse/HBASE-21620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844693#comment-16844693 ] Zheng Hu commented on HBASE-21620: -- OK. Mind to open an seperate issue for this ? I will take some

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844564#comment-16844564 ] Zheng Hu commented on HBASE-22422: -- Update the patch with debug2.patch, which only LOG the non-data

[jira] [Updated] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22422: - Attachment: 0001-debug2.patch > Retain an ByteBuff with refCnt=0 when getBlock from LRUCache >

[jira] [Commented] (HBASE-22422) Retain an ByteBuff with refCnt=0 when getBlock from LRUCache

[ https://issues.apache.org/jira/browse/HBASE-22422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844541#comment-16844541 ] Zheng Hu commented on HBASE-22422: -- After applied the debug.patch, seems it's easy to full gc and

<    1   2   3   4   5   6   7   8   9   10   >