目錄

項目背景：主站的現狀

選型的過程

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资源控制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。