1. 确认时延来自哪些方面？
有几种可能：
- 虚拟机本身时延高
- 数据面转发时延高
- 物理网络转发时延高（涉及跨主机通信）
2. 如何确认时延来自虚拟机
这里指的是发包给虚拟机，虚拟机回复比较慢。表现一般是偶尔跳一个高时延的包：
最简单的方法是抓包，如下，vm1 ping vm2，在图中 vlink1 和 vlink2 两个点分别抓包：
观察目的端（也就是 vlink2 点）的抓包情况，如果 request 包和 reply 包的时间相隔比较长，正好匹配 ping 的高时延，那就是虚拟机本身处理时延高导致的抖动。
- 同时看 vlink1 和 vlink2 的 request 包，可以确认 DVS/EVS 的转发时延，可以看到这里只有 4 us
- 只看 vlink2 的 request 和 reply 包，可以确认虚拟机的回包时延，可以看到这里有 12ms 左右
如果不想抓包，那就问题虚拟机同时 ping 几台虚拟机和网关，看抖动的时间点是否一致，不一致也能说明时延发生在虚拟机内部；
这个可以确认的原因是数据面（dataplane）是同一个，要影响都会同时受影响，但这个点作为证据可能说服力不够，最有说服力还是抓包！
3. 如何确认时延来自数据面？
如果 ping 的时延是持续很高的，基本可以确认是 dp 有性能瓶颈了；
680 及之后的版本可以后台看下 dpdebug 4 来确认各个转发核的使用率是不是很高，很高意味着 dp 有性能瓶颈；
之前的版本没有这个命令，可以看下 vxlan 口有没有和管理口复用，如果复用了可以看下黑盒里面管理网的 ping 监控，如果看到时延有抖动，也能确认是 dp 有性能瓶颈；
如果没有复用，这种比较难确认，但也有一些方法可以间接确认，比如：
- 可以多找几个虚拟机，同时互 ping 或 ping 网关，看下是否同时都有高时延出现，如果是，那也能确认；
- 看下主机详情页网卡流量统计的地方，流量是否有突增，或流量比较高，再结合网口统计的地方是否有 rx_missed_error 之类的错包，也能确认
- 另外还有一种情况是 session 满或新建比较高，session 满后台 dataplane 日志有 session 满的日志可以判断；
session 新建高，这个统计后台没开（6110才打开），问题发生时也无法确认，但可以看下前端有没有虚拟机 session 过高的告警（但要注意，有这个告警不代表有性能瓶颈，因为告警设置的阈值比较低，但可以作为部分参考）
4. 如何确认时延来自物理网络？
这个涉及到跨主机通信，没有很好的办法，只能在两台主机上同时抓包，然后用上述虚拟机时延的判断方法来判断问题发生在哪里。
虚拟机时延问题，根因可能是虚拟机内部跑的应用比较耗资源，如 oracle 等数据库应用；也可能是超融合平台超配严重，vCPU 被抢占导致；
数据面时延问题，根因就是数据面性能不足了，可能流量大、session 新建高等；
物理网络时延问题，根因来自外部，非 HCI 问题，一般不关注；
虚拟机时延问题
- 如果因为vCPU被抢占导致网络时延抖动（虚拟机内部top查看steal比较高，或者后台pidstat查看kvm进程的%wait比较高），
可以进行虚拟机独占（670及以后版本前端有开关，老版本后台脚本进行绑核（咨询吴冬冬）），也可以将主机上其他虚拟机迁走降低主机负载，如果整体负载都比较高，建议考虑扩容。
- 如果解决vCPU抢占后还是有抖动，就要具体分析虚拟机内部应用是否干扰了网络收发包。
数据面时延问题
- 如果转发核是单核，那就调整 4 核
- 如果已经是 4 核，聚合口可以看下有没有网口流量偏载的现象，如果有，可以调整聚合模式为 4层
- 如果 session 表满，就调整“网络转发消耗内存”（目前遇到调到 2000万完全够了）
- 如果上述都调整了还是有瓶颈，这个比较难搞，要么得找出软件上的瓶颈点在哪，然后版本跟进优化；
要么能确认是硬件瓶颈，那就更换网卡（比如客户流量就是超过 10G的，那可能得上 25G网卡）
建议使用Chrome浏览器访问！
