32-常见故障排除

那最后呢，咱们来聊一聊常见的一个故障排除，常见故障排除这边咱们列了十来个十几个啊。主要是大家经常问到的，经常碰见的，咱们简单聊一聊，第一个就是非法配置异常，如果你看到抛出异常，什么非法的配置异常表明什么存在无效的配置，比如说内存为负。或者说分数大于一的，这个应该很明显，这个比较正常啊，就配置有问题你改就行了啊，这个很明显了，另外一个就是关于内存这一块的啊，咱们第二个到这个第六个都是关于内存这一块的异常，其实很简单，你看堆空间异常。特别是这种oom的问题，你要看一下是哪一块内存超出来了，如果它是堆内存超出来。咱们知道堆内存内存模型，咱们一开始就聊了，堆内存主要是哪几块，是不是一个task堆内，还有框架的堆内啊。是不是这两个超了对吧？那你可以是不是可以尝试着增加，那task怎么增加呢？我们说task克堆上的，它是减人家吃剩下的对吧，吃剩下的那你对应的是不是可以把其他的地方减小一点比例，或者说整体内存给大一点也可以，那框架内存默认128，你可以调大呗，但一般框架内存是不不太需要调的，你把框架内存调大，Task不是更小的嘛，对吧，咱们重点还是考虑task。

好，接下来就是缓冲存储器异常。正常是报这是什么OM，然后呢，你看他报错的是什么director。哎，这一块咱们还是这样，把这张图拿着大家更直观一点，我把它截个图。嗯。好大来看director buffer memory。O了de director是哪一块啊，就是我这边写的直接内存的这一块，它由三部分组成呗，呃，框架对外，它个对外网络缓冲区，那中间这个默认是什么？零上面这个128。

那缓冲区内存默认是flink内存的0.1对不对。0.1啊，那这个时候就说明它不够了呗。对吧。你去知道怎么调了呗，好。再往下圆空间异常，圆空间是哪一个，是不是这个。这个我们说默认值是百二百五十六兆。对吧，256那不够的话，你是不是可以先尝试着把它增加就行了，这个参数指定特别简单，这些都OM，你不要看到OM就慌了，对吧，有什么兵来将挡水来土土土掩嘛，对吧。还有一个网络缓冲区数量不足，他报的是这种错IO异常对吧。他这里很明显说网络缓冲区。不够了。

那这个时候咱们就怎么样增大这一块，还是刚才的道理，它默认不是0.1link内存吗？就扣掉JM这两个之后乘以0.1对吧，那你要么把它系数调大一点。啊，说明你的网络开销还是比较大的，你可以增加一下，另外一个就是比较。难搞的一个超出容器内存异常，咱们说指定内存的时候，一般指定是什么进程，内存就这一块。容器呢？使用的内存就是进程内存，包含了堆内堆外，还有JVM相关的开销，这些通通包含在里面。那么。这个时候他怎么可能还会超出呢？按照咱们内存模型，不是每一块都有精确的计算吗？怎么还会超出来？这一块主要是什么呢？没有预留足够的本机内存，为什么？其实最核心的是这一块。管理内存。特别是你用RODB的时候，可能会碰到这个问题，Rose DB我们说了，呃，它是用的管理内存，托管内存，那么默认呢，是flink来帮我们管理，但是呃，由于lost DB版本的问题，还是可能出现什么内存超用的问题，那么一旦这一块管理内存超用，甚至超整体所有内存加起来，那么一算，诶，超出进程内存，那就超出了容器的大小，那这个时候咱们的容器就会被雅N给K掉。

啊，这主要是使用DB的时候可能出现的啊，那么如果是job manager啊，有一个参数啊，它可以排除。呃，首先是直接内存的泄露可能性啊，这个参数你把它制成true就行，那么另外就是咱们刚才分析的那个task manager上面的DB内存。这个还是，呃，在早期啊，很多企业里面特别常见的，那么这一块怎么办呢。呃，有最简单的方式，你可以尝试一下调高JVM执行开销，执行开销你可以理解为如果调大的就是预留吗？比如说管理内存，超用了就lost DB，那超用了它会继续使用对外内存，比如说富余的JM开空间，它是可以拿去用。

