问题背景
某客户反馈有一台节点上多个Pod出现RTT增高现象，持续时间为10~30s
排查过程
安装ACK Net-Exporter后，问题复现后，观察相应的TCP指标
establish连接数有突增，但是timewait并没有出现突降，可以确认这个pod的业务是快进快出类型，连接的关闭在对端，timewait不在本地，即establish突增的原因是由于本地业务报文回复较慢导致对端没有办法及时关闭连接所致。
listendrops等链接相关的指标的异常是连接增多引发的结果，从这里看关键的信息还是rxqueue堆积的增多，用户进程没有及时处理业务数据，没有及时从socket中完成消费，但是txqueue没有出现堆积，说明用户进程本身没有遇到cgroup throttled级别的调度问题，发送报文的过程是通常的，问题的核心在于用户进程出现了卡顿，卡顿是由于进程本身的业务操作收到影响导致。
客户提供passiveopens的监控，在问题发生附近有明显的先增长后突降的现象，这是一种补偿态的图表，可能与客户的业务逻辑有关，连接的增多导致passiveoopens增长，随后由于增长，半连接队列也被打满，导致passiveopens突降。
同时客户反馈相同节点流量较高的几个pod军出现类似的问题，部分流量较低的pod没有出现明显的RTT增长。
客户的业务由于某些原因导致进程本身出现卡顿，覆盖同节点多个pod，从客户提供的情况大致的推测方向有以下几个：
● iowait增高。
● dirty page落盘导致卡顿。
● 经确认后客户的机型为g6 104c384g，存在2个numa node，且打开了numa balance，即有可能是numa migrate导致。
● 其他底层原因。
可以排除一下原因：
● cgroup throttle，客户反馈已开启cpu burst。
● 调度问题，客户多个pod相同时间出现，多个cpu同时出现调度问题概率较小。
查看了dirty page、采样的cpu使用率没有明显的回落，iowait也没有明显的变化。可以排除这些方面的原因。
根因原理
客户打开了numa balance，并且numa node有2个，可能存在page migrate。目前来看这个可能性较大。
page migration相关资料：
https://www.kernel.org/doc/html/v5.4/vm/page_migration.html
page在不同numa node之间做迁移的情况下，可能会导致page关联的task的操作被延迟执行，从而导致进程本身的卡顿。 
查看进程的/proc/[pid]/sched文件可以看到numa_pages_migrated的数值大于0。
net-exporter监控中发现socket的rqueue堆积比较明显，同时socketlatency read100ms次数变化有突增。
解决办法
建议建议客户使用拓扑感知调度，如果是单独部署，可以关闭集群中单个节点的numa balance，具体操作方式如下：
