CC00063.hadoop——|Hadoop&MapReduce.V34|——|Hadoop.v34|NamenodeFullGC-FullGC的影响|

已于 2022-04-09 23:19:02 修改
阅读量261 收藏 1
点赞数
分类专栏： bigdatav006——hadoop.v001 文章标签： java jvm hadoop 大数据 python
于 2022-04-07 14:23:00 首次发布
不予转载
本文链接：https://blog.csdn.net/yanqi_vip/article/details/124031139
版权
一、Namenode Full GC 
~~~     [NamenodeFullGC-FullGC的影响]                                                                                  
~~~     [NamenodeFullGC-FullGC的日志分析]
二、JVM堆内存 
### --- JVM堆内存
~~~     JVM内存划分为堆内存和非堆内存，堆内存分为年轻代(Young Generation)、
~~~     老年代(OldGeneration)，非堆内存就一个永久代(Permanent Generation)。
~~~     年轻代又分为Eden和Survivor区。Survivor区由FromSpace和ToSpace组成。
~~~     Eden区占大容量，Survivor两个区占小容量，默认比例是8:1:1。
~~~     堆内存用途：存放的是对象，垃圾收集器就是收集这些对象，然后根据GC算法回收。
~~~     非堆内存用途：永久代，也称为方法区，存储程序运行时长期存活的对象，
~~~     比如类的元数据、方法、常量、属性等。

### --- 补充：
~~~     JDK1.8版本废弃了永久代，替代的是元空间(MetaSpace)，元空间与永久代上类似，
~~~     都是方法区的实现，他们最大区别是：元空间并不在JVM中，而是使用本地内存。
三、对象分代 
### --- 对象分代

~~~     新生成的对象首先放到年轻代Eden区，
~~~     当Eden空间满了，触发Minor GC，存活下来的对象移动到Survivor0区，
~~~     Survivor0区满后触发执行Minor GC，Survivor0区存活对象移动到Suvivor1区，
~~~     这样保证了一段时间内总有一个survivor区为空。
~~~     经过多次Minor GC仍然存活的对象移动到老年代。
~~~     老年代存储长期存活的对象，占满时会触发Major GC(Full GC)，
~~~     GC期间会停止所有线程等待GC完成，所以对响应要求高的应用尽量减少发生Major GC，避免响应超时。
~~~     Minor GC ： 清理年轻代
~~~     Major GC(Full GC) ： 清理老年代，清理整个堆空间，会停止应用所有线程。
四、Jstat 
### --- 查看当前jvm内存使用以及垃圾回收情况

[root@linux121 ~]# jps
8960 NameNode
### --- 显示pid是58563的垃圾回收堆的行为统计

[root@linux121 ~]# jstat -gc -t 8960 1s             
Timestamp        S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
         1489.6 2240.0 2240.0 1003.8  0.0   17984.0   8890.8   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1490.6 2240.0 2240.0 1003.8  0.0   17984.0   8890.8   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1491.6 2240.0 2240.0 1003.8  0.0   17984.0   8890.8   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1492.6 2240.0 2240.0 1003.8  0.0   17984.0   8973.3   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1493.6 2240.0 2240.0 1003.8  0.0   17984.0   8980.4   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1494.6 2240.0 2240.0 1003.8  0.0   17984.0   8980.4   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1495.6 2240.0 2240.0 1003.8  0.0   17984.0   8980.4   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1496.6 2240.0 2240.0 1003.8  0.0   17984.0   9021.4   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1497.6 2240.0 2240.0 1003.8  0.0   17984.0   9021.4   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1498.6 2240.0 2240.0 1003.8  0.0   17984.0   9025.0   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1499.6 2240.0 2240.0 1003.8  0.0   17984.0   9025.1   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1500.6 2240.0 2240.0 1003.8  0.0   17984.0   9025.1   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1501.6 2240.0 2240.0 1003.8  0.0   17984.0   9058.0   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1502.6 2240.0 2240.0 1003.8  0.0   17984.0   9058.0   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
         1503.6 2240.0 2240.0 1003.8  0.0   17984.0   9061.5   44796.0    31671.0   41392.0 40564.9 5040.0 4843.1     36    0.371   2      0.414    0.785
