这几年互联网公司都在搞降本增效，以前依靠堆机器跑起来的服务，现在都需要重构，想方设法提升机器的资源利用率。将多个不同的服务部署在同一台机器上，是最直接的提升资源利用率的方法。实践中发现，混合部署的方式不对，模块间也会相互影响，从而带来性能问题。

我们的模块对外提供在线视频转码服务，计划是与一个提供数据存储服务的模块混合部署在一台24核128G的机器上。两个模块各分配8个核心、16G内存资源，通过cgroup对资源进行隔离。

初期的设想是两个模块消耗的资源类型不同，也通过cgroup机制进行隔离，理论上模块间不会产生影响。然而，测试发现，混合部署后同一个处理请求的处理延时出现了毛刺性抖动。

 经过多次测试分析，发现有以下现象：

• 独立模块部署，同一个处理请求处理耗时比较稳定，没有抖动。
• 混合部署的存储模块负载越高，转码模块的处理耗时抖动越明显，毛刺越大。
• 同样的计算资源，混合部署后转码模块的QPS下降20%左右。

显而易见，混合部署后两个模块间产生了相互影响，转码模块的处理性能出现了明显下降，主要还是处理延时出现增长，这对用户体验产生了影响，是不可接受的。

在混合部署时，我们已经使用cgroup对模块进行了隔离，为啥还会产生相互影响？

cgroup是linux 下一种将进程按组管理的机制，可以用来限制进程使用的CPU、内存、网络、磁盘等硬件资源的配额。就隔离CPU资源，cgroup提供了3种机制。（控制组，可以是一个或者多个进程)

• 时间片隔离：用于配置在一个CFS调度周期内，允许此控制组执行的时间。
• CPU隔离：为控制组分配独立的处理器和内存节点，隔离性较高。
• 权重隔离：限制控制组可使用CPU资源的下限，当CPU有空闲时，控制组可以占用更多的资源。

运营同学在调研时，发现docker 底层也是使用cgroup技术来实现容器间的资源隔离，默认采用的是时间片隔离机制，查看转码模块的cgroup配置文件发现，采用的也是时间片隔离机制，大概率是参考了docker的实现。

从上面的描述来看，时间片隔离并没有真正的隔离CPU资源，模块间还是共享CPU资源、不同模块的线程还是有机会运行在同一个CPU上。

联想到操作系统相关知识，每个CPU都有自己的L1、L2级高速缓存，当CPU执行的进程发生切换时，需要更新高速缓存里面的进程数据，频繁的更新数据会带来延时的增长。

从上述cgroup隔离机制来看，采用CPU隔离的形式，理论上两个模块几乎不会相互影响。 采用CPU隔离以后，延时抖动数据如下。

• 转码模块的平均处理耗时、QPS表现很平稳，与独立部署时保持一样。
• 转码模块的性能，不会随着存储模块负载变化而变化，相互间不会产生影响，
• cgroup在绑定CPU核心时，要绑定CPU的物理核心，绑定超线程核心等效于不绑核。

为了分析时间片隔离与绑核隔离的性能差异原因，我们分析了这两个场景下CPU的cache-misses比例，比例越高代表cache命中率越低，程序的性能越差。

使用时间片的cgroup隔离机制下cache-misses 达到37.19% ，使用CPU的cgroup隔离机制下cache-misses比例只有 26.08% ，两者相差11%左右。

多模块同机混合部署时，要考虑到模块间是会产生相互影响的，要根据服务的类型选择合适的隔离机制，减少对服务性能的影响。

• 对于IO密集性的服务而言，大部分时间都在等待IO处理，CPU缓存命中率带来的延时抖动对整体性能影响较小，使用cgroup隔离可以考虑时间片方式。
• 对于CPU密集性的服务而言，大部分时间都在做计算逻辑对CPU的占用较高、CPU缓存命中率带来的延时抖动对整体性能影响较大，使用cgroup隔离可要谨慎考虑时间片方式。
• 使用cgroup隔离时，单纯的使用绑定CPU的方式，无法实现服务器资源的超卖，对整体收益不利。

欢迎关注下方公众号，获取最新技术文章。