2015-08-22 补充下文档…. ….

先前这文章写的有些零散，不着调…. 今个再把文档给补充下。

题外话，我们先聊下虚拟机和docker在性能的区别. 

VM是一个运行在宿主机之上的完整的操作系统，VM运行自身操作系统会占用较多的CPU、内存、硬盘资源。
Docker不同于VM，只包含应用程序以及依赖库，基于libcontainer运行在宿主机上，并处于一个隔离的环境中.

我们的分布式爬虫里面，有个组件叫做 extractor，是做网页的各种计算、黑名单适配、正则抽取、去噪 适应数据模型的cpu运算。 最一开始这个组件是存在于虚拟机里面的，后来肯定放弃这虚拟机的方案。 这也是我上面要介绍虚拟机和docker容器的一些特性区别。 

随着公司对业务的大力支持，又随着业务的疯狂增长，光extractor计算节点就用了15台 32核94G内存的实体机来做页面运算。那么我们会选择用docker呢？  

第一个原因，每次试图在新节点部署页面计算程序，那是相当的麻烦。 所以把服务尽量封装成docker，用来做快速的部署。 

第二个原因，我们自己的其他的模块，也已经搞到docker化了，这样最大的好处就是在平台中，看到哪一层的性能不足，可以随时的拉镜像，增加节点，从部署到接入再到后期的自动化调试验证，一共也就3分钟的事情….

第三个原因，因为涉及到大量的cpu计算，我们预想到docker会性能的问题，后来我跟在韩国的kakao的朋友聊了不少，他们的一些分布式的计数运算，也是放到docker里面了。  根绝他的一些的线上性能数据，基本说服了我。  可以透露下，他们用了500个服务器，都做了docker服务，用来专门扩充计数的计算服务。  我这么时髦的人，肯定也会跟进的。   

但是问题来了，这两天把抽取服务推送到线上后，总是有种使不上劲的感觉。 单纯的看cpu top，很些不尽人意。。。 在线上跑计算组件的时候，cpu消耗一般总是在90%左右，但是用docker跑的计算组件，会发现下面的问题，忽高忽低。 我跟同事也排查了各种情况，各种strace跟踪了下，没发现有问题，系统的版本及代码的版本，各个pip安装模块版本也跟线上一样。  

这监控图表，下面的那根橘色的线是docker产生的，会发现他的性能要比实体服务器差得多… 大家会发现他的折线在后期上涨了些，是我把prefork的进程调节到了20个….  

再额外提示下：

我这边启动的时候，没有做cpu和内存的限制，启动的时候也很干净，没有下面的cpuset或者是-c参数。 

docker run -it –rm –cpuset=0-4 bj/extractor

性能慢得问题，还在查询中…..   业务的逻辑虽然设计到很多组件的调用，比如获取文章感情色彩，文章的正负面影响，redis的pop队列，hbase的put写入，mongodb的定期匹配关键字，elasticsearch的body写入。 但是前后观察了各个单元的时间消耗，基本都不到一秒，确切来说都在 0.0x秒左右。 

通过logstash的日志查看外部调用的日志，基本没啥堵塞的地方，我们可以看到tasks的时间，几乎在0.00x秒左右。 

下面是 获取文章的感情色彩和正负面的接口的情况

这两天会陆续检查处理不给力的情况 ！

补：

我们做了单元的测试，出现性能的点，确实是在调用ac自动机做关键字匹配时慢了下来….  

在国外的一些论坛，查到了关于docker比宿主机会慢得问题，这类的问题基本是涉及到了两个点，一个点是 容器内的服务做了大量的磁盘操作，docker的文件系统用的是aufs多层文件系统。 

还有一点可能是和网络io有关系，如果你的docker内的服务是做ftp，或者是下载有关系的服务，比如是yum源，docker源这类的。 这时候，你又选择的是 bridge桥接网络的模式，这个时候因为nat的关系，也会影响性能的。 

总结下，

      这是我第一次遇到docker性能有关的问题，当然我得问题有些片面性，回头我会找更多的服务来验证docker的性能问题。 

原文地址是，下面的链接就是原文……

妈蛋的，话说最近有不少网站总是爬我得网站…..   哥也是做爬虫的。  

尤其是  u . outofmemory . cn ,我干你 ！

xiaorui.cc

xiaorui.cc

xiaorui.cc

xiaorui.cc

xiaorui.cc