那为什么不调这个task都要把它本来是零把它调大呢？为什么呢？因为它跟直接内存是有三块混用的，即使你调大的，它也不一定说完全会给什么Rose DB来做buffer。所以比较推荐的就是，如果真遇到这种情况，第一个第一个解决思路，调大管理内存。这是第一个，第二一个调大执行开销。一般来说，如果是这个原因就没什么问题。好，这块是关于内存方面的一些异常，接下来我们看看checkpoint。切克poem曼，呃，失败，失败分为两种啊，一种是什么？

这个啥衰落衰退另外一个什么呢。到期对吧。这种是两种异常，第一种衰退，你可以看到这个日志，关键词在这里。我们就讲一下思路，因为这个问题引发的原因千奇百怪，你可以通过log里面查找。Job manager运行在哪个容器上面？对吧，然后呢，你再去呃。通过日志可以看到嘛，这个是以前人家截下来的日志，对吧，比如说这一句话你看。部署什么什么什么，到哪个slot在哪一个容器上面对吧，具体呢，在哪一个主机上面都有，你仔细看日志就行，那找到对应的节点。你再去找这个节点里面task manager的日志，因为咱们实际执行是不是在task manager上面对吧，在这里面查找具体的原因。

那么像这种衰退的，呃，还有一种特殊情况是什么？被取消了。这种是。呃，什么呢？如果咱link里边有较小的checkpoint还没有对齐，比如说我编号为一的啊，这边需要等待两个，另一个一一直在路上还没有对齐，收到了更大的check po，比如说现在收到了快的，这个又收到了一个二了。第二次barra，那这时候一就会怎么样被取消掉，相当于说被越过了。就是你太慢了。变成二了。你看上一个还在对齐，收到了20的bar。会慢慢控制好，19过期了，过期了啊好。那这个日志如果你打开debug是能看到的，对吧，然后。放弃什么对齐啊，跳过对齐等等，这个checker抛很多问题，我们需要通过第bug日志去看。

好，另外一个就是。到期这个主要是什么？慢慢引起的啊，做的非常慢，超时了，失败了。那如果在这里关键词是什么这个。过期了，到期了。那同样的道理，你还是要找到说，呃，对应的一个日志。就对，找到哪一个容器，那个容器不就是运行task manager吗？那在那个主机上再看一下它的task manager日志啊，到底是什么原因，一般是由其他原因引起的啊。那如果咱们详细聊check point，呃，Task可门你这端做的快照的话，分为三个阶段，一个是对齐。对齐之前就是开始做快照前就是在等待对齐嘛，那对齐之后就开始做了，对齐之后它会有一个同步阶段。

同步阶段之后，它会有一个异步阶段，异步阶段早期版本是需要手动开启的，就你可以选同步还是异步啊，那异步指的是写这一块，比如说咱们将状态写，呃，写入到HDFS这个动作。呃，是一般来讲是异步完成的，那现在高版本默认全部都是异步来写的，所以这个也不用担心，总而言之呢，三个阶段，那debug日志也有，如果你看到说开始什么切口抛。这个就表示已经对齐了，要准备开始做了，那再往下，如果你在debug日志看到这么一个关键词。叫同步部分，那说明他开始什么做同步了。啊，不是应该说已经完成了，然后花费了多少时间完成了这个同步动作，大家注意，如果你开启异步的话，同步阶段是不会去写状态的，都不会去写入远程存储的，是由异步的线程去做的啊。

再往后，如果你看到这个异步阶段。呃，花了多少秒，这个指的就是他去写，将状态快照写入到外部存储啊，这个过程，比如说他花了多少时间，这个是大概介绍一下怎么去定位哪一个区间出现的问题，那么根据这些关键日志，你就可以定位到底是做哪一步慢。因为每一步慢，它的原因完全不一样，比如说一步慢了，那是不可能远端的那个文件存储系统，它那边出现的性能瓶颈。对吧，有可能。好，另外一个checkpoint慢，Check point慢呢，咱们一般呃，还得考虑间隔嘛，对吧，我们说这个都前面讲过怎么来测对吧，端到端的时间你也不能设的太短。你要结合端到端的这个check point时间来考虑，呃，那首先第一个间隔，如果是一分钟超时十分钟。

