淘宝主站Cgroup资源控制

项目背景：主站的现状

选型的过程

Cgroup/LinuxContainer介绍

定制和开发

存在的问题和对策

项目背景

主站：

跑在xen虚拟机上的Java应用
处理业务逻辑，本地无重要存储，无状态。
一台物理机部署3台虚拟机
双路Xeon，48GB内存
多数应用是非交易相关的
有1/3虚拟机峰值Load小于0.5
基本无磁盘IO，主要资源需求集中于cpu和内存
机器数量非常多

我们需要什么

一台物理机跑更多虚拟机
更好的组合应用，做到集群利用率均衡
消耗资源多的和少的部署在一起
核心应用和非核心部署在一起
如果某台虚拟机流量上升需要更多资源，给它分配的内存和cpu也增加，反之亦然。
不增加监控、运维成本

OS层次上的虚拟化

Operating system-level virtualization
各种称呼, “containers”, “jails”, 增强的chroot
Container是安全容器与资源容器的组合
安全容器：chroot, UID/PID/IPC/Network Namespace
资源容器：Control Cgroup(Cgroup)

实现

Linux ▪ OpenVZ, Linux-VServer, LinuXContainer(LXC)

Solaris Zones

FreeBSD Jails

Cgroup

LXC = Namespace + Cgroup
基于进程组的资源管理
基础框架+ 子控制器

使用Cgroup的分组机制，对一组进程就某种系统资源实现资源管理。

cpuset子控制器

为进程组分配一组允许使用的CPU和内存结点

memcg子控制器

限制进程组允许使用的物理内存

只限制匿名页和Page Cache，不包括内核自己使用的内存

内存紧张时使用与全局回收同样的算法在组内回收

Blkio子控制器

限制进程组的磁盘IO带宽

实际控制的是磁盘为各进程组服务的时间片数量，和进程调度器cfs针对cpu的分时服务原理相同

实际使用的方案

虚拟化方案比较

Contains的优势和劣势

优点

虚拟化开销小，一台物理机跑很多“小”虚拟机
通过Cgroup增减CPU/内存非常方便，调整速度很快
和本地环境相同的速度

缺点

不能热迁移-----调度流量，而不是调度机器
不能模拟不同体系结构、装不同os------不需要
安全隔离差-------内部集群，由运维操作
ForkBomb、优先级反转、Cgroup实现缺陷
见招拆招 ▪ Memcg不能控制buffer和内核内存
Proc下的多数文件不认识Container，top/sar/free/iostat 都用不了
自己按需求修改内核

性能监控

/proc没有“虚拟化”
为每个Container计算Load和CPU利用率

社区已有部分Patch，但没被接受

Upstream内核中为了提高SMP伸缩性，计算Load变得非常复杂—而且有Bug，幸好我们目前不需要

如何表示与自己共享CPU的其他Container占用的 CPU时间？借用半虚拟化中的steal time概念

为每个Container维护/proc/meminfo

社区已有部分Patch，但仍然不被接受

Buffer列只能显示零

内存总量即为Cgroup允许的该容器内存上限

弹性内存分配

Cgroup可以动态调整内存上限，但Hotspot 的GC堆大小是启动时设定的
基本想法：在内存紧张时，“摘掉”GC堆中垃圾对象所占的物理内存

内存紧张可能由于全局内存缺乏，也可能由于 cgroup组内内存不足

仍然不能让GC堆扩大，但可以一开始就设个比较大的值(overcommit)，在资源紧张时让其缩小

对GC堆上限(-Xmx)和memcg上限(hard limit)这两个参数不再敏感

重新思考最基础的设计
Hotspot 的GC堆大小(-Xmx)和memcgroup的上限(hard limit)如何取值？堆内和堆外内存应该给多少？
内存满了会发生什么？

匿名页被交换到磁盘上

Page cache页直接丢弃，脏页丢弃前先回写

部署大量Java应用时内存主要是GC堆的匿名页

垃圾所占匿名页从其失去最后一个引用之时起到下次GC之时止不会被访问，被交换出去的概率相对更大

把垃圾交换到磁盘上是一种浪费

很多细节

有许多Container，该回收谁的内存？

