Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

It's possible to limit a container to 512MB of RAM and 4GB of swap. However, if that container uses memory frequently that has been swapped out wouldn't it dominate the the IO resources of the storage device(s) containing the swap file(s)? What I want to avoid is one container from pinning the storage device at 100% utilization and starving other containers that have more modest demands for swap. Ideally each container should get their fair share under load, and be able to burst beyond that when the load permits.

Now I know there are blkio limits, and it seems quite straightforward to limit those, but it's technically the kernel that's doing the swapping, so I don't know if it respects those limitations or counts page faults towards those limits.

Does anyone know if this is possible or how to configure it if it is?

edit: OpenVZ has something called vswap, which will throttle a container that's swapping even if actually the system has enough slack that the "swap" pages are in RAM and it's not really going to disk for them. That seems to be what I'm after. Is there any way to do that with "vanilla" Linux containers?

share|improve this question

If you're regularly running out of IO on your hypervisors... you've done it wrong. That's always the battle. Page-faults are not something that can be limited... as they're the result of a lack of resources. The only way to reduce/eliminate page-faults is to add more physical RAM or reduce/remove the swap space. Page-faults (despite the name) does not always imply an "error" occurred. It simply means that when an application attempted to access the virtual memory segment from RAM... it was no longer available, and has to re-read it from the disk.

It sounds more like your instances do not have sufficient RAM... and you're trying to solve the issue with a swap-file. Swap-files should not be relied on. They're only useful in situations where you occasionally need to go above the limited physical RAM for a brief period of time.

The only way to reduce delays on IO... is to provide more IO... or reduce/limit the usage on IO. Reducing/limiting would result in instances that perform terribly... and may create additional bottle-necks on the CPU trying to implement quotas on the IO.

share|improve this answer
Will limiting IO limit page faults as well? Saying there's never a reason to use swap is a little presumptuous don't you think? There are plenty of valid reasons to use swap. I also don't buy your argument that limiting page faults is intrinsically bad. When a cgroup exceeds its limit for a time period, simply suspend it's processes until the end of the time period if they page fault (unless there's spare capacity.) Granted that may be hard to do depending on implementation details in the kernel, I don't know, but I might give it a try if there's no easier alternative. – Eloff Jul 8 '13 at 16:49
Using, e.g. blkio.weight would seem to be exactly what I want, except I don't know if that includes IO generated by page faults (and nowhere does anyone seem to answer that question.) – Eloff Jul 8 '13 at 18:05
I never said limiting page-faults is bad.... I said that you cannot tell an OS not to have page-faults. It is the result of a lack of resources. I also never said there is never a good reason to use swap... I said that a swap-file should not be relied on. They're good for limited temporary expansion of memory. Using swap, comes at a very high cost of performance. Adding delays or limiting IO would only increase the loss of performance. – TheCompWiz Jul 10 '13 at 13:00
That's still presumptuous, I can take two enterprise 250K IOPS SSDs, stick them in the PCI slots and get half a million random 4K page reads per second. I think for a lot of systems that would be more than acceptable. It's not even that exotic, I can get one fifth of that on the high IO AWS instances. It neither needs to come at a high performance cost nor be temporary. Adding delays would hurt the throttled container, but it prevents that same badly behaved container from hogging the entire system. – Eloff Jul 10 '13 at 16:05
page reads are NOT page faults. Page faults are caused by attempts at page-reads when the physical memory has been reallocated to something else (this is called swapping). Adding a delay, or limiting the amount of IO, would cause a performance hit no matter which way you cut it. Sure, it would make every instance "equal"... but like communism, it makes everyone equally starved... except for the rich. – TheCompWiz Jul 11 '13 at 14:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.