![是否可以使用 LXC 容器虚拟化来限制/节流页面错误?](https://linux22.com/image/614354/%E6%98%AF%E5%90%A6%E5%8F%AF%E4%BB%A5%E4%BD%BF%E7%94%A8%20LXC%20%E5%AE%B9%E5%99%A8%E8%99%9A%E6%8B%9F%E5%8C%96%E6%9D%A5%E9%99%90%E5%88%B6%2F%E8%8A%82%E6%B5%81%E9%A1%B5%E9%9D%A2%E9%94%99%E8%AF%AF%EF%BC%9F.png)
可以将容器限制为 512MB RAM 和 4GB 交换空间。但是,如果该容器频繁使用已交换出的内存,它是否会占用包含交换文件的存储设备的 IO 资源?我想要避免的是,一个容器将存储设备固定在 100% 利用率,并使其他对交换的需求较小的容器处于饥饿状态。理想情况下,每个容器都应该在负载下获得公平的份额,并且能够在负载允许时突破这一份额。
现在我知道有 blkio 限制,而且限制这些限制似乎很简单,但从技术上讲,是内核在进行交换,所以我不知道它是否尊重这些限制或将页面错误计入这些限制。
有人知道这是否可行或如果可行该如何配置吗?
编辑:OpenVZ 有一种称为 vswap 的东西,它会限制正在交换的容器,即使系统实际上有足够的空闲空间,以至于“交换”页面在 RAM 中,而实际上并没有将它们转移到磁盘上。这似乎就是我想要的。有没有办法用“原始”Linux 容器做到这一点?
答案1
如果您的虚拟机管理程序经常出现 IO 不足的情况……那么您就做错了。这总是一场战斗。页面错误是无法限制的……因为它们是资源不足的结果。减少/消除页面错误的唯一方法是添加更多物理 RAM 或减少/删除交换空间。页面错误(尽管名称如此)并不总是意味着发生了“错误”。它只是意味着当应用程序尝试从 RAM 访问虚拟内存段时……它不再可用,必须从磁盘重新读取它。
听起来更像是您的实例没有足够的 RAM... 而您正在尝试使用交换文件来解决这个问题。不应依赖交换文件。它们仅在您偶尔需要在短时间内超出有限的物理 RAM 的情况下才有用。
减少 IO 延迟的唯一方法是提供更多 IO,或者减少/限制 IO 的使用。减少/限制会导致实例性能不佳,并且可能会在尝试实施 IO 配额时在 CPU 上造成额外的瓶颈。