简洁版本：
有没有关于在 Virtuozzo/OpenVZ 中用作 Web 服务器的容器应将 kmemsize 屏障和限制设置为多少的官方指南？我们在以下文章中找到了博客和论坛认为 kmemsize 至少应为 vmguarpages 的 10%（在转换为相同单位后）。遗憾的是，我们没有找到任何权威参考资料（甚至没有理由）来支持这一 10% 的断言。知道这个 10% 的想法从何而来吗？
长版本：
我的一位客户在 1and1 托管的 VPS 上有一个网站，运行 CentOS 5.9 64 位。该网站内容丰富，但特别值得注意的是，它是一项在线调查，通常由一群人在同一时间从同一地点（想象一个教室）进行。有时（但并非总是如此）当一群人同时开始调查过程时，我们会看到 VPS 上的 kmemsize“持有”值大幅飙升。起初，这导致我们超出了 kmemsize 限制，增加了 kmemsize 失败次数，并向用户的浏览器发送错误。通过调整 Apache 的 MaxClients，我可以防止我们超出 kmemsize 限制。但是，如果我们的峰值略低于限制，http 请求就会排队，网站速度会变得非常缓慢，页面加载需要几分钟，可以说这不比崩溃好。很明显，我们需要更高的 kmemsize 屏障/限制。
这就是背景。我真正的问题是我们当前的限制是否合理。我们应该有 1G 的 RAM“保证”（vmguarpages 屏障设置为 262144），可能突然增加到 4G。但我注意到，即使我们接近或达到 kmemsize 限制，
free仍然会报告我们使用的内存少于 600,000k。
/proc/user_beancounters报告我们的 kmemsize 屏障为 31457280，限制为 34603008。如上文简版所述，我们发现一些网站声称 kmemsize 应设置为 vmguarpages 设置的“保证”内存的至少 10%。通过计算，我发现我们处于
kmemsize 屏障 = 31457280 B = 30 MB = 约占 1024 MB vmguarpages 屏障的 3%
这似乎与以下观点一致：（根据free）我们似乎从未使用过超过“保证”总内存量的一半。因此，我们只想打电话给 1and1 并说“哇，您提供的这项服务不符合 VPS 的最低建议，因此我们实际上不可能使用您保证给我们的内存量”。而且，如果他们不听劝告并修复它，就转向另一家提供商。但是，为了向提供商表明我的观点并向我客户组织的高层证明（如果有必要）转向的合理性，我希望能够引用更权威的来源来支持这个“kmemsize 应至少为保证内存的 10%”的想法。
答案1
查看 kmemsize 条目Parallels 知识库。