云计算中最关键的技术就是虚拟化技术, 用以实现不同独立应用间的资源共享. 传统的虚拟机技术由于过度的抽象化在实际生产环境中部署繁琐, 资源消耗过多, 启动速度慢. 自2013年以来, 随着以Docker为代表的新一代容器技术的快速发展, 已成为各大云计算厂商和云计算开发者的首选. 对比虚拟机技术, Docker具有应用部署灵活, 资源消耗少, 启动速度快等优点, 凭借轻量级的特性在虚拟化领域形成了颠覆性的影响^[1]. 近年来, 国内大量互联网公司也纷纷进行以新一代容器技术为核心进行技术转型, 阿里在2017年11月正式开源了其自研容器Pouch Container. 而在2018年5月的全球软件与运维技术峰会上, 知乎计算平台宣布利用Docker已实现全部业务和服务的容器化运行. 国内外的Docker相关研究^{[2, 3]}更是层出迭见, 这些现象表明新一代容器技术火热的发展趋势.

在龙芯平台虚拟化技术研究方面, 早在2013年蔡万伟等人^{[4, 5]}就已经做了大量关于MIPS架构下的内存虚拟化研究. 2016年王篁^[6]为系统级的二进制代码兼容性优化提供了解决方案. 2019年4月龙芯公司宣布龙芯KVM虚拟机产品正式发布. 而关于容器技术方面, 龙芯平台上Docker方案还是停留在比较老旧的Fedora21系统的Docker老版本上, 而新版Docker需要进一步在龙芯平台上得以支持.

鉴于X86的Fedora28系统默认安装源为1.13.1版本的Docker方案, 所以本文针对该版本进行了移植并集成到龙芯平台的Fedora28系统中, 并测试分析了新版Docker方案在龙芯平台下的性能表现, 凭借容器内测试程序稳定性更高的优势, 比较了容器内同主频下龙芯3A3000与AMD Ryzen 5 (2400 GB)的性能表现.

1 Docker技术概述

作为一个热门技术, Docker正处在快速发展的阶段, 新版本和新特性不断涌现^[7]. 1.13版本作为Docker分离社区版和企业版前的最后一个版本, Docker方案的整体架构已经逐渐稳定下来, 如图1所示.

如今的Docker^[8]方案, 对于容器整个生命周期的管理操作都由Containerd模块^[9]完成, Dockerd将创建容器和运行容器等操作直接发送给与Containerd来完成, Containerd收到请求后将启动一个Containerd-Shim进程来管理一个运行的容器, 通过Runc模块与容器进行交互. Containerd和Runc结合起来成为了容器服务标准化的两个重要部分. 同时用户可以直接在Containerd和Runc上建立包括MicrosoftAzure、VMWare在内的多种上层应用, 并不仅仅局限于Docker容器平台. 其中的Runc模块是从Docker的Libcontainer中演化过来的, 相当于Libcontainer模块结合上一个小型的客户端用以实现容器的启动停止和资源隔离等功能. 作为应用程序级的虚拟化技术, 如今的Docker中通过Runc模块, 即使绕过Daemon守护进程依然能够直接运行容器, 某种程度上来说已经不依赖于Docker本身了^[10].

2 Docker方案评测

龙芯平台上的Fedora28系统已经发布, 故本次测试将在移植Docker 1.13+版本到28系统上后, 使用测试工具对Docker方案进行测试, 其中涉及的机器配置如表1.

2.1 Docker移植

在进行具体的测评工作之前需要对相应的Docker方案进行MIPS平台的编译工作. 由于官方提供的安装方法是在容器内自动安装, 过程需要从Docker官方镜像仓库中拉取需要的Image镜像, 涉及镜像数量较多, 且大量镜像需要在MIPS平台上重新制作, 故本次实验选择手动编译的方式进行移植, 根据龙芯平台Fedora28系统的差异性对Docker源码进行调整, 添加MIPS架构入口标识, 优化不同架构平台的参数设置.

Docker方案编译工作完成后, 测试准备工作仍未完成, 由于平台架构的差异性, 测试工作中涉及的所有镜像需要重新设计. 尤其是新版本Fedora28系统的基础镜像, 为预防可能出现的镜像冗余问题, 需要重新制作一个单独的精简系统, 并保证新系统安装源的维护. 制作的Fedora28-base镜像已经推送到Docker官方仓库上, 并同步更新下载源.

2.2 测试镜像设计

