深入了解 Flink 网络栈（二）：监控、指标和处理背压
在之前的文章中，我们从高级抽象到底层细节各个层面全面介绍了 Flink 网络栈的工作机制。作为这一系列的第二篇文章，本文将在第一篇的基础上更进一步，主要探讨如何监视与网络相关的指标，从而识别背压等因素带来的影响，或找出吞吐量和延迟的瓶颈所在。
找出重传较高的TCP连接
考虑一个场景：如果监控到一台主机的tcp重传率较高，如达到20%以上，且在这台主机系统上开了成百上千的tcp listen监听端口，同时间tcp连接并发高达数十万，此时如何得知哪些监听端口上重传较高? 哪些tcp连接在不断重传报文导致？可能的原因是什么？下边将解析这些问题。
分析网络超时问题的最佳实践
对于云上的用户来说，业务日志里面报超时问题处理起来往往比价棘手，因为1) 问题点可能在云基础设施层，也有可能在业务软件层，需要排查的范围非常广；2) 这类问题往往是不可复现问题，抓到现场比较难。在本文里就分析下如何来分辨和排查这类问题的根本原因。
Java应用异常状态监测
老板最近分派了一个任务，说线上客户在部署应用的时候发生了系统级别的OOM，触发了OOM Killer杀掉了应用，让我们解决这个问题。
对于这个任务，我从如下几点开始调研、分析与解决。
1、什么是系统级别的OOM（Out-Of-Memory）？
当创建进程时，进程都会建立起自己的虚拟地址空间（对于32位系统来说为4g）。