### --- 结果解释：
~~~     # C即Capacity 总容量，U即Used 已使用的容量

S0C:        //  当前survivor0区容量(kB)。
S1C:        //  当前survivor1区容量(kB)。
S0U:        //  survivor0区已使用的容量(KB)
S1U:        //  survivor1区已使用的容量(KB)
EC:         //  Eden区的总容量(KB)
EU:         //  当前Eden区已使用的容量(KB)
OC:         //  Old空间容量(kB)。
OU:         //  Old区已使用的容量(KB)
MC:         //  Metaspace空间容量(KB)
MU:         //  Metacspace使用量(KB)
CCSC:       //  压缩类空间容量(kB)。
CCSU:       //  压缩类空间使用(kB)。
YGC:        //  新生代垃圾回收次数
YGCT:       //  新生代垃圾回收时间
FGC:        //  老年代 full GC垃圾回收次数
FGCT:       //  老年代垃圾回收时间
GCT:        //  垃圾回收总消耗时间
### --- 开启HDFS GC详细日志输出
~~~     编辑hadoop-env.sh

[root@linux121 ~]# vim /opt/yanqi/servers/hadoop-2.9.2/etc/hadoop/hadoop-env.sh
export HADOOP_LOG_DIR=/hadoop/logs/
### --- 增加JMX配置打印详细GC信息
~~~     指定一个日志输出目录；注释掉之前的ops
~~~     增加新的打印配置

[root@linux121 ~]# vim /opt/yanqi/servers/hadoop-2.9.2/etc/hadoop/hadoop-env.sh 
# JMX配置

export HADOOP_JMX_OPTS="-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"


export HADOOP_NAMENODE_OPTS="-Dhadoop.security.logger=${HADOOP_SECURITY_LOGGER:-INFO,RFAS} -Dhdfs.audit.logger=${HDFS_AUDIT_LOGGER:-INFO,NullAppender}$HADOOP_NAMENODE_OPTS"
export HADOOP_DATANODE_OPTS="-Dhadoop.security.logger=ERROR,RFAS$HADOOP_DATANODE_OPTS"
export NAMENODE_OPTS="-verbose:gc -XX:+PrintGCDetails -Xloggc:${HADOOP_LOG_DIR}/logs/hadoop-gc.log \
-XX:+PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime \
-server -Xms150g -Xmx150g -Xmn20g -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 \
-XX:ParallelGCThreads=18 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:+DisableExplicitGC -XX:+CMSParallelRemarkEnabled \
-XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSMaxAbortablePrecleanTime=5000 \
-XX:+UseGCLogFileRotation -XX:GCLogFileSize=20m -XX:ErrorFile=${HADOOP_LOG_DIR}/logs/hs_err.log.%p -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${HADOOP_LOG_DIR}/logs/%p.hprof\
"

export DATENODE_OPTS="-verbose:gc -XX:+PrintGCDetails -Xloggc:${HADOOP_LOG_DIR}/hadoop-gc.log \
-XX:+PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime \
-server -Xms15g -Xmx15g -Xmn4g -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15\
-XX:ParallelGCThreads=18 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:+DisableExplicitGC -XX:+CMSParallelRemarkEnabled \
-XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSMaxAbortablePrecleanTime=5000 \
-XX:+UseGCLogFileRotation -XX:GCLogFileSize=20m -XX:ErrorFile=${HADOOP_LOG_DIR}/logs/hs_err.log.%p -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${HADOOP_LOG_DIR}/logs/%p.hprof\
"