为了对搭建好的Docker平台进行综合性能评估, 分析龙芯CPU上的Docker性能表现, 在综合考量大量性能测试工具后, 基于实验可重复性和简洁性的考虑, 选择结合Unixbench工具制作测试镜像. 因为Unixbench工具是一款非常经典的系统基本性能测试工具, 相对其他一些测试工具而言, 它的测试项更为全面, 而且能自动化执行一系列的测试命令, 这更加契合测试镜像的制作初衷, 提高了测试效率. Unixbench包括系统调用、IO读写、进程、2D、3D、管道、运算、C库等在内的多种性能测试, 测试结果不仅仅取决于CPU、内存、硬盘, 还关乎硬件、开发库和编译器等, 能较为全面地综合评价系统各方面性能. 而且Unixbench能将测试后的数据计算成相应的分数以供用户参考, 使测试结果更加直观简洁.

重要的是, Unixbench支持多CPU系统的测试, 默认的测试行为是两次, 第一次进行单进程测试(Running 1 Parallel Copy of Tests), 第二次则是进行当前系统CPU个数的测试(Running N Parallel Copy of Tests). 这样的测试是为了测试系统多任务下并行处理的性能, 以更为客观地表现出实际数据结果. 主要测试项如下:

(1) Dhrystone测试: 该测试用于衡量和比较计算机CPU的性能, 主要侧重于整数计算, 没有浮点计算, 受到编译器和链接器选项, 软硬件设计等影响较大.

(2) Whetstone测试: 这项主要用于测试浮点数的运算和效率, 包含大量C语言函数、浮点数的运算操作和若干科学计算的经典性能模块等.

(3) Execl Throughput测试: Execl吞吐量测试, 用于测试Execl函数每秒调用次数, Execl函数是Exec函数家族的一部分, 该函数族提供了在一个进程中启动另外一个执行程序的方法.

(4) Pipe Throughput测试: 用于测试进程间的通信, 即一秒钟一个进程写512 bite到一个管道中并读回来的次数.

(5) Pipe-based Context Switching测试: 基于管道的上下文交互测试, 这是两个进程通过管道进行通信的次数.

(6) Process Creation测试: 用于测试每秒创建进程并立刻收回的次数.

(7) Shell Scripts测试: 用于测试一定时间内进程可启停Shell脚本的次数.

(8) System Call Overhead测试: 用于测试系统调用的性能, 即重复执行getpid()函数调用时进入和离开内核的时间.

2.3 不同容器数量的测试结果

测试分别在单核系统环境和四核系统环境下进行以便分析容器下虚拟化性能损耗. 首先对龙芯单路主机进行Unixbench测试作为基准值记为Container Number = 0, 然后在不同数量的Docker容器内同时运行测试镜像进行性能测试.

这次实验中, 设容器编号(Container Number)为0时在宿主机上运行测试, 容器编号为N时在同时运行的N个容器中运行测试, 对于每次测试重复执行3次以降低误差的影响, 每一项测试结果取所有的数据结果的平均值为最终值, 即每次最终的测试数据Data_N计算如下:

$Dat{a_N} = \frac{1}{3}\sum\limits_{i = 1}^3 {\frac{1}{N}\sum\limits_{j = 1}^N {{u_{ij}}} } \left( {N \geqslant 1} \right)$

(1)

式中，u_ij表示在N个容器同时运行情况下, 第j个容器第i次的测试数据.

实际测试数据表如表2.

由于Unixbench工具出于测试系统单任务性能与多任务下并行处理性能的目的, 测试行为中有两项测试, 即单进程测试(Running 1 Parallel Copy of Tests)和当前系统CPU个数的多进程测试(Running N Parallel Copy of Tests, [CPU(N)]). 单进程测试中所有的处理器只处理一个测试进程, 而多进程测试中所有的处理器同时运行处理器数量个的测试进程. 由于单核系统环境环境下无需进行并行处理的测试, 故只有一个结果, 这个测试结果既可以看作是单核系统下的单测试任务结果, 也可以看作是多测试任务的结果. 以下的数据分析中以多测试任务结果为主.

2.4 测试结果分析

Dhrystone测试是测试处理器运算能力的基准程序之一, 是各个测试项中最能反映CPU能力的测试项, 所以着重分析这一项测试的结果, 来研究虚拟化在龙芯上的影响.

从表2中, 以测试处理器运算能力的基准程序Dhrystone测试的结果可以看出, 四核环境下的测试中, 随着同时运行测试程序的容器数量增加, 机器的字符串处理性能几近线性下降. 如图2. 而在单核测试中, 多容器下的性能以接近y=1/x函数的形式呈曲线下降, 如图3, 与基准值(单容器测试数据)相比, 双容器下Dhrystone测试性能约为54.67%, 三容器下Dhrystone测试性能约为44.16%, 四容器下Dhrystone测试性能约为33.04%. 而其他的大部分测试项, 无论在四核还是单核条件下都有相似的结果, 性能并不是呈线性下降的, 比如Execl函数测试和管道吞吐量测试等, 因为资源控制机制发挥了很大影响, 它对CPU、内存、磁盘等计算资源的使用进行了调控.

