[原]管理OpenVZ资源-System Parameters篇
•
linux专区 今天继续OpenVZ的内容，要描述的是OpenVZ中如何控制VE可使用的System Parameters（系统参数）。这部分的内容比较繁杂，若您对Linux系统比较了解，会觉得较容易理解，但很难举例完全说明白，需要在实际使用中逐渐体会。对于系统资源，OpenVZ分三个类别：Primary、Secondary、Auxiliary。
一、参数说明
在《OpenVZ-Users-Guide》中对每个参数比较清晰的说明，这些参数都可以在各VE的配置文件中设置。其中，“num”开头的需用十进制数字定义；结尾是“buf”或者“size”的单位是bytes；参数中包含“pages”名称的，意味着在IA32普通核心下，单位为4096-bytes pages，而在ovzkernel-enterprise 核心（也就是hugmemory核心）下，单位为4096-Mbytes pages。
详细参数如下：
（我觉得这部分的不翻译可能更容易理解，故保留英文原文，含义请对比Linux系统参数体会）
![[原]管理OpenVZ资源-System Parameters篇](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiIgdmlld0JveD0iMCAwIDE2IDE2Ij48cmVjdCB3aWR0aD0iMTAwJSIgaGVpZ2h0PSIxMDAlIiBzdHlsZT0iZmlsbDojY2ZkNGRiO2ZpbGwtb3BhY2l0eTogMC4xOyIvPjwvc3ZnPg==)
下载文件
点击这里下载文件
二、VE的内存管理
上述的大部分参数，通过对比Linux环境的系统参数应该不难理解。比较容易混淆的是OpenVZ对VE内存管理部分的内容。
OpenVZ并没一个非常直接的方式来实现给某个VE多少内存的方式，也就是说，并不直接存在“给某VE使用256MB内存”这样的描述。OpenVZ为能更充分的利用资源，会通过其最小保证可用内存、最大可用内存、OOM状态保证可用内存三个方面进行控制。
在文档中并没有详细说明这部分的内容，可参考：《Virtuozzo Management of System Resources》或者wiki这里
1、先看看默认状态
以下是一台物理内存为256MB（部分共享给显卡做显存了），swap是1G的机器。
查看VE中的资源：
# vzctl exec 120 cat /proc/user_beancounters
使用基础配置文件得到的结果是：
引用
held：对应参数当前使用的资源值；
maxheld：最后一次统计时，该参数曾经使用的最大资源值；
barrier和limit：在/etc/sysconfig/vz-scripts/vpsid.conf中，参数配置值；
failcnt：在使用该资源时失败的次数，若该值在启动某应用后增加，也就是说该资源已经不足。
2、参数的含义
当前内存资源占用的情况：
引用
kmemsize：Kernel memory，核心进程使用的内存资源，这部分不能被swap，291256 bytes；
privmmpages：Private virtual memory，已经被分配的内存资源（物理内存+swap），但包括部分可能已经释放，现在没有使用的，609 pages（each page is 4Kb）；
physpages：Physical pages，在上面privmmpages中真正在用的内存资源，438 pages；
VE可用内存资源还涉及：
引用
vmguarpages：该值不会统计信息，所以“current usage”总为零，该值的barrier（6144 pages）用于保证在正常情况下，VE可分配到的最小内存页面；
可分配到的最大内存页面受privmmpages的barrier（49152 pages）限制，而对于拥有足够高的优先权的VE system进程，其还可以获得最大privmmpages的limit（53575 pages）的内存资源，但再多就没有了；
oomguarpages：其“current usage”为当前VE使用的RAM+SWAP，其barrier值（6144 pages）是OOM（内存溢出）的条件，一旦VE使用的内存资源超过该值，就会触发Linux OOM的机制，部分进程会被迫终止。
请仔细阅读上述的内容。下面计算一下提及到的数据。
3、计算内存数据
HW物理内存为256MB（部分共享给显卡做显存了），swap是1G的机器。VE数据计算。
a）当前状态
引用
# vzctl exec 120 free -m
total used free shared buffers cached
Mem: 192 2 189 0 0 0
-/+ buffers/cache: 2 189
Swap: 0 0 0
除非你另外划分Swap给VE，否则VE的Swap总为0。可用内存是：
引用
privvmpages barrier（49152）×4Kb / 1024 ＝ 192 Mb
除此之外，其他值和VE的参数并没有直接关系。
b）正常情况
引用
获得保证的最小内存资源为：
vmguarpages barrier（6144 pages）×4Kb / 1024 ＝ 24Mb
当前VE实际占用HW的物理内存资源：
physpages current value（438 pages）×4Kb ＝ 1752Kb
当前VE占用HW的RAM＋SWAP资源：
ommguarpages current value（438 pages）×4Kb ＝ 1752Kb
VE可占用的最大资源：
privvmpages barrier（49152）×4Kb / 1024 ＝ 192 Mb
VE的系统进程可最大到：
privvmpages limit（53575）×4Kb / 1024 ＝ 约209Mb
这里的资源，指的都是VE占用HW（但不包括Kernel和其他sock部分）的资源，和在VE中用free统计的数据会有些出入。
而且，并没有准确的数据告诉你，VE中那些资源可以是放在HW的RAM，还是SWAP中，这部分是由HW自行控制的，VE能获取的将是HW的RAM＋SWAP总和资源。
（这句话不完全正确，后面有例外的情况说明。）
c）OOM情况
当：
引用
ommguarpages current value（438 pages）×4Kb ＝ 1752Kb
＋
sockets buffers current value（tcpsndbuf held、tcprcvbuf held、othersockbuf held、dgramrcvbuf held）
0＋0＋2236＋0 ＝2236 bytes
＋
kmemsize current value（291256 bytes）
＝ 2087540 bytes
小于oomguarpages barrier（6144 pages × 4 Kb ×1024 ＝25165824 bytes）的时候，那么就不会发生OOM故障咯。
4、从HW中看VE的资源
HW可用的内存资源：
引用
# free -m
total used free shared buffers cached
Mem: 238 197 41 0 22 150
-/+ buffers/cache: 24 214
Swap: 1027 0 1027
若直接从HW中cat /proc/user_beancounters，虽然可以获得VE的数据，但同VE中的结果会有部分出入。另外，还可以通过下面的命令获得VE中可用内存资源占HW的大概情况：
引用
# vzcalc 120
Resource Current(%) Promised(%) Max(%)
Memory 0.77 4.44 16.86
Promised百分比：
由vmguarpages和oomguarpages中barrier部分，较大的数值除以HW的RAM＋SWAP得到。
引用
（6144×4Kb/1024）/（238＋1027）×100% = 1.89%
（由于这里设定的保证值过低，HW会自行分派一个更合理的百分比给予VE，下面扩大参数值时会更清楚。）
Max百分比：
由privvmpages的limit部分除以HW的RAM＋SWAP得到。
引用
（53575×4Kb/1024）/（238＋1027）×100% = 16.52%
5、Promised的例外
上面的结果有点出乎意料之外，Promised的运算结果并不正确。这是因为设定的值超过了HW的合理范围。
我们调大vmguarpages或oomguarpages其中一个的barrier值：
# vzctl set 120 –vmguarpages 128m:2147483647 –save
计算：
引用
128m/（238＋1027）×100% = 10.11%
结果：
引用
# vzcalc 120
Resource Current(%) Promised(%) Max(%)
Memory 0.77 10.44 16.86
6、Max的情况
把Max也调大看看。
若我们把VE的privvmpages调大，超过HW的RAM范围：
# vzctl set 120 –privvmpages 512m:1024m –save
计算：
1024m/（238＋1027）×100% =80.94%
结果：
引用
# vzcalc 120
Resource Current(%) Promised(%) Max(%)
Memory 0.77 10.44 81.18
似乎没有什么问题。再看看VE里面的情况：
引用
# vzctl exec 120 free -m
total used free shared buffers cached
Mem: 238 2 236 0 0 0
-/+ buffers/cache: 2 236
Swap: 0 0 0
可惜，结果又不是我们预期的512m。实际结果等于HW的最大可用物理内存数。
也就是说，vzcalc是按照HW的RAM＋SWAP为总数，虽然HW会根据情况分配RAM和SWAP的数据，但实际VE可用的最大内存依旧不能超过HW的RAM。
这开始我也不理解，不知道是Bug，还是担心使用SWAP做VE的内存会影响速度等原因，反正，实际环境中VE可用内存是受HW的RAM限制的。记住吧！
三、给VE分派内存
原理性和注意事项已经讲得太多了，不明白请再仔细看看。而要给VE设置可用内存其实是很简单的，只要不触及上面提到的例外情况即可。
保证VE最小可用64M内存：
# vzctl set 120 –oomguarpages 64m:2147483647 –save
# vzctl set 120 –vmguarpages 64m:2147483647 –save
两个值的barrier可以相同，也可以让oomguarpages小于vmguarpages。
最大可用内存是128M：
# vzctl set 120 –privvmpages 128m:192m –save
检查配置文件是否正确：
引用
# vzcfgvalidate /etc/vz/conf/120.conf
Validation completed: success
对配置文件的检查仅能对单个VE的配置评估而已，并不能告诉你多个VE占用HW资源是否合理。
看看结果：
引用
# vzcalc -v 120
Resource Current(%) Promised(%) Max(%)
Low Mem 0.24 4.44 4.44
Total RAM 0.77 n/a n/a
Mem + Swap 0.15 5.39 n/a
Alloc. Mem 0.19 5.39 15.49
Num. Proc 0.08 n/a 1.64
——————————————–
Memory 0.77 5.39 15.49
# vzctl exec 120 free -m
total used free shared buffers cached
Mem: 128 2 125 0 0 0
-/+ buffers/cache: 2 125
Swap: 0 0 0
四、观察VE内存是否足够
要知道VE的内存是否足够，有两种常用的方法：
1、查看free
红色标记的值比较大，表示内存可以接受。
引用
# vzctl exec 120 free -m
total used free shared buffers cached
Mem: 128 2 125 0 0 0
-/+ buffers/cache: 2 125
Swap: 0 0 0
2、查看failcnt
# vzctl exec 120 cat /proc/user_beancounters
若启动某应用后，failcnt非0，而且增加，又或者应用报错，那么很可能就是VE的内存不够了，加大内存吧。
其他参数的判断也可以参考该方法。
在Asinuax 3.0 上使用Xen 虚拟化
Asianux 4.0 中KVM 使用桥接
使用HyperVM管理OpenVZ
把物理系统搬入OpenVZ中
配置Squid 2.6实现反向代理
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/112479.html