export HADOOP_NAMENODE_OPTS="$NAMENODE_OPTS $HADOOP_NAMENODE_OPTS"
export HADOOP_DATANODE_OPTS="$DATENODE_OPTS $HADOOP_DATANODE_OPTS"
~~~     -Xms150g -Xmx150g ：堆内存大小最大和最小都是150g
~~~     -Xmn20g ：新生代大小为20g，等于eden+2*survivor，意味着老年代为150-20=130g。
~~~     -XX:SurvivorRatio=8 ：Eden和Survivor的大小比值为8，意味着两个Survivor区和一个Eden区的比值为2：8，一个Survivor占整个年轻代的1/10
~~~     -XX:ParallelGCThreads=10 ：设置ParNew GC的线程并行数，默认为8 +(Runtime.availableProcessors - 8) * 5/8 ，24核机器为18。
~~~     -XX:MaxTenuringThreshold=15 ：设置对象在年轻代的最大年龄，超过这个年龄则会晋升到老年代
~~~     -XX:+UseParNewGC ：设置新生代使用Parallel New GC
~~~     -XX:+UseConcMarkSweepGC ：设置老年代使用CMS GC，当此项设置时候自动设置新生代为ParNew GC
~~~     -XX:CMSInitiatingOccupancyFraction=70 ：老年代第一次占用达到该百分比时候，就会引发CMS的第一次垃圾回收周期。后继CMS GC由HotSpot自动优化计算得到。
五、GC 日志解析 
### --- 日志解析：jstat命令输出

[root@linux121 ~]# jstat -gc -t 8960 1s
Timestamp        S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
         2865.7 2240.0 2240.0  0.0   295.9  17984.0   8002.0   44796.0    31671.0   41392.0 40672.3 5040.0 4845.9     37    0.376   2      0.414    0.791
         2866.7 2240.0 2240.0  0.0   295.9  17984.0   8018.1   44796.0    31671.0   41392.0 40672.3 5040.0 4845.9     37    0.376   2      0.414    0.791
         2867.8 2240.0 2240.0  0.0   295.9  17984.0   8033.4   44796.0    31671.0   41392.0 40672.3 5040.0 4845.9     37    0.376   2      0.414    0.791
         2868.8 2240.0 2240.0  0.0   295.9  17984.0   8033.4   44796.0    31671.0   41392.0 40672.3 5040.0 4845.9     37    0.376   2      0.414    0.791
         2869.7 2240.0 2240.0  0.0   295.9  17984.0   8040.5   44796.0    31671.0   41392.0 40672.3 5040.0 4845.9     37    0.376   2      0.414    0.791
         2870.8 2240.0 2240.0  0.0   295.9  17984.0   8040.5   44796.0    31671.0   41392.0 40672.3 5040.0 4845.9     37    0.376   2      0.414    0.791
         2871.8 2240.0 2240.0  0.0   295.9  17984.0   8040.5   44796.0    31671.0   41392.0 40672.3 5040.0 4845.9     37    0.376   2      0.414    0.791
### --- 查看GC日志输出