而从表2的第3部分可以看到, 在四核环境下的单进程测试(Running 1 Parallel Copy of Tests)中, Dhrystone测试的结果并没有变化, 这是由于四核环境下的系统运算能力并未完全发挥出来, 即使是在4个容器内同时运行测试任务, 也只是最大限度地体现了四核下的运算能力, Dhrystone测试的单进程测试平均结果为473.0, 稍高于单核测试中的双容器测试结果14.7%, 多进程测试平均结果为492.2, 高于基准值16.6%.

而Whetstone测试结果来看, 数据结果十分稳定, 即使在八容器的测试实验中, Whetstone测试在单进程测试中的平均结果也是200.2, 多进程下结果是794.5, 误差几乎可以忽略不计, 再结合Dhrystone测试的结果, 可以确定容器虚拟化给CPU的计算能力带来损耗非常小.

就龙芯单路主机上的测试结果和单容器测试的基准值比较, 本文发现, 在四核环境下, 主机上的Dhrystone测试结果是基准值的96.17%, 单核环境下是基准值的96.0%, 而其他的一些测试项并未有这样的结果, 因此推测, 这是由于容器内的镜像系统是轻量化的精简系统, 在测试程序执行过程中CPU对于其他可能存在的负载程序的支持更为轻松, 所以测试结果显示的相关计算能力会较为优越, 这一结果也更加体现了Docker镜像的制作对于实际应用中可能产生重要影响, 一个优越的轻量化镜像能更好地提升容器集群的性能和实际运行的流畅度.

3 龙芯平台与X86平台下的测试比较 3.1 与锐龙5处理器的对比测试

作为比较对象, X86平台下选择的是搭载AMD锐龙5处理器的机器, 硬件参数表如表3.

容器内的测试更不容易受到误差因素干扰, 可靠性和稳定性更强, 因此在实际实验中, 分别在龙芯的单路服务器、双路服务器和四路服务器上的测试容器内进行Unixbench测试, 并在搭载AMD Ryzen 5 2400 GB芯片的X86机器上运行同样的测试容器, 由于Unixbench工具的测试特性分为两项测试结果, 相关测试结果如表4和表5所示.

由于Ryzen 5(2400 GB)处理器上的CPU主频是动态的, 因此为保证测试数据的客观性和对比实验的可行性, 在BIOS选项中设置了搭载Ryzen 5处理器的主机主频, 然后通过不断读取/proc/cpuinfo文件信息, 确认主机的主频均值在1.45 GHz左右, 与龙芯双路服务器主频相近.

龙芯双路、四路服务器下CPU主频为1.45 GHz, 单路主机为1.5 GHz, 实际测试数据表如表4和表5.

3.2 测试结果分析

在单进程测试下(Running 1 Parallel Copy of Tests), 由于只有一个测试进程, 所以无论处理器的核心数量是多少, 都只有一个测试进程在执行, 相当于在一个核心上进行性能测试, 故首先可以从最能体现芯片性能的两项测试Dhrystone测试和Whetstone测试开始分析, 如图4所示.

首先从单个芯片的性能数据开始比较, 主要以MIPS_CPU(8)和X86_CPU(8)下的结果进行比较. 根据表4和图4, 可以看到在Dhrystone测试方面, 双路服务器中单核心龙芯性能分数为687.9, X86下的测试分数为1795.6, 龙芯在容器内进行Dhrystone测试的执行效率大约是Ryzen 5 (2400 GB)的38.3%, 而在与科学计算性能相关的Double-Precision Whetstone测试中, 龙芯的运算效率大约是Ryzen 5 (2400 GB)的37.4%左右, 由两个测试项数据结合确定了龙芯双路服务器在运行单个测试进程时CPU计算性能约为搭载Ryzen 5主机的40%左右. 但这仅仅是单个测试进程的结果, 而基于Unixbench测试工具的设计理念, 多进程测试的结果更为贴近实际的应用场景表现出来的性能, 因此需要着重分析多进程测试的数据结果. 根据表5, 可以得到多进程测试下的Dhrystone测试和Whetstone测试数据结果, 如图5.

从图5中很清晰地看到, 在龙芯双路服务器中, Dhrystone测试的整数计算性能约为搭载Ryzen 5主机的63.6%, Whetstone测试的浮点数计算性能约为44.8%, 后续在进行验证性测试时发现, 数据结果基本稳定在测试数据的附近区间内, 误差大约在3%左右浮动, 说明数据是可靠的. 因此可以确定, 处理器核心数量越多, 基于Dhrystone测试和Whetstone测试得到的性能分数越高, 机器整数运算性能和浮点数运算能力越强, 而相等的处理器核心数量下, 龙芯3A3000芯片的相关计算性能约为Ryzen 5(2400 GB)芯片的40~60%. 其中多进程测试下, 与Ryzen 5主机相比, 龙芯双路服务器的性能表现从38.3%提高到了63.6%, 这是由于龙芯双路服务器是八块CPU芯片, 而Ryzen 5主机只是四块CPU八核心的处理器结构. 其他项的测试可见图6和图7.