那么他经常要做了九分钟，这个时候是不是表示他非常慢呢？虽然还没超时，我们间隔一分钟，其实就是期望他一分钟之内能完成。那。有这么几个思路啊，第一个触发慢。在老版本有一个问题，有一个强锁的问题，这边大家可以去看这个问题列表啊，我去翻出来了啊，我特意去翻了一下，那如果你的版本比较老，什么1.81.9可能会有这个问题，1.10开始就不会啊。也就是说这个问题，如果你是老版本去看一下这个。那如果不是的话，就不用管，一般不会出现啊，另外一个就是尽量还是开启增量的这个泡你慢你想想如果是大状态，你又是全量，那肯定效率不高对吧。让DB，我们用DB增量前面也测试过了，率肯定是很高的。

第三一个还是一样的，咱们都讲过。存在反压是不是会影响这个po时长对吧？这个分析过了，现在咱们回过头来看是吧？另外反压是不是可能由数据倾斜引起的，就这两个最常见的两个老大难问题啊，你去看看有没有呗，都很明显，很直观。最还有一个就bar对齐慢。一直不对齐的话，他就肯定是会影响他去执行，对吧，那他一般。我们就看刚才提到的那个日志，开始check point。如果他迟迟没有。那是不是说明一直没对齐，那你就是往上游找啊，一直往上找，往上找往上找。好。还有一个主线程太忙啊，说白了就计算性能太差了啊，代码逻辑看是不是有问题，这个时候你可以通过什么火结合火焰图来分析啊。

说白了，这个一般可能会结合法尼亚一起出现的。同步阶段做得慢。这个一般是老一点的版本，就是说。你没有开启异步功能。没有开启异步的话，那个后面的异步阶段写阶段就不会去做了，而且都都是在同步完成的，所以一般老版本我们建议是什么呢？把异步打开，新版本就不用管，新版本的话，新版本应该是从1213开始，应该是一三吧，还是呃，对1313默认的就全部是异步了，不，不让你改了就全是异步了。异步阶段。这个异步阶段干什么呢？我们说了持久化到存储上面嘛，对吧，比如说HDFS。那这个的瓶颈一般就是网络啊，网络情况不太好，或者那个HDFS有点问题，你对应的去看一看就行了，另外呢，呃，对于loss DB来讲，从本地读文件。

还要考虑本地磁盘的性能，对吧？那我们知道它有一个线程数，还记得咱们看过预定义选项默认源码里面是不是有些地方给我们设成了四了，对吧？那从一三开始这个参数就是四了，那如果早期版本默认还是一啊，你尝试着把它改成四啊，比较推荐的值，提高一下它本地啊读写的性能。啊，不是本地读写，这个是多线程上传的啊，多线程上传。好，这是checkpoint相关的问题。呃，那后面还有几个咱们一起看的呗，啊。那这个动态发现分区卡不卡什么场景呢？就原先我卡不卡，比如说是这个topic是三个分区，那我这边可能在消费，那可能由于。

你们自己的规划，你对这个topic增加了一个分区啊，增加了一个分区没问题，但关键是什么，你增加分区flink不消费啊。因为你新的他之前没分配过，他怎么知道呢，对吧？啊，但是别担心，Flink提供了一个功能，动态发现分区。你只需要开启这个参数就行。它是什么意思呢？它就是它会启动一个线程。根据咱们这个是一个时间间隔啊。定时呢，去检测一下卡不卡最新的原数据，你分区变化它就能，呃，后面它就检测到了嘛，然后呢，它就会呃，对新分区开始从头消费。那还有一个water mark不更新，这个主要看你对water mark那个传递机制了不了解，咱们知道water mark，比如说这是一个算子，它的上游有。

