前段线上用户频繁反馈，flink任务运行一段时间就失败了。然后查看flink UI管理界面，发现整个taskmanager都挂了
问题分析
收集了用户flink日志，主要是taskmanager日志
image
发现非内存因素OOM的，而是自主退出的。
关键因素由于取消任务超时180s引起的，taskmanager误判服务异常，自主退出
接着跟踪日志，找到经过多次重试，尝试恢复任务的地方
第一次重试
image
第二次重试，刚好间隔60s
image
总共重试3次了。超过180s
taskmanager打印退出日志
排查到根因是因为mysql业务操作引起的sink表被锁住导致无法写入。
接着排查60s时间，询问客户发现配置的数据源的socketTimeout为60s，对于实时场景，该超时时间过大了。
解决方案
业务层面，告知用户flink实时任务，尽量保证链路的纯粹，不要因为类似操作影响实时性。
flink层面：默认180s取消任务超时时间适当调大一些，task.cancellation.timeout
数据源层面： socket超时时间，不要过长，不然容易引起任务线程IO阻塞等待过大，无法及时响应一些内部状态变更，从而引发雪崩。