3.157: [GC (Allocation Failure) 3.157: [ParNew: 272640K->34048K(306688K),0.0844702 secs] 272640K->69574K(2063104K), 0.0845560 secs] [Times: user=0.23sys=0.03, real=0.09 secs]
4.092: [GC (Allocation Failure) 4.092: [ParNew: 306688K->34048K(306688K),0.1013723 secs] 342214K->136584K(2063104K), 0.1014307 secs] [Times: user=0.25sys=0.05, real=0.10 secs]
... cut for brevity ...
11.292: [GC (Allocation Failure) 11.292: [ParNew: 306686K->34048K(306688K),0.0857219 secs] 971599K->779148K(2063104K), 0.0857875 secs] [Times: user=0.26sys=0.04, real=0.09 secs]
12.140: [GC (Allocation Failure) 12.140: [ParNew: 306688K->34046K(306688K),0.0821774 secs] 1051788K->856120K(2063104K), 0.0822400 secs] [Times: user=0.25sys=0.03, real=0.08 secs]
12.989: [GC (Allocation Failure) 12.989: [ParNew: 306686K->34048K(306688K),0.1086667 secs] 1128760K->931412K(2063104K), 0.1087416 secs] [Times: user=0.24sys=0.04, real=0.11 secs]
13.098: [GC (CMS Initial Mark) [1 CMS-initial-mark: 897364K(1756416K)]936667K(2063104K), 0.0041705 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
13.102: [CMS-concurrent-mark-start]
13.341: [CMS-concurrent-mark: 0.238/0.238 secs] [Times: user=0.36 sys=0.01,real=0.24 secs]
13.341: [CMS-concurrent-preclean-start]
13.350: [CMS-concurrent-preclean: 0.009/0.009 secs] [Times: user=0.03 sys=0.00,real=0.01 secs]
13.350: [CMS-concurrent-abortable-preclean-start]
13.878: [GC (Allocation Failure) [ParNew: 16844397K->85085K(18874368K),0.0960456 secs]116885867K->100127390K(155189248K), 0.0961542 secs] [Times: user=0.14 sys=0.00,real=0.05 secs]
14.366: [CMS-concurrent-abortable-preclean: 0.917/1.016 secs] [Times: user=2.22sys=0.07, real=1.01 secs]
14.366: [GC (CMS Final Remark) [YG occupancy: 182593 K (306688 K)]14.366:[Rescan (parallel) , 0.0291598 secs]14.395: [weak refs processing, 0.0000232secs]14.395: [class unloading, 0.0117661 secs]14.407: [scrub symbol table,0.0015323 secs]14.409: [scrub string table, 0.0003221 secs][1 CMS-remark:976591K(1756416K)] 1159184K(2063104K), 0.0462010 secs] [Times: user=0.14sys=0.00, real=0.05 secs]
14.412: [CMS-concurrent-sweep-start]
14.633: [CMS-concurrent-sweep: 0.221/0.221 secs] [Times: user=0.37 sys=0.00,real=0.22 secs]
14.633: [CMS-concurrent-reset-start]
14.636: [CMS-concurrent-reset: 0.002/0.002 secs] [Times: user=0.00 sys=0.00,real=0.00 secs]
~~~     # ParNew: 16844397K->85085K(18874368K), 0.0960456 secs
~~~     其中， 16844397K 表示GC前的新生代占用量， 85085K 表示GC后的新生代占用量，
~~~     GC后Eden和一个Survivor为空，所以85085K 也是另一个Survivor的占用量。
~~~     括号中的18874368K 是Eden+一个被占用Survivor的总和(18g)。

~~~     # 116885867K->100127390K(155189248K), 0.0961542 secs
~~~     其中，分别是Java堆在垃圾回收前后的大小，和Java堆大小。
~~~     说明堆使用为116885867K=111.47g，回收大小为100127390K=95.49g，
~~~     堆大小为155189248K=148g(去掉其中一个Survivor)，回收了16g空间.
### --- 总结：

~~~     在HDFS Namenode内存中的对象大都是文件，目录和blocks，
~~~     这些数据只要不被程序或者数据的拥有者人为的删除，
~~~     就会在Namenode的运 行生命期内一直存在，所以这些对象通常是存在在old区中，
~~~     所以，如果整个hdfs文件和目录数多，blocks数也多，内存数据也会很大，
~~~     如何降低Full GC的影响？
六、计算NN所需的内存大小，合理配置JVM 
### --- 使用低卡顿G1收集器

~~~     # 为什么会有G1呢？
~~~     因为并发、并行和CMS垃圾收集器都有2个共同的问题：
~~~     老年代收集器大部分操作都必须扫描整个老年代空间(标记，清除和压缩)。
~~~     这就导致了GC随着Java堆空间而线性增加或减少
~~~     年轻代和老年代是独立的连续内存块，所以要先决定年轻代和年老代放在虚拟地址空间的位置
~~~     G1垃圾收集器利用分而治之的思想将堆进行分区，划分为一个个的区域。
~~~     G1垃圾收集器将堆拆成一系列的分区，这样的话，大部分的垃圾收集操作就只在一个分区内执行，
~~~     从而避免很多GC操作在整个Java堆或者整个年轻代进行。
### --- 编辑hadoop-env.sh
~~~     注意：如果现在采用的垃圾收集器没有问题，就不要选择G1，如果追求低停顿，可以尝试使用G1

[root@linux122 ~]# vim hadoop-env.sh 
export HADOOP_NAMENODE_OPTS="-server -Xmx220G -Xms200G -XX:+UseG1GC -
XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -
XX:+ParallelRefProcEnabled -XX:-ResizePLAB -XX:+PerfDisableSharedMem -
XX:-OmitStackTraceInFastThrow -XX:G1NewSizePercent=2 -XX:ParallelGCThreads=23 -
XX:InitiatingHeapOccupancyPercent=40 -XX:G1HeapRegionSize=32M -
XX:G1HeapWastePercent=10 -XX:G1MixedGCCountTarget=16 -verbose:gc -
XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -
XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=100M -
Xloggc:/var/log/hbase/gc.log -Dhadoop.security.logger=${HADOOP_SECURITY_LOGGER:-INFO,RFAS} -Dhdfs.audit.logger=${HDFS_AUDIT_LOGGER:-INFO,NullAppender}$HADOOP_NAMENODE_OPTS"
yanqi_vip
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
Hadoop HA --- 网络原因/NN Full GC造成集群故障
liuguoxiang815116的博客
07-20 1074
Hadoop HA — 网络原因/NN Full GC造成集群故障1 问题描述简单描述一下问题，集群为Hadoop HDFS HA模式，三个节点104、105、106，由于三个节点的时间不同，以105时间为标准。2017-07-08 01:45分左右，集群出现故障。2 日志信息105 NN 日志如下： 105 DN日志如下： 104 JN日志如下： 105 JN日志如下： 106 JN日志如
hadoop Federation（联邦）简介
学习笔记
05-31 1万+
在hadoop1.x中HDFS的架构文件的存储是放在块上的（Block Storage） 文件的元数据是放在namenode上的，只有一个Namespace（命名空间）。随着HDFS的数据越来越多，单个namenode的资源使用必然会达到上限，而且namenode的负载能力也会越来越高，限制HDFS的性能。hdfs主要有两层架构： 1.命名空间（namespace） 由目录、文件、块组成。
namenode gc故障及解决办法记录
weixin_33913332的博客
06-01 553
问题：WARN org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager: Waited 19016 ms (timeout=20000 ms) for a response for sendEdits. Succeeded so far: [10.80.248.17:8486] namenode gc overhead limit e...
触发Full GC执行的情况
whsq1987的博客
02-27 152
  引自 http://blog.sina.com.cn/s/blog_7a351012010163a1.html 除直接调用System.gc外，触发Full GC执行的情况有如下四种。 1. 旧生代空间不足 旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误： java.lang.OutOfMemoryEr...
Hadoop原理-NameNode源码BUG
weixin_40503364的博客
05-31 183
1 Namenode Full GC导致进程异常退出BUG NameNode瞬时高并发导致短暂不可用 NameNode full GC导致集群异常退出bug NameNode写元数据到journalnode超时会导致Namenode进程异常退出 源码处理方式 journalnode传输后20s没有收到超过半数节点响应，代表数据传输失败，程序会自动停止active namenode进程 但是当发生full GC超过30秒则会发生异常退出，很多平时超时则停止的程序都会存在full GC导致异常退出问题 jo
hadoop-mapreduce-client-jobclient-2.6.5-API文档-中文版.zip
05-01
赠送jar包：hadoop-mapreduce-client-jobclient-2.6.5.jar； 赠送原API文档：hadoop-mapreduce-client-jobclient-2.6.5-javadoc.jar； 赠送源代码：hadoop-mapreduce-client-jobclient-2.6.5-sources.jar； 赠送...
hadoop-mapreduce-client-core-2.5.1-API文档-中文版.zip
04-23
赠送jar包：hadoop-mapreduce-client-core-2.5.1.jar； 赠送原API文档：hadoop-mapreduce-client-core-2.5.1-javadoc.jar； 赠送源代码：hadoop-mapreduce-client-core-2.5.1-sources.jar； 赠送Maven依赖信息文件：...
hadoop-3.1.1.3.1.4.0-315.tar.gz
10-11
ambari-2.7.5 编译过程中四个大包下载很慢，所以需要提前下载，包含：hbase-2.0.2.3.1.4.0-315-bin.tar.gz ，hadoop-3.1.1.3.1.4.0-315.tar.gz ， grafana-6.4.2.linux-amd64.tar.gz ，phoenix-5.0.0.3.1.4.0-315....
hadoop-mapreduce-examples-2.7.1.jar
06-03
hadoop-mapreduce-examples-2.7.1.jar
hadoop-mapreduce-client-common-2.6.5-API文档-中英对照版.zip
04-19
赠送jar包：hadoop-mapreduce-client-common-2.6.5.jar； 赠送原API文档：hadoop-mapreduce-client-common-2.6.5-javadoc.jar； 赠送源代码：hadoop-mapreduce-client-common-2.6.5-sources.jar； 赠送Maven依赖信息...
hbase full gc问题解决
vah101的专栏
04-04 9070
2014-03-30 20:53:09,137 WARN org.apache.hadoop.hbase.util.Sleeper: We slept 49879ms instead of 10000ms, this is likely due to a long garbage collecting pause and it's usually bad, see http://hbase.apa
触发FullGC的几个条件
渣渣想逆袭
04-09 2597
1.年轻代存活的对象太多,老年代了放不下 01.示例代码 public class DemoTest1 { public static void main(String[] args) { byte[] array1 = new byte[4 * 1024 * 1024]; array1 = null; ​ byte[] array2 ...
MapReduce中FULLGC的问题
warden的博客
05-20 270
MapReduce中FULLGC的问题问题描述 问题描述 我在集群上将近好几T的数据需要遍历一遍，然后过滤出我想要的数据。我本来以为是一个简单的事情，没想到试了两三天也没有成功。总是会出现超时超内存的问题。 超时的问题可能是一个reduce的量有点太大了。这里我把key值稀疏了一下。但是超内存的问题还是存在。这让我很费解。 今天终于搞明白了在这个地方 ...
fullgc问题解决：Full GC (Metadata GC Threshold)
热门推荐
刘本龙的专栏
09-30 4万+
Full GC (Metadata GC Threshold) jdk8JVM调优 MetaspaceSize元空间配置
一次让人难以忘怀的排查频繁Full GC过程
huaweitman的专栏
03-15 8731
我们的Java应用因频繁FULL GC导致性能降低很多，经过多人的定位也没有结论，于是我自主请命，经过一天的研究终于搞定了，现把经验与大家共享，相关的gc日志如下： 4.758: [Full GC [PSYoungGen: 464K->0K(71936K)] [PSOldGen: 37949K->33994K(68672K)] 38413K->33994K(140608K) [PSPermGen
导致JVM进行Full GC的情况及解决办法
TinnnnnnY
03-07 1万+
堆内存划分为 Eden、Survivor 和 Tenured/Old 空间，如下图所示： 对年轻代（包括 Eden 和 Survivor 区域）进行GC被称为 Minor GC，对老年代进行GC称为Major GC，而Full GC是对整个堆来说的，在最近几个版本的JDK里默认包括了对永生带即方法区的回收（JDK8中无永生带了），出现Full GC的时候经常伴随至少一次的Minor GC,但...
重启hdfs集群的时候，报大量的gc问题。
weixin_34067102的博客
03-11 923
问题现象： 2019-03-11 12:30:52,174 INFO org.apache.hadoop.util.JvmPauseMonitor: Detected pause in JVM or host machine (eg GC): pause of approximately 7653ms GC pool 'ConcurrentMarkSweep' had collection...
一次频繁Full GC的排查过程
沈鸿斌的博客
10-03 1万+
问题描述最近公司的线上监控系统给我推送了一些kafka lag持续增长的消息，我上生产环境去看了相应的consumer的情况，发现几台机器虽然还在处理消息，但是速度明显慢了很多。问题猜测与验证我猜测是JVM频繁做Full GC，导致进程也跟着频繁卡顿，处理消息的速度自然就慢了。为了验证这个想法，先用jstat看看内存使用情况： jstat -gcutil 1 1000 #1是进程号 结果如我所
Unresolved dependency: 'org.apache.hadoop:hadoop-MapReduce-client-core:jar:2.7.7'
最新发布
05-16
这个错误通常是由于缺少依赖项引起的，你需要确保在你的项目中添加了正确的Hadoop依赖项。你可以尝试在你的pom.xml或build.gradle文件中添加以下依赖项： Maven: ```xml <groupId>org.apache.hadoop ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

yanqi_vip

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值