多个。那么请问。呃，每一个都传给他一个沃mark，那么当前这个算子它的进度是多少，是不是在这里面取最小啊，对吧，那就有这么一个问题，比如说咱们消费卡不卡。呃，SS我是1:1写的，比如说都是三个，那么结果呢，可能到了。夜里或者什么情况，呃，咱们这个。比如说只有这两个分区有数据继续更新，这个地方一直不更新，那就导致什么这里在动，这里在动，这里没动。那它生成的water是不是一直是那个很小值啊。对吧，那再接下来他们往下游发，比如说下游是一个变形度，别管几个变形度，这个萨塔是不是要收三个，呃，这个水印呢，那上面这两个一直在更新，后面这个不更新。

那最终是不是导致它一定是最小的，它最小啊。那即使你两个一直在增加，一直在增加，但是一直有一个拖后腿的，就导致water mark不更新，沃mark不更新就会导致什么呢？咱们事件时基于事件时间定义的各种窗口啊，定时器啊，都无法被触发了。那这个怎么办呢？这其实人家也考虑到了，咱们当然特别老的版本是没有啊，可以指定一个空闲，呃，输入检测。诶，比如说咱们指定卡夫卡少子为那个。圆的时候可以直接从卡不卡原指定water mark生成。你看我利用了一个这个官方连接器的实现类，这个是sources的时限内，对吧。那这个定义好之后，是可以直接调用指定water mark的方法，那在这里有一个water mark有个方法叫什么。空闲等待时长，也就是说超过五分钟你都是处于空闲状态，那么你这个小分区就不会被我记入water mark的更新依据，也就刚才那种场景。

前两个在动，后面这个不动，那导致你这个一直是最小值water mark不更新啊，比如说我指定五分钟，五分钟你都没动了，好你没资格你出局了，接下来沃mark的更新只看这两个。就这么一回事啊。呃，接下来就是几个常规的小问题啊，有很多，嗯。对弗link不太熟的经常碰见的高频问题。说实话。呃，这些问题可能是你不够细心引起的，第一个就依赖冲突。呃，经常报错，Class not found no such method，对吧，找不到类，找不到方法，不合适的类，类型转换，这种一般就是依赖冲突。最经常见，我经常碰到别人问的问题就是什么了，哈杜冲突，哈杜依赖冲突，还有瓜娃冲突等等等等，这种东西呢，冲突嗯，首先我比较建议打包插件，用C的插件啊，另外就是定位冲突的方式。

他会报错嘛，哪个类找不到，哪个类的哪个方法找不到，你去源码里面搜一下这个东西是属于哪个包下面的，对吧，你先搜到这个类啊，举个例子啊，咱们搜一个什么呢？比如说你报错什么flink卡夫卡。C base这个类找不到，好，你看现在CTRL加N输入全列名是不是跳到这个类了，你按了一下左上角，这里是不是有个准星啊，定位到它所在的炸包啊，这个就是炸包了。那在接下来我比较推荐的一个东西是main help这个插件。啊，我们打开setting。你直接看依赖数也可以啊插件。这就是一个main help，呃，D安装就行了，它能够可视化的界面操作，咱们那个依赖问题，举个例子，点开这不是泡门键吗？我装了插件之后，这里就会出现这个菜单栏。

这个是什么依赖分析，比如说我出现了。一个刚才那个包名是什么啊，随便呢，我们假设是这个什么fast Jason冲突了，好吧，那你在这搜fast Jason。Yeah。啊，这个不会显示啊，我想想啊哈，Do会吧。啊，我没用哈杜，那用点什么呢。刮网来刮网。啊，不是啊，他是这样啊，我这边没冲突，所以没有他这边你看这是显示冲突的一些炸包，然后你可以过滤。这是冲突的列表。你可以在这列表里面过滤，另外一个是所有的依赖都展示，比如说在这这边就所有依赖都展示出来了，那你可以搜啊，比如说还是一个什么。

