Qemu-KVM 网络性能优化实践

作者:赵星

背景

在做优化之前,腾讯云上使用的母机单队列,性能只有14w pps。

已有的多队列版本,在20w+ pps左右,不是很理想。

主要问题性能

1 . 单队列成为性能瓶颈

物理主机环境,使用多队列已经有多年。

而在公有云上,虚拟化的virtio-net长期使用的多队列。

有如下原因:

  • 早期的qemu-kvm版本只支持单队列。
  • 为了稳定性,友商如阿里云,virtio-net的网卡到2016年底,仍然是单队列。

2 . 多队列性能并不理想

引入网卡多队列,目的是充分利用SMP处理器的性能。

在物理母机上,多队列性能提升非常明显。

但是在虚拟机上,性能却没有得到明显提升。

已有的kvm-2.0版本,当时是20w pps左右,单队列能到14w pps。

Qemu-kvm多队列原理

上图是多队列的示意图。

和物理机上的多队列类似。

一个virtio-net的队列,对应一个虚拟cpu。

这样,避免了多个虚拟cpu使用同一个队列带来的竞争问题。

性能优化实践

云上Overlay网络的实现

腾讯云网络使用了overlay网络技术。

在用户看来,每个用户都是一个独立的网络,相互隔离。

具体实现如下:

由上图可见,数据包的流程为

  • 虚拟机向外发包,经过virtio-net网卡驱动外发(virtio-net前端)
  • Qemu实现的tun口(内核态)收到包后,交给网桥
  • 网桥上数据包会被VPC截获,实现overlay网络功能
  • 数据包经过处理后,交给GRE口,进行overlay封装
  • Gre口调用物理口的发包函数进行发送。

进来虚拟机方向的数据包处理流程相应反转即可。

初步分析

从上图可以看出,数据包是经过了一条较长的路径,最终从物理口发送出去。

其中每一个流程都是可以成为瓶颈。

于是,我们做了第一步,让虚拟机支持多队列。

虚拟机多队列的选择

两个方案:

  • 升级kvm-2.0
  • 在kvm-1.0上移植母机多队列

最终,我们选择了移植的方案,理由如下:

  • 腾讯云的物理服务器基本上都是kvm-1.0版本,这个版本是不支持多队列的。
  • 有kvm-2.0版本,但多队列性能提升并不明显。
  • 在kvm-1.0上,我们已经做了大量的工作,也经过了长期运营的检验。

多队列功能的移植

移植涉及到了qemu-kvm虚拟化的所有核心组件:qemu,libvirt,Linux内核。

移植过程的主要问题:

  • Patch非常多,Linux内核20+个patch,qemu 20+patch,libvirt patch相对少一点。
  • 要兼容旧的qemu和内核。三个组件存在混合部署的情况。
  • 热迁移要实现兼容。

最终,和yunfangtai一起,通过谨慎小心的移植,这些目标都实现了。

还有单队列性能瓶颈

多队列移植后,理论上也只能达到kvm-2.0的性能水平。实测也是如此,在20w pps左右。

当时业界Google的性能能达到40w pps。我们只有20w pps。

这其中存在着很大的提升空间。

Vpc overlay基本不配置规则的情况下,性能损失约10%。不是主要矛盾。

通过内核perf工具和流程分析,发现耗在spin_lock的cpu特别高。

主要是在dev_queue_xmit中加锁消耗的。

分析vpc的代码,发现GRE口实现,还是一个单队列网卡。

前面的并发处理,到了GRE口变成了独木桥,性能损失明显。

还是并发瓶颈

将vpc中的GRE虚拟口实现改为多队列之后,性能仍然没有太大的提升。

通过perf采样发现,spin_lock占用的cpu仍然很高,是最可疑的瓶颈点。

分析内核代码流程,最有可能的还是dev_queue_xmit中的队列锁。

这里存在这样一种情况,虚拟机选择队列后,经过一层层选择,最终到物理队列时,会有多个虚拟队列选中同一个物理网卡队列的情况。

问题基本定位清楚,需要做如下修改:

  • 虚拟机virtio-net后端的tun实现,要保持虚拟机选的队列。
  • Vpc中的gre口实现,不能修改队列映射关系
  • 物理口发包时,要保持映射关系不变。
  • 同时,多个虚拟机,要保证尽可能利用不同的物理队列,避免相互干扰。

以上修改做完后,性能有了明显提升,达到了业界第一梯队Google GCE的水平。实现了本身的突破。

其他优化

  • Qemu自身队列长度限制位256,修改为1024,在大流量下减少丢包。
  • 后端tun网卡队列长度优化。

展望

Virtio-net的性能优化,按目前的vhost-kernel框架下,潜力已经很小。

后续方向:

  • 硬件offload方案

如智能网卡方案,将vpc部分逻辑offload到服务器之外的设备上。

  • Dpdk+vhost-user方案

提升母机发包引擎的性能,同时poll mode能减少虚拟机发包的负担。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏蓝天

理解Load Average做好压力测试

SIP的第四期结束了,因为控制策略的丰富,早先的的压力测试结果已经无法反映在高并发和高压力下SIP的运行状况,因此需要重新作压力测试。跟在测试人员后面做了快一周...

542
来自专栏美团技术团队

消息队列设计精要

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。 当今市面上...

5635
来自专栏腾讯技术工程官方号的专栏

鹅厂 TDSQL XA 事务隔离级别的奥秘

TDSQL XA 全局事务(global transaction)是指用户客户端连接到 TDSQL XA 分布式数据库系统后发起和执行的事务,也就是 TDSQL...

2792
来自专栏北京马哥教育

我所理解的性能测试是什么?

扯淡 首先说明这篇博客是文不对题的。起这个名字想法来源自韩寒的《我所理解的生活》,之前看过一个关于这本书的视频,感觉巨牛X,于是就想写一篇《我所理解的性能测试...

3609
来自专栏韩伟的专栏

经典的服务器结构概述(中)

. 经典的服务器结构概述(中) 今天将和大家详细探讨分服模型,本文结构如下: ? 1模型描述 分服模型是游戏服务器中最典型,也是历久最悠久的模型。其特征是游...

3087
来自专栏noteless

3.操作系统简单介绍 操作系统发展历史 批处理分时系统 操作系统是什么 操作系统对文件的抽象 进程 虚拟内存是什么 操作系统作用 操作系统功能

它是在人们使用计算机的过程中,为了管理硬件资源,提高性能提高资源利用率,而逐步地形成和完善起来的。

873
来自专栏IT米粉

Redis常见的应用场景解析

缓存是Redis最常见的应用场景,之所有这么使用,主要是因为Redis读写性能优异。而且逐渐有取代memcached,成为首选服务端缓存的组件。而且,Redis...

5358
来自专栏陈龙涛的专栏

分布式锁服务关键技术和常见解决方案

网络通信的时延和不可靠,加上分布式环境中各种故障的常态化发生,导致实现一个可靠的分布式锁服务需要考虑更多更复杂的问题。

8784
来自专栏用户画像

3.1.2覆盖和交换

早期的计算机系统中,主存容量小,虽然主存中仅存放一道用户程序,但是存储空间放不下用户进程的现象也经常发生,这一矛盾可以用覆盖基础来解决。 覆盖的基本思想是:...

571
来自专栏EAWorld

任务和调度:理解批量处理的关键设计

一、背景 1.1.什么是批量处理 1.2.批量处理拥有广泛的使用场景 1.3.批量处理需要良好的架构设计 二、批量处理中的关键设计 2.1从SpringBat...

3779

扫码关注云+社区