Dec
28
[原]管理OpenVZ资源-System Parameters篇
今天继续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系统参数体会)
二、VE的内存管理
上述的大部分参数,通过对比Linux环境的系统参数应该不难理解。比较容易混淆的是OpenVZ对VE内存管理部分的内容。
OpenVZ并没一个非常直接的方式来实现给某个VE多少内存的方式,也就是说,并不直接存在“给某VE使用256MB内存”这样的描述。OpenVZ为能更充分的利用资源,会通过其最小保证可用内存、最大可用内存、OOM状态保证可用内存三个方面进行控制。
在文档中并没有详细说明这部分的内容,可参考:《Virtuozzo Management of System Resources》或者wiki这里
1、先看看默认状态
以下是一台物理内存为256MB(部分共享给显卡做显存了),swap是1G的机器。
查看VE中的资源:
使用基础配置文件得到的结果是:
表示意思是:
2、参数的含义
当前内存资源占用的情况:
VE可用内存资源还涉及:
请仔细阅读上述的内容。下面计算一下提及到的数据。
3、计算内存数据
HW物理内存为256MB(部分共享给显卡做显存了),swap是1G的机器。VE数据计算。
a)当前状态
除非你另外划分Swap给VE,否则VE的Swap总为0。可用内存是:
除此之外,其他值和VE的参数并没有直接关系。
b)正常情况
这里的资源,指的都是VE占用HW(但不包括Kernel和其他sock部分)的资源,和在VE中用free统计的数据会有些出入。
而且,并没有准确的数据告诉你,VE中那些资源可以是放在HW的RAM,还是SWAP中,这部分是由HW自行控制的,VE能获取的将是HW的RAM+SWAP总和资源。
(这句话不完全正确,后面有例外的情况说明。)
c)OOM情况
当:
小于oomguarpages barrier(6144 pages × 4 Kb ×1024 =25165824 bytes)的时候,那么就不会发生OOM故障咯。
4、从HW中看VE的资源
HW可用的内存资源:
若直接从HW中cat /proc/user_beancounters,虽然可以获得VE的数据,但同VE中的结果会有部分出入。另外,还可以通过下面的命令获得VE中可用内存资源占HW的大概情况:
Promised百分比:
由vmguarpages和oomguarpages中barrier部分,较大的数值除以HW的RAM+SWAP得到。
(由于这里设定的保证值过低,HW会自行分派一个更合理的百分比给予VE,下面扩大参数值时会更清楚。)
Max百分比:
由privvmpages的limit部分除以HW的RAM+SWAP得到。
5、Promised的例外
上面的结果有点出乎意料之外,Promised的运算结果并不正确。这是因为设定的值超过了HW的合理范围。
我们调大vmguarpages或oomguarpages其中一个的barrier值:
计算:
结果:
6、Max的情况
把Max也调大看看。
若我们把VE的privvmpages调大,超过HW的RAM范围:
计算:
1024m/(238+1027)×100% =80.94%
结果:
似乎没有什么问题。再看看VE里面的情况:
可惜,结果又不是我们预期的512m。实际结果等于HW的最大可用物理内存数。
也就是说,vzcalc是按照HW的RAM+SWAP为总数,虽然HW会根据情况分配RAM和SWAP的数据,但实际VE可用的最大内存依旧不能超过HW的RAM。
这开始我也不理解,不知道是Bug,还是担心使用SWAP做VE的内存会影响速度等原因,反正,实际环境中VE可用内存是受HW的RAM限制的。记住吧!
三、给VE分派内存
原理性和注意事项已经讲得太多了,不明白请再仔细看看。而要给VE设置可用内存其实是很简单的,只要不触及上面提到的例外情况即可。
保证VE最小可用64M内存:
两个值的barrier可以相同,也可以让oomguarpages小于vmguarpages。
最大可用内存是128M:
检查配置文件是否正确:
对配置文件的检查仅能对单个VE的配置评估而已,并不能告诉你多个VE占用HW资源是否合理。
看看结果:
四、观察VE内存是否足够
要知道VE的内存是否足够,有两种常用的方法:
1、查看free
红色标记的值比较大,表示内存可以接受。
2、查看failcnt
若启动某应用后,failcnt非0,而且增加,又或者应用报错,那么很可能就是VE的内存不够了,加大内存吧。
其他参数的判断也可以参考该方法。
一、参数说明
在《OpenVZ-Users-Guide》中对每个参数比较清晰的说明,这些参数都可以在各VE的配置文件中设置。其中,“num”开头的需用十进制数字定义;结尾是“buf”或者“size”的单位是bytes;参数中包含“pages”名称的,意味着在IA32普通核心下,单位为4096-bytes pages,而在ovzkernel-enterprise 核心(也就是hugmemory核心)下,单位为4096-Mbytes pages。
详细参数如下:
(我觉得这部分的不翻译可能更容易理解,故保留英文原文,含义请对比Linux系统参数体会)
下载文件
二、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:在使用该资源时失败的次数,若该值在启动某应用后增加,也就是说该资源已经不足。
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;
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的机制,部分进程会被迫终止。
可分配到的最大内存页面受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
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
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
+
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
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
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
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
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
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
# 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
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
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
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的内存不够了,加大内存吧。
其他参数的判断也可以参考该方法。
Rex
2009/05/10 19:23
好文章
lanbolee
2009/01/24 22:26
好文章!
3444334
2008/04/16 21:39
你的网站用火狐浏览器打开好像有点变形啊,不知道是不是我电脑的问题。
分页: 1/1 1