00:00
那么接下来呢,咱们呃列了几个常见的故障,然后给大家讲一下思路啊,其实就是结合咱们前面讲过的一些优化点,还有一些注意事项,第一个呢,Reduce端缓冲大小。要注意控制,以避免OM,他们之前不是优化的时候讲的默认48兆对吧,那我们说数据量特别大,可以适当的调大啊,然后呢,提高它杀Le RA的一个效率,但是呢,如果调的太大,有可能OM这个咱们前面讲过了,每reduce reduce端可能有多个,每一个的你调大的,原来内存就这么小,你现在需要这么大,它也需要这么大,它也需要这么大,那么如果map这一端数据量特别特别的大,你当然能,呃,首先提高的话,能提高它的拉取读取效率没错,但是数据量是不是一下子涌进来了。涌进来是不是一下子也要占用很多很多的执行内存呢?呃,去跑啊,那这个也大,这个也大,那就很容易造成一个reduce的OM,所以其实这个咱们要去。
01:08
呃,均衡对吧,去均衡,你资源足够的再去考虑调啊,不够的话还是掂量掂量自己啊,所以呢,咱们就就是以性能换执行。那咱们要考虑考虑可不可以啊,不然容易OM啊,要先保证能运行再考虑优化。那第二一个TC导致的杀文件拉取失败,这个东西呢,首先咱们前面讲的有可能是什么呢,那个。PC呢,导致那个连接停滞了,停滞了可能就超时了,超时了就失败了,对吧,那从除了提高那个拉取,呃,除了提高那个连接时长之外啊,咱们还可以考虑杀否的重试,那么也是有参参数可以设的啊。IO最大重试对吧,还有wait每次重试的一个间隔,这个咱们之前呢,也是设置过了对吧。
02:06
那同时可以增加那个连接等待时长也可以啊,这是一个思路,这个咱们前面提过的啊,提过的。呃,序列报的错,你就看报错的日志,如果有一个序列的字眼啊,那你就要考虑几个问题了,第一个作为RD的元素。如果是咱们自定义的类型,一定要注意要保证它能序列化,对吧,咱们要去继承一些实现一些序列化的一个接口啊,或者它的一个抽象类啊之类的啊。那么算子函数里面使用的一些外部自定义变量也要注意能不能序列化啊。那有一些东西呢,啊,就要注意了,就这个注意序列化的问题,这个只是做一个提醒,那算子函数返回now值的问题。那我们可以。
03:01
做一些处理,其实就是替换嘛,对吧,比如说替换成一些业务上,或者说对咱们分析没影响的默认值,比如说负一啊零啊空啊这种都可以啊。呃,另外呢,也可以不想替换的,这个数据没有意义,你就过滤掉就行了啊。那既然过滤掉,可能各个分区的数据都有减少呢,咱们就可以去调整分区也可以呢,用那咱们前面3.0的自动合并分区也行,都可以啊都可以,还有一个网卡流量激增的一个问题。这主要是出现在客户端模式下,那么建议呢,咱们还是用class模式啊。因为你用client client的话,Driver在本机。那么driver又需要与进行频繁的通讯,对吧?那么这个时候如果咱们task的数量多,E也多的话,那可能呢?
04:02
就会出现一个流量激增。那这样的话他可能扛不住,所以咱们用C的话,把那个driver单独拎出去的话,呃,就比较好了。嗯,还有一个雅恩克拉斯特模式的JVM占内存。呃,溢出。那这个呢。是跟JVM有关,有一个永久带的大小,如果咱们是用的class模式呢,它那个大小呢。是82兆,那么如果咱们在driver端,他肯他要做什么事呢?首先呢,呃,语义解析啊,就像咱们那个执行计划的转换过程啊,那么这中其实一般也会大这种情况。那如果真的比较大,超过达到了,呃,82小于128的话,小于永久。那么这个时候呢?
05:01
咱们可以去调整JVM的参数配比啊。那这边也有,咱们给出了一个事例,这么调就行了啊,把它改一改。把它的最大值调大一点啊,然后把这个也改成128啊。L巴克森后导致的JVM占内存溢出啊。前面那个问题一般是什么呢?看一出啊,不是堆溢出,占一出可能就出现了递归,那递归呢,一般是因为咱们有or这个关键字。因为它在解析的时候要执行一个递归的执行计划,另外呢,就是咱们只查询的数量不也不要过多,因为这样层级过多对吧,那也可能会粘立出。那一般呢,咱们只查询的数量呢,尽量保证在100个以内,那二的关键字也在100个以内啊,这样的话就会好一点了,这些问题呢,都比较简单啊,那持久化与缺口泡的使用啊。
06:04
容错的考虑,呃,咱们不要单纯用一个catch catch加checkpoint结合使用对吧?Checkpoint有持久化啊,相当于说对它缓存做了一个备份啊,这样会更可靠一点啊。那接下来如果是OM,咱们前面那些都不行,那咱们可以去做一个内存泄露的排查,用一些内存分析工具就可以了。那比如说IBM的这个工具。咱们可以利用它啊,这大家提供一个思路,咱们生成那个he文件,然后呢,用这些工具打开它,可以看到哪些对象占用了咱们大量的一个存储空间。像这样的,大概使用情况就是这样。啊,他会分析每一个对象的占用大小,还有调用都有,那咱们看一看最大的是什么对象,再核对一下代码,那你就知道有啥问题了啊,它就是一个价包就行了,架包咱们去执行就可以了。
07:06
那你也可以,咱们这边也可以模拟对吧,比如说这个代码,咱们创建的一个map。然后呢,疯狂的往里面去溜对象啊,疯狂的利一个对象往里插数据,插数据,那这边溜了10万,然后呢,他慢慢慢慢对象太多了,就溢出了嘛,啊这个时候咱们用这个工具去看的话,就能看到这个对象占量出现了大量啊,数量特别多啊,那我们就定位到可能是他没有及时回收。啊,没有及时回收呢,咱们就知道啊,这个去定位一下它调用的地方,那就知道它的问题了啊,这边是给大家讲一个思路啊,还有一个思路呢,就是如果频繁GC上面咱们也讲了一个。呃,可能的问题对吧,什么增加重试啊,调大连接时长啊,那还有一个咱们可以精准去定位啊,就是要统计G,那要G们程相志加几。
08:09
这是Java参数啊,JM的配置啊,就是打印GC详细日志,就这个,还有打打印时间戳这个不仅仅是Spark,其他的程序都可以这么方式打印GC的日志。那如果是负GC,那一般就是内存问题了啊,一般就内存问题可以去调,其实这个事儿呢,你嗯,你可以结合咱们最前面第二章那个。估算内存那个地方,你估算一下,一般不会有太多问题啊。那如果是年轻代的GC minor GC多的话,那这个时候如果前面估算也没什么问题,你可以调整这个,呃,年轻代的一个内存大小。可以调整一下。另外一个就是建使用万的话,目也比较也比较好,应该来大概不会不会有太多的问题啊,这边是给大家说一下是不简,只是简单带一下啊,简单带一下,因为这些问题,嗯,只能说不是很复杂,就是提供一些思路可能的问题啊。
我来说两句