Docker的性能损耗：以基因组分析流程为例

IBM Research在2014年的一篇论文中，曾对比了Docker容器和虚拟机对CPU和内存的性能损耗，相比传统虚拟机技术，容器的性能更佳。那么对比物理机，Docker的性能又是怎样的呢？

2015年9月的一篇论文『The impact of Docker containers on the performance of genomic pipelines』，通过对比基因组分析流程在物理机和Docker环境中运行，所花费的时间，评估Docker带来的性能损耗。

‌‌

以下为译文（计算生物学部分翻译若有不准确之处，还请理解）：

简介

基因组程序通常会涉及多个第三方的软件，这些应用有很多是学院派的原型应用，安装、配置和部署都有一定困难。因为在一个特定环境中运行的程序，对其它程序，库和组件有很多隐含的依赖。这样一来，在一个环境中构造出来的计算分析流程，很难在另一个环境中顺利地运行起来。而且实验数据的经常变化，也造成了部署和生产环境中的很多问题。

过去，我们会采用虚拟化技术来处理这种问题。但是，这种方式有一些重大缺陷。虚拟机镜像非常大（通常是几GB），因为他们需要一个操作系统的完整复制。即使是一个文件的添加或更改，也需要重新配置和部署整个虚拟机。而且虚拟机内软件或数据的重用也几乎是不可能的，因为其内容不是系统描述的，也不能通过标准的工具/协议访问。

最近，Docker技术已经引起了科学类社区的广泛关注，因为它能让应用运行在一个隔离的，自包含的软件包中，实现快速分发和跨多个平台的执行。

其最显著的优势是将繁琐的软件安装过程，简化成了下载一个事先build好的，随时能运行起来的镜像，镜像中包含了所有的软件及其需要的配置。

Docker的另一个优势在于每个进程运行在相互隔离的容器中，避免了同一个主机环境中多个程序的冲突，同时保证了每个进程运行在一个可控的系统配置中，即使后续对软件的错误配置，系统更新或程序错误也不会影响这个环境。

那么问题来了，Docker会不会影响整个分析流程的性能？

IBM Research的研究显示Docker容器对CPU和内存造成的性能损耗是很小的，相比传统虚拟机技术，容器的性能更佳。

那Docker和物理机相比的性能损耗是多少呢？本文我们将通过现实的计算生物学场景，来评估Docker容器对基因组分析流程的性能影响。

方法

为了评估Docker对计算生物学工具的性能影响，我们模拟了三种不同的基因组分析流程，来做基准测试，分别在Docker和物理机的环境下，处理同一组数据。硬件环境是HP BL460c Gen8，12 核CPUIntel Xeon X5670 (2.93 GHz)，96GB RAM，操作系统是ScientificLinux 6.5 (kernel 2.6.32-431.29.2.el6.x86_64)。

Docker的版本是1.0，device mapper作为存储驱动。Docker镜像的base image是Scientific Linux 6.5，计算节点是专为这个基准测试预留的（其它工作负载不会被分发到这个节点上），另外，为了防止任何网络延迟影响执行时间，所有测试都将节点的本地硬盘作为主要存储。

这三个分析流程都通过Nextflow开发，Nextflow可以简化计算流的跨平台部署，并且支持Docker。这样一来，不改代码，就可以把相同的分析流程运行在本地或Docker两种环境中，只需要在Nextflow中简单修改Docker镜像的配置文件。

需要说明的是，基于Docker的实现方式并不是说所有的分析流程都运行在一个容器中，而是每个从分析流程分隔出来的任务都运行在各自的容器中。容器的工作路径被设定到Dockervolume中，这个volume被挂载到主机文件系统的一个本地目录中。这样一来，各个任务之间可以共享数据，也不影响分析流程的执行流程。每个任务还能使用不同的镜像，使用网络共享存储（比如NFS）的集群还能实现无缝扩展。

每组基准测试中，通过在Docker和物理机，分别运行10个实例并计算平均运行时间，再进行比较。由于整个分析流程分为多个并行的任务，整个工作的执行时间为所有任务执行时间的总，具体计算方式是启动和完成的系统时间戳之差，所以其中包含了容器的实例化时间开销（不包含pull镜像的时间）。