Shares: Container的权重，我们在这里使用其允许使用的最大内存总量做为权重

Pages: Container实际使用的内存量  回收倾向= Shares / Page，越小越容易被选中

希望的行为

Container活跃时得到允许范围内尽可能多内存

Container的工作集缩小(不活跃)时剥夺它的内存

引入内存活跃程度百分比α，通过定期扫描页得到

引入不活跃内存惩罚系数idle_tax∈[1, +∞)

回收倾向= Shares / Pages * (α + idle_tax * (1 – α) )

算法来自Vmware ESX Server

遗留问题

内存还剩多少时触发？

Full GC时Young Gen中活对象先整体提升，所以内存使用量可能出现先升后降的现象

Full GC用时远长于一次kswapd活动，内存用量在Full GC期间可能继续上涨至direct reclaim

必须考虑和Page cache用量的平衡

目前只支持ParallelGC collector，不支持CMS
numaaware

目前实现把每个numa结点视为单独的机器计算

然而ParallelGC collector不是numa-aware的，被某个内存紧张的结点挑中的Container回收到的内存未必在这个结点上

内存压力有可能来自于应用内存持续泄露，此时oom比触发GC来回收内存更好

淘宝主站Cgroup资源控制相关推荐

拳王虚拟项目公社：淘宝虚拟货源怎么找？在哪里找虚拟资源，虚拟产品如何找到?
淘宝的虚拟货源从哪来?卖家要知道虚拟产品有什么技巧?很多小伙伴开店开站卖的是虚拟产品,为什么新手更愿意选择虚拟产品开店呢? 因为,虚拟店铺的成本非常低.利润却很高,相对于非虚拟的店铺,虚拟店铺是非常具 ...
淘宝海量数据产品的技术架构
原文地址:http://www.cnblogs.com/Mainz/p/3638370.html 淘宝海量数据产品的技术架构是什么,又是如何应对双十一的海量访问的?先看图: 按照数据的流向来划分,我们 ...
阿里淘宝海量级数据技术架构
架构图按照数据的流向来划分,我们把淘宝数据产品的技术架构分为五层(如图1所示),分别是数据源.计算层.存储层.查询层和产品层.位于架构顶端的是我们的数据来源层,这里有淘宝主站的用户.店铺.商品和交易 ...
淘宝应对双11的技术架构分析
双"11"最热门的话题是TB ,最近正好和阿里的一个朋友聊淘宝的技术架构,发现很多有意思的地方,分享一下他们的解析资料: 淘宝海量数据产品技术架构数据产品的一个最大特点是数据的非 ...
python爬取淘宝数据魔方_淘宝数据魔方技术架构解析
淘宝网拥有国内最具商业价值的海量数据.截至当前,每天有超过30亿的店铺.商品浏览记录,10亿在线商品数,上千万的成交.收藏和评价数据.如何从这些数据中挖掘出真正的商业价值,进而帮助淘宝.商家进行企业 ...
淘宝彩票移动项目开发实践
转自:http://ued.taobao.com/blog/2012/10/11/%E6%B7%98%E5%AE%9D%E5%BD%A9%E7%A5%A8%E7%A7%BB%E5%8A%A8%E9%A ...
淘宝帝国是如何创建的连载03
第三部分----我在淘宝这八年 2011年12月8日那天,有同事恭喜我,我才知道自己在淘宝已经七周年了.很多人问"七年痒不痒?"老实说,也曾经痒过, 但往往都是一痒而过,然后又投入 ...
从P1到P7——我在淘宝这7年
从P1到P7--我在淘宝这7年作者: 赵超发布时间: 2012-02-25 14:47 阅读: 159999 次推荐: 217 [收藏] (一) 2011-12-08 [原文链接] ...
第12年双11｜技术总指挥汤兴：淘宝确实变了
总交易额达4982亿元. 订单创建峰值58.3万笔/秒. 这是今年双11我们创下的新纪录. 对于背后支撑的淘系技术体系来说,也是新的技术峰值. 在应对并发流量和系统稳定性上,淘系一直在和自己赛跑. 每 ...

淘宝主站Cgroup资源控制

淘宝主站Cgroup资源控制相关推荐

最新文章

热门文章