如何做网站后台管理系统,知识付费网站建设,帮做网站,医疗器械行业前景目录
项目背景#xff1a;主站的现状
选型的过程
Cgroup/LinuxContainer介绍 定制和开发
存在的问题和对策 项目背景 主站#xff1a;
跑在xen虚拟机上的Java应用 处理业务逻辑#xff0c;本地无重要存储#xff0c;无状态。 一台物理机部署3台虚拟机 双路Xeon#…目录
项目背景主站的现状
选型的过程
Cgroup/LinuxContainer介绍 定制和开发
存在的问题和对策 项目背景 主站
跑在xen虚拟机上的Java应用 处理业务逻辑本地无重要存储无状态。 一台物理机部署3台虚拟机 双路Xeon48GB内存 多数应用是非交易相关的 有1/3虚拟机峰值Load小于0.5基本无磁盘IO主要资源需求集中于cpu和内存 机器数量非常多我们需要什么
一台物理机跑更多虚拟机 更好的组合应用做到集群利用率均衡 消耗资源多的和少的部署在一起 核心应用和非核心部署在一起 如果某台虚拟机流量上升需要更多资源 给它分配的内存和cpu也增加反之亦然。 不增加监控、运维成本
OS层次上的虚拟化
Operating system-level virtualization 各种称呼, “containers”, “jails”, 增强的chrootContainer是安全容器与资源容器的组合安全容器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下的多数文件不认识Containertop/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来回收内存更好
