本周遇到点问题，发现某个进程触发netlink请求后，会长时间hang(1~2s)，需要进行深入归因排查。

归因的主要思路是先找到hang的位置，即找到现场的调用栈，由于触发时会出现秒级的hang行为，此处不需要太过复杂的机制，周期性cat proc目录的stack文件即可。

在找到调用栈后，就需要反查到底是哪些进程触发netlink请求了，这里的难点在于，进程的hang行为并非由于当前线程导致的，因此需要一种全局维度的机制来进行综合判断。

已经做了一段时间的RDMA相关开发了，陆续总结几篇相关文章。

RDMA是Remote Direct Memory Access的简称，目前主流的RDMA实现大致可以分为IB、RoCE、iWarp三类。

最近利用空闲的服务器搭建了一个buildbot集群，需要在上面实现自动构建和自动测试，两者均涉及消息的推送。

buildbot可以通过email、http、IRC等方式进行消息的推送，但由于部署环境特殊以及出于安全方面的考虑，比较适合的方式是通过钉钉机器人推送构建信息。

0x00 问题描述

这是前阵子发现的一个问题，当时我正在写一个简单的http benchmark工具，具体简单到什么程度呢？就是创建一堆socket，去connect目标服务器。

接下来，问题就出现了，我发现1w并发链接和2w并发连接的耗时完全无线性关系，而是呈现一种近指数上升的趋势。例如，1w并发链接建连1w次，耗时不到1s，如果改为2w并发链接，建连2w次，耗时突然变成了10+s。

今天来谈一谈心跳连接，本文不会给出具体的解决方案，只抛出问题。

使用心跳连接的初衷是检查目标主机是否可用，具体方式通常是通过独立的连接，以一定的频率pingpong，当然timeout也是必不可少的，毕竟丢包也是很正常的事情。