You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Michael Stack (Jira)" <ji...@apache.org> on 2020/06/02 21:33:00 UTC
[jira] [Commented] (HBASE-24051) When the data directory is set to
EC,the amount of storefiles reaches a relatively high level,heap Occupancy
Percent is above heap occupancy alarm watermark,resulting in frequent gc
and eventual failure
[ https://issues.apache.org/jira/browse/HBASE-24051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124335#comment-17124335 ]
Michael Stack commented on HBASE-24051:
---------------------------------------
Unscheduled for now. Shout if you are up for working on getting this in [~shenshengli] Thanks.
> When the data directory is set to EC,the amount of storefiles reaches a relatively high level,heap Occupancy Percent is above heap occupancy alarm watermark,resulting in frequent gc and eventual failure
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-24051
> URL: https://issues.apache.org/jira/browse/HBASE-24051
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.1
> Reporter: shenshengli
> Assignee: shenshengli
> Priority: Major
> Attachments: 1.png
>
>
> When the data directory is set to EC, during the continuous load process, regionserver is found down ,to view the log:
> regionserver.HeapMemoryManager: heapOccupancyPercent 0.91630864 is now below the heap occupancy alarm watermark (0.95)
> regionserver.HeapMemoryManager: heapOccupancyPercent 0.969546 is above heap occupancy alarm watermark (0.95)
> [JvmPauseMonitor] util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 1254ms
> GC pool 'G1 Young Generation' had collection(s): count=2 time=115ms
> GC pool 'G1 Old Generation' had collection(s): count=1 time=1487ms
> In particular, GC pauses occurred 283 times in half an hour.
> The memory analysis found that most of the memory footprint was generated by HeepByteBuffer,and DFSStripedInputStream produces the HeepByteBuffer
> See HDFS-14308，but after the fix, hbase did not return to normal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)