基准测试 1

第一个基准测试的分析流程是转录组测序（RNA-Seq）数据分析。

这个分析流程将原始的RNA-Seq序列作为输入，然后按照序列比对，回贴（map）到参考基因组和转录注释。回贴信息通过参考的转录注释，确定各个转录本的表达量。每一个进程样本，会生成一个所有转录组相对表达量的table。

同一组数据将分别在Docker和物理机环境中分别被处理10次。转录组测序（RNA-Seq）数据取自ENCODE项目（ENOCDE，Encyclopedia of DNA Elements。ENCODE是一个大规模基因注释工程，旨在描述基因组中所编码的全部功能性序列元件），分别从两只幼鼠（一只14天，一只18天）脑部样本数据中随机抽取。

每个完整分析流程包含9个任务：Bowtie运行一个index任务（为基因组创建索引），Tophat2运行4个mapping的任务（序列回帖到基因组），Cufflinks来运行4个transcript的任务（用回帖到基因组的短序列来拼接转录本）。Mapping和transcript的任务是并行执行的。软件版本分别是Samtools 0.1.18，Bowtie2 2.2.3，Tophat-2.0.12，Cufflinks 2.2.1。

整个分析流程在物理机环境下的平均执行时间是1156.0分钟（19h 16m 14s），在Docker环境下的平均执行时间是1158.2分钟（19h 18m 14s），所以容器带来的开销大概在0.1%（见表1及图1）。

表1：三组测试中，Docker环境下和物理机环境下的耗时对比

图1：RNA-Seq分析流程时间对比

基准测试 2

基准测试 2是基于『Minimum Information for Reporting NextGeneration Sequencing Genotyping” (MIRING)』的基于拼接的突变鉴定流程，用于组织相容性，免疫遗传和免疫基因的应用。

针对人类白细胞抗原（HLA，human leukocyte antigen）和杀伤细胞免疫球蛋白样受体（KIR，killer-cell immunoglobulin-like receptor），做了双端测序（Paired-end genomic reads）序列，被排列到人类参考基因组中，并用来做突变鉴定。

同样，这个分析流程会在Docker和物理机环境下分别执行10次，具体的工具和版本为：ngs-tools 1.7，SSAKE 3.8.2，BWA0.7.12-r1039和Samtools1.2。

每个分析流程运行48个任务，最多可并行的任务数被设为10，大多数任务可以在几秒内完成，只有SSAKE任务需要2-3.5小时。

这个分析流程在物理机的平均执行时间是1254.0分钟（20h 53m 58s），Docker环境下的时间是1283.8分钟（21h 23m 50s），Docker带来了大概2.4%的额外开销。（见表1及图2）

图2：Variant Calling 分析流程时间对比

基准测试 3

最后一个基准测试使用了Piper-NF（https://github.com/cbcrg/piper-nf），一个用于检测和回帖长链非编码RNA(long non-coding RNA，lncRNA)的分析流程。

和前两次一样，整个分析流程会在Docker环境和物理机环境中分别被执行10次，所用工具为T-Coffee 10.00.r1613， NCBI BLAST 2.2.29+， Exonerate 2.2.0。每个工作流被分为98个任务，可以并行执行的任务数为10。

在物理机所用的平均时间是58.5分钟，Docker环境下的平均时间是96.5分钟。Docker带来的额外开销在65%左右（见表1）。

主要原因在于，这个分析流程的执行包括多个短的实时任务，任务的平均执行时间是35.8s，中值是5.5s。这样一来，由Docker启动程序和挂载主机文件系统所带来的时间开销，相比很短的任务就变得不容忽视了。（见图3）

图3：Piper-NF分析流程时间对比

结论

在这篇论文中，我们评估了Docker技术对基因组分析流程的性能影响，结果显示，对于基因组分析流程这种耗时较长的计算任务，Docker所产生的性能损耗是微不足道的。这些损耗完全可以被Docker带来的好处所抵消。

然而越是小型的作业，Docker产生的性能损耗也更明显，因为作业如果只有几秒或几毫秒，容器的启动时间就会变得不容忽视。

