[ https://issues.apache.org/jira/browse/AMBARI-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15716654#comment-15716654 ]
Hudson commented on AMBARI-18936: --------------------------------- FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6144 (See [https://builds.apache.org/job/Ambari-trunk-Commit/6144/]) AMBARI-18936. DataNode JVM heap settings should include (smohanty: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=0c837a60c6bbe7c6fb7c5586963520957bb4146f]) * (add) ambari-server/src/main/resources/stacks/HDP/2.4/services/HDFS/configuration/hadoop-env.xml > DataNode JVM heap settings should include CMSInitiatingOccupancy > ---------------------------------------------------------------- > > Key: AMBARI-18936 > URL: https://issues.apache.org/jira/browse/AMBARI-18936 > Project: Ambari > Issue Type: Improvement > Affects Versions: 2.2.2 > Reporter: Arpit Agarwal > Assignee: Arpit Agarwal > Fix For: 2.5.0 > > Attachments: AMBARI-18936.02.patch > > > This is a followup to AMBARI-18694 to fix remaining stack versions: > ___________________________ > As HDFS-11047 reported, DirectoryScanner does scan by deep copying > FinalizedReplica. In a deployment with 500,000+ blocks, we've seen the DN > heap usage being accumulated to high peaks very quickly. Deep copies of > FinalizedReplica will make DN heap usage even worse if directory scans are > scheduled more frequently. > Another factor is that huge number of ScanInfo instances corresponding to > HDFS blocks are lingering in garbage to eat many heap memories until a full > GC takes place. > This proposes adding JVM settings to force GC more frequently to release > DataNode heap consumed as a result of two aforementioned reasons, i.e. add > the options to HADOOP_DATANODE_OPTS > {noformat} > -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly > -XX:ConcGCThreads=8 -XX:+UseConcMarkSweepGC > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)