呃，K。你看他就找到了K，而且是谁引用的，你看这里层级关系都有。塑形也有啊，那正常来讲，你看所有依赖里边，我过滤条件去掉红色的就代表有冲突，我们点一下看看。引用到这个依赖的有谁呢？你看，有ES的包，有Jackson的包。杰克son的，还有哈多ER的包，还有杰克son的包对吧，那你可以右键也SC，它就自动在这里把它排除掉了，但有时候不好使。就是说这依赖是强行绑定到内置里面的，去除不掉，那你可以考虑用she的插件把它给呃遮蔽掉啊，She的插件可以的，She插件也可以，Rude就可以完全去除掉，这个你不用担心，或者呢，把它改个包名。

相关方法我就不说了，这个网上资料特别多啊，大家要学会解决。另外一个编码习惯就是你这种集群环境有的包你就不要打进去了，尽量就是什么providing providing providing就好了呀，啊，不要什么包都打进你的这个执行价保里面去，没必要，特别是什么哈杜啊，哈杜的包啊，Flink的包啊，呃，日志的包啊等等就不要打了，只有那些你live安装路径下live里面没有依赖，你才考虑说打进JA包里面去，对吧。那有有的人又说我我程序本地执行不了，那你这个run。配置。这里不有个什么吗？执行的时候包含包吗？你把它勾上就行了，好吧。这没啥好讲的，另外一个too many open files，这个其实特别常见啊，就各种东西都可能遇到，这是超出操作系统的文件描述符限制，咱们可以用什么呢？一个命令u limit去看啊。

呀。我现在的上限是65536啊，这个是我改过的，杠N是可以直接看杠A也可以杠A，这是操作Linux系统的一些各种各样的限制，什么进程数啊，Open file就文件描述，描述符啊，数量限制等等这些你100度同样也是一堆啊，我也不啰嗦了。那如果你是低版本flink使用，要要注意就是。他关于lost DB有一个参数自己的限制啊，那如果不限制，你可以改成负一，那如果是高版本一三的不用管了，它默认就负一啊。那一般你就看看是不是操作系统的这个超限。还有一个常见的，呃，什么不能够怎么样把数据发送给下游，这个其实就是什么就脏数据，举个例子，咱们的代码里边啊，随便薅一个。

啊UV吧，你看咱们一开始是不是做了各种各样的map对吧？Map map可能你中间刚提交执行前啊，前一阵子跑的好好的，突然啊，这程序就报那个错，其实是什么来了一条你程序无法识别的脏数据转换不了啊，这里处理就出问题了，你怎么往下游发呀。对吧，像这种问题你一看应该就知道。啊，一看就知道啊，异常要么类型异常，要么解析异常等等啊，就是一些场景脏数据你没有考虑到啊，你把它处理一下，另外一个就是报一些通讯超时，什么这个ask time out，主要是什么阿卡，那我们我在那个弗link源码课程，那个是我写我录的那个视频，呃也讲了弗link用到既用到阿卡，也用到什么ne。

Net呢是用来传输数据的，就咱们处理的那些数据，阿卡呢，是用来老大跟小弟之间，呃，互相沟通，互相交流的，比如说心跳啊啊，还有下命令啊，调度啊之间的通知，都是用的阿卡，传数据用nat。阿卡超时。就集群负载大，网络比较拥堵。反正就是性能不行，那如果负载网络问题无法解决，你再考虑调大这个超时时间，默认是十秒，其实一般是够用的，如果超过十秒，我建议呢，还是优先解决自身的问题。另外就调用外部服务，这个要注意，就比如说你去读写base那样，还是用异步IO，要不然你可能阻塞在那个读读写上面，网络太繁忙。那也有可能。最后的最后呢，咱们当然这个错误是讲不完的，那这边给到一个参考，这个是阿里那边阿里云上面的一篇啊。

常见的问题与排查思路，这边还有列出很多很多问题啊，那当然。大家可以去参考参考啊，这边我就不再讲了，给大家提供一个方向，好吧，这边就是常见的一些问题。