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 条评论
登录 后参与评论

相关文章

来自专栏张善友的专栏

从APM角度上看:NoSQL和关系数据库并无不同

Michael Kopp拥有十年以上C++、Java/JEE的架构及开发经验,现Compuware技术策略师,专攻大规模产品部署的架构和性能。 以下为译文: 传...

2338
来自专栏JAVA高级架构

浅谈 MySQL 集群高可用架构

新年快乐 前言 高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用。对于一个系统而言,可能包含很多模块,比如前端应用,缓存,数据库...

37415
来自专栏CSDN技术头条

创建一个分布式网络爬虫的故事

编者按:作者通过创建和扩展自己的分布式爬虫,介绍了一系列工具和架构, 包括分布式体系结构、扩展、爬虫礼仪、安全、调试工具、Python 中的多任务处理等。以下为...

2348
来自专栏ImportSource

故障驱动的微服务架构设计

此文背景: 之所以发布此文,是有一个直接的原因,就是我们之前在线上遇到了一个使用timeout来判断是否失败的案例,这是真实的,结果就是效果很不好。看了本文中介...

4987
来自专栏EAWorld

微服务来了,配置怎么办?

配置管理是个简单的小话题,程序员都已经非常熟悉,咋就跟微服务挂上钩了呢? 前些年没提微服务架构的时候,大家也都会做配置管理相关的事情,比如我接触过的很多项目都做...

3566
来自专栏织云平台团队的专栏

如何优雅地实现高可用系统?

3679
来自专栏开源项目

实用的国产优秀开源中间件 | 码云周刊第 52 期

在系统软件之中,操作系统、数据库、中间件的三驾马车,中间件是最神秘的,而且是一个专业化非常强的细分产业。中间件技术主要用来支撑分布式软件的开发,在大型分布式软件...

4498
来自专栏PPV课数据科学社区

【重磅】33款可用来抓数据的开源爬虫软件工具

要玩大数据,没有数据怎么玩?这里推荐一些33款开源爬虫软件给大家。 爬虫,即网络爬虫,是一种自动获取网页内容的程序。是搜索引擎的重要组成部分,因此搜索引擎优化很...

6644
来自专栏架构师之路

即使删了全库,保证半小时恢复

近期一篇《就这样把根目录删了!!!》引发了广泛的讨论,《如何防止根目录被删》汇总了7种防删方案。还有同学评论中反馈“不小心把库删了”,如何快速恢复删掉的数据库,...

4065
来自专栏lulianqi

为什么需要多线程

对于这个问题可能很多朋友会说是为了高性能,个人觉得这是误解,多线程不等于高性能,从cpu(单核)的角度上看单线程才能带来最高性能。

1172

扫码关注云+社区