另外，每个基准测试分别进行的10次实验中，时间差别都很小，说明Docker隔离的环境受到外部影响较小。

在评估容器技术时，其它对容器执行的性能没有直接影响的因素也应该考虑在内：

Docker镜像虽然比虚拟机镜像要小，但需要从远程的镜像库下载，所需的时间决定于网络环境和镜像大小。可以安装一个本地的mirror将镜像缓存到本地网络中，以加速下载；

在容器规模小的情况下，Docker用起来很简单，但是将一个多步骤的分析流程Docker化并不容易，可能每个步骤都需要执行不同的容器，可能会引起不必要的复杂性。类似Nextflow的工具可以极大地简化这个过程；

Docker技术还很年轻，存在潜在的安全问题；

最后，Docker只能运行在基于Linux的操作系统中，Mac OS-X和Windows系统还需要先安装Linux虚拟机。

虽然本文中所考虑的是一个特定生物信息学工具和数据分析分析流程，我们希望这项工作对其它有类似的资源需求和任务粒度场景也能起到参考作用。

所有实验数据都可以在GitHub上找到：https://github.com/cbcrg/docker-benchmarks

论文链接：https://peerj.com/articles/1273/

原文链接：http://www.jianshu.com/p/ad5bc1874976

Docker的性能损耗：以基因组分析流程为例相关推荐

Go gomaxprocs 调高引起调度性能损耗
先前在社区里分享了关于 golang 行情推送[1]的分享,有人针对 ppt 的内容问了我两个问题,一个是在 docker 下 golang 的 gomaxprocs 初始化混乱问题,另一个是 gol ...
Go gomaxprocs 调高会引起调度性能损耗
先前在社区里分享了关于 golang 行情推送[1]的分享,有人针对 ppt 的内容问了我两个问题,一个是在 docker 下 golang 的 gomaxprocs 初始化混乱问题,另一个是 gol ...
unity使用Sprite Editor图片切割功能减少性能损耗
在unity里利用Sprite Editor切割本图片为多张图片,让Batches和SetPass calls的值处于最小值,用以减少性能损耗. 上图可以见到,尽管图片有十多张,但是Batches和S ...
宏基因组分析流程报错与解决
宏基因组分析流程报错与解决 microbiome_helper流程报错 kneaddata质控 metaphlan_to_stamp.pl metaphlan2流程报错前言:坑有时候就是这么出其不意 ...
微生物组助手——最易学的扩增子、宏基因组分析流程
软件简介 Microbiome Helper开源软件,方便大家分析微生物组数据.不仅提供了多套扩增子.宏基因组的分析流程方案,同时提供了几十个软件间衔接的脚本,可大大提高使用者分析的效率. 文章于20 ...
Mysql中where条件一个单引号引发的性能损耗
日常写SQL中可能会有一些小细节忽略了导致整个sql的性能下降了好几倍甚至几十倍,几百倍.以下这个示例就是mysql语句中的一个单引号('')引发的性能耗损,我相信很多朋友都遇到过,甚至还在这样写. ...
性能测试总结(二)---测试流程篇
本文主要介绍下性能测试的基本流程,性能测试从实际执行层面来看,测试的过程一般分为这么几个阶段,如下图: 下面分别介绍下每个阶段具体需要做什么: 一.性能需求分析: 性能需求分析是整个性能测试工作开展的 ...
性能测试方法及基本流程
1 简介随着应用软件用户负载的增加和愈来愈复杂的应用环境,用户的响应速度.系统的安全运行等性能问题逐渐成为软件系统必须考虑的指标之一.性能测试通常通过自动化的测试工具模拟多种正常.峰值以及异常负载 ...
2021.11.16【读书笔记】丨宏基因组分析流程
本次笔记为美格基因宏基因组课程笔记目录 1. quality control 2. Reads-based分析 2.1 物种分类鉴定 2.2 揭示物种多样性 2.3 功能分类鉴定 2.4 数据库和比 ...

Docker的性能损耗：以基因组分析流程为例

Docker的性能损耗：以基因组分析流程为例

Docker的性能损耗：以基因组分析流程为例相关推荐

最新文章

热门文章