反压定位学习之解决思路

调优/backpress.md

@@ -109,7 +109,10 @@ Network和 task I/Ometrics 是轻量级反压监视器，用于正在持续运
 采用 Metrics 分析反压的思路：如果一个 Subtask 的发送端 Buffer 占用率很高，则表明它被下游反压限速了；如果一个
 Subtask 的接受端 Buffer 占用很高，则表明它将反压传导至上游。
 
-![pic](./backpress004.png)
+| / | outPoolUsage 低 | outPoolUsage 高 |
+|--- |--- |---| 
+| inPoolUsage 低 | 正常 | 被下游反压，处于临时情况，没传递到上游；<br>可能时反压的根源，一条输入多条输出的场景 |
+| inPoolUsage 高 |  如果时上游所有outPoolUsage 都是低，<br>有可能最终可能导致反压(还没传递到上游;<br>如果时上游所有的outPoolUsage 都是高，则为反压根源) | 被下游反压。 |
 
 inPoolUsage和outPoolUsage反压分析表
 
@@ -129,3 +132,51 @@ outPoolUsage 与 floatingBuffersUsage 、 exclusiveBuffersUsage 的关系:
 buffer 消耗完，就会使用floating Buffer）
 
 
+# 反压的原因及处理
+
+注意：反压可能时暂时的，可能由于负载高峰，CheckPoint或者作业重启引起的数据积压而导致的反压。如果反压是暂时的，
+应该忽略它。另外，请记住，断断续续的反压会影响我们的分析和解决问题。
+
+定位到反压节点后，分析造成反压的原因的办法主要是观察Task Thread。按照下面顺序一步步排查。
+
+## 使用火焰图分析
+
+火焰图是跟踪堆栈线程然后重复多次采样而生成的。每个方法的调用都会有一个长方型表示，长方型的长度和它在采样中出
+现的次数成正比。是Flink 1.13 新特性。
+
+开启方法：
+```bash 
+rest.flamegraph.enabled : true
+```
+
+横向就是耗时时长，横向越长表示耗时越长。纵向表示调用栈。一般只需要看最上面函数。
+
+
+## 分析GC情况
+
+TaskManager的内存以及GC问题也会导致反压，包括TaskManager JVM 各区内存不合理导致频繁Full GC甚至失联。通常建议
+使用默认的G1垃圾回收器。
+
+打印 GC 日志的第一步，就是开启 GC 打印的参数了，也是最基本的参数。
+
+```bash 
+-XX:+PrintGCDetails -XX:+PrintGCDateStamps 
+```
+-D参数配置方式：
+
+```bash 
+-Denv.java.opt="-XX:+PrintGCDetails -XX:+PrintGCDateStamps"
+```
+
+## 外部交互组件
+
+如果我们发现我们的source端数据读取性能比较低或者Sink端写入性能较差，需要检查第三方组件是否遇到瓶颈，以及做维表
+join时的性能问题，也许要和外部组件交互。
+
+关于第三方的性能问题，需要结合具体的组件来分析，最常用的思路：
+
+1、异步IO + 热缓存来优化读写性能，减少对外部组件的访问。
+
+2、先攒批在进行读写操作。
+
+