4.2. 诊断

TX 丢弃是因为实例 vCPU 和虚拟机监控程序上其他进程之间的干扰而造成的。tap 接口的 TX 队列是一个缓冲区，可以在实例无法获取数据包时存储简短的数据包。如果实例的 CPU 阻止运行（或冻结）长时间，会出现这种情况。

TUN/TAP 设备是一个虚拟设备，一个末尾是一个内核网络接口，另一个端是用户空间文件描述符。

TUN/TAP 接口可在两种模式下运行：

在 KVM 网络中，用户空间文件描述符归 qemu-kvm 进程所有。发送到 tap 的帧（从 hypervisor 的视角到TX），最终在 qemu-kvm 内作为 L2 帧，然后将这些帧作为收到到虚拟网络接口的网络数据包（从虚拟机的视角来看）将那些帧发送到虚拟机中的虚拟网络设备。

使用 TUN/TAP 的重要概念是管理程序中的传输方向是虚拟机的接收方向。相反方向也是如此；从虚拟机传输虚拟机监控程序的接收是相同的。

virtio-net 设备上没有数据包的"ring buffer"。这意味着，如果 TUN/TAP 设备的 TX 队列被填满，因为虚拟机未接收（足够快或根本），那么新数据包都没有什么位置，并且虚拟机监控程序看到利用的 TX 丢失。

如果您注意到 TUN/TAP 上的 TX 丢失，增加 tap txqueuelen 以避免，类似增加 RX 环缓冲，以停止物理 NIC 丢失。

但是，假设虚拟机在接收中只是"slow"和"bursty"。如果虚拟机没有足够快，或者根本没有收到接收，则调整 TX 队列长度不会帮助。您必须发现为什么虚拟机没有运行或接收。

如果唯一需要提高虚拟机数据包处理性能，请完成以下步骤：

这记录在 KVM 的 libvirt 域规格中，并可在 RHEL KVM 管理程序上通过 virsh edit 进行。

如果您无法在 Red Hat OpenStack Platform 中配置 virtio-net multiqueue，请考虑在虚拟机中配置 RPS，以平衡多个 CPU 内核与软件接收负载。如需更多信息，请参阅 kernel-doc 软件包中的 scaling.txt，或者参阅 RHEL 产品文档中的 RPS 部分。

/sbin/ip link set tap<uuid> txqueuelen <new queue length>

/sbin/ip link set tap<uuid> txqueuelen <new queue length>

cat <<'EOF'>/etc/udev/rules.d/71-net-txqueuelen.rules
SUBSYSTEM=="net", ACTION=="add", KERNEL=="tap*", ATTR{tx_queue_len}="10000"
EOF

cat <<'EOF'>/etc/udev/rules.d/71-net-txqueuelen.rules
SUBSYSTEM=="net", ACTION=="add", KERNEL=="tap*", ATTR{tx_queue_len}="10000"
EOF

ip link ls | grep tap

[root@overcloud-compute-0 ~]# ip link ls | grep tap
29: tap122be807-cd: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 5505
qdisc pfifo_fast master qbr122be807-cd state UNKNOWN mode DEFAULT
group default qlen 10000