管道吞吐(Pipe Throughput)和交互测试(Pipe-based Context Switching)两项测试中, 龙芯双路服务器上的性能分数分别是2931.3和980.9, 大约为Ryzen 5 (2400 GB)下的76.3%和70.1%. 这两项测试表明在相近主频下, 龙芯双路服务器在进程通信效率上大约为Ryzen 5(2400 GB)主机的70%~76%. 其他与系统性能相关测试的还有Process Creation测试, 用于测试每秒创建进程并回收的次数, 龙芯双路服务器性能约为Ryzen 5 (2400 GB)的30%左右; Shell Scripts测试用于测试一定时间内进程可启停Shell脚本的次数, 龙芯双路服务器性能约为Ryzen 5 (2400 GB)的48%左右. 因此综合来看, 同样的Fedora28系统的容器运行环境下, 龙芯双路服务器的系统综合性能大约为Ryzen 5 (2400 GB)的50%左右.

3.3 Docker方案综合分析

首先, Docker方案在移植到龙芯Fedora28系统上之后, 运行状态良好, 稳定性可靠性大幅提升, 同时经过大量验证性实验之后可以肯定, 容器内的性能分数稍高于主机环境约5%左右, 在排除误差带来的影响之后, 体现了容器本身的轻量级技术的特性, 同时也印证了镜像构建的重要性, 可以预测一个优越的轻量化镜像能更好地提升容器集群的性能和实际运行的流畅度, 所以在后续构建和维护龙芯平台的Docker镜像仓库中同样需要秉持认真负责的态度.

其次, 本文发现多容器状态的测试数据并不稳定, 而且产生了一些性能损失, 这是因为容器对于资源管理功能的实现仍然深深依赖与Linux系统内核的自身特性, 由于Docker方案本身就是基于传统LXC技术实现的应用程序容器技术^[10], 旨在提供标准运行环境, 实现底层操作系统与物理主机的解耦. 因此, 在容器数量增加到一定程度后, 可以预见到容器间资源的不合理行为会变得十分频繁从而影响整个的容器集群. 从本次测试的多容器数量的性能趋势中可窥一斑, 所以在之后的实验研究中, 将把研究重点放到容器的动态调度算法和集群负载均衡策略优化上去, 通过容器调度策略等设计优化容器的实际应用环境.

同时, 根据借助容器环境在Ryzen 5 (2400 G)处理器上实现的对比实验, 本文发现, 目前主流的龙芯芯片3A3000与Ryzen 5 (2400 GB)芯片相比CPU计算性能约在60%左右, 这是龙芯双路服务器与八核的Ryzen 5 (2400 GB)机器在进行多进程测试时比较得到的结果. 如果就单进程测试而言, 龙芯3A3000的性能大约是Ryzen 5 (2400 GB)的一半, 如果综合考虑所有系统性能测试项, 龙芯双路服务器的综合评分大约有搭载Ryzen 5 (2400 GB)主机的50%左右.

4 结束语

经过分析本文得到以下结论: 一是龙芯平台上的新版Docker方案适应性良好, 稳定性可靠性大大提高, 并且发现轻量化的镜像会略微提升容器内隔离进程的运行效率, 这体现了容器本身的轻量级技术的特性, 同时也印证了镜像构建工作的重要性; 二是通过性能数据的渐变趋势, 可以预测高容器数量级下整个集群系统性能会产生很大损失, 仅仅依赖Linux内核特性进行资源管理是远远不够的, 所以下一步研究将集中在容器集群模式下的负载均衡策略和动态调度算法设计上去; 三是在容器中, 经过与Ryzen 5 (2400 GB)芯片的对比实验发现, 根据Dhrystone测试和Whetstone测试结果, 龙芯3A3000芯片在CPU计算性能方面大约是Ryzen 5 (2400 GB)芯片性能的40%~60%左右, 多进程测试中Dhrystone测试性能约为Ryzen 5 (2400 GB)的63.6%. 综合考虑所有系统性能测试项, 龙芯双路服务器的综合性能评分大约为搭载Ryzen 5 (2400 GB)主机的50%左右. 但是微架构优化后的下一代龙芯3A4000芯片即将推出, 性能方面将会有更大的提升, 国产化CPU事业会发展的越来越好.