关于OpenVZ VPS的共享内存设备的问题

windywinter

原讨论贴在此：http://www.lilynana.eu.org/thread-38788-1-1.html
经过查询OpenVZ的wiki，发现共享内存设备的确是OpenVZ在管理内存上的一个问题，但也不能算是“漏洞”。
OpenVZ的User Beancounters里面提供了一个参数——shmpages来控制VE能够使用的共享内存设备容量，这一部分内存计入privvmpages的held值，也就是算作VE占用的内存。
好了，下面的内容分两段提供给不同的人群。
For VPS providers:

shmpages应该合理配置，barrier和limit应小于等于vmguarpages的barrier。用户可以通过在/dev/shm下建立文件的方式占用内存，而这样占用的内存在母机缺少内存时无法强制释放（母机只能通过杀进程的方式释放内存）。
假定一个极端情况：shmpages被设置为无限大，某用户恶意在/dev/shm下建立一个大小接近privvmpages的barrier的文件（也就是占满busrtable memory），这时母机缺内存了，恰好只有这一个VE使用了burstable memory，于是母机杀掉了这个VE的所有进程——但是该VE却始终占据着巨大的内存（共享内存随着开辟它的进程的结束而消失，但恶意建立文件开辟的共享内存却没有进程约束它，于是除非关掉这个VE或主动去删文件，否则永远无法释放），这时OpenVZ的调整机制失效，Linux内核只能通过随机杀进程的方式释放内存，不管这个进程所属的VE是否用了burstable memory。
如果shmpages的barrier和limit小于等于vmguarpages的barrier，那么最极端的情况也就是该VE进程被杀光却仍然占用了全部的guaranteed memory。

For VPS customers:

用于web服务器的VPS中最常见的使用共享内存设备的东西是MySQL，到底会用多少我也不清楚。我有几个5~6M大的数据库，shmpages的held值是4736（也就是占用4726×4k=18.5M内存）。如果服务商设定的shmpages过小的话，大一点的MySQL数据库会跑不起来。所以这个值很容易成为除了numproc、numtcpsock、tcpsndbuf、tcprcvbuf、numfile之外另一个玩阴招的地方。
在查/dev/shm的相关内容的过程中，我发现有一篇《检测openvz vps内存是否超售的方法》，需要指出的是，只要服务商配置合理，这个方法是不能检查OpenVZ VPS内存是否超售的，原因如上所述，VE中能开辟的共享内存受shmpages的限制，不能完全占满burstable memory。而且如果文中叙述是真实的，那么Burst对OpenVZ的配置无疑是存在问题的。

大家有OpenVZ VPS的不妨把自己的shmpages参数贴一下。

[ 本帖最后由 windywinter 于 2010-12-12 15:44 编辑 ]

Poison

这个是要在母鸡上设置的吧

hotsnow

如何查看 shmpages 参数？

windywinter

原帖由 hotsnow 于 2010-12-12 15:30 发表
如何查看 shmpages 参数？

1. sudo cat /proc/user_beancounters | grep shmpages

复制代码

贴一贴只是好玩

hotsnow

貌似 held 值每次都不一样？

windywinter

held是“当前占用的值”，会有差别，但不应该差别很大。

我是人

held 是当前的使用状况。

我查了一下 BuyVM, Yard, 123Systems，shmpages 都设成和 vmguarpages 一样的值。

hotsnow

limit 都是 131072

我是人

131072 x 4K / 1024 = 512MB