3 ms·

> If I have enough RAM why do I want things to swap to begin with? The author never explained why putting rarely used pages in swap will improve performance if

by pfranz 7y ago

> If I have enough RAM why do I want things to swap to begin with? The author never explained why putting rarely used pages in swap will improve performance if I have adequate RAM. One thing I think the author was getting at, but never explicitly stated is that we spec most things for the average expected workload with a bit of headroom--not the peak workload since that is very difficult to assess. Peak workload might also be few and far between and not worth paying for upfront. Swap allows you to deal with peak workloads more gracefully for many applications. Having your process randomly die isn't a big deal with stateless processes (which is a more and more common design), but really sucks for stateful things. Not just the possibility of lost/corrupt state, but process startup and loading of state can take a long time. We have a few servers that don't have swap and I was hoping to find an excuse to add it in this article. Instead, it reenforced that decision because of type of things we run on it.

eikenberry 7y ago
> Swap allows you to deal with peak workloads more gracefully for many applications. This is almost always false in practice though. Peak workloads means more than just lots of memory, it means high CPU and high IO (disk and network). If you under-spec your servers such that they need to hit swap during peak loads they are going to generally cause more problems than if they just die. A server dying is something you have to prepare for and deal with anyways, and is much simpler to plan for than the weird latency issues you'll get with a server hits swap. Think of it as similar to Erlang's fail-fast model. Better for things to just die and be recovered than to continue on in a bad state.
- pfranz 7y ago
  I'm not really sure what you're getting at. You and I are both emphasizing a different behavior for different classes of applications. I feel like my comment and the article were pretty clear about that. I've had the opposite experience than "almost always false in practice" but my domain is fairly different than most here so I try and be very careful when generalizing. If your hardware is underspeced for the workload, there's still a business case to be made before you buy new hardware. Sometimes the preferred failure mode is to slow down, other times it's preferred to die and restart. Hardware speced for peak loads can sometimes cost multiple times otherwise appropriate hardware...assuming you even know what peak loads will be. I have one class of application that is fairly idempotent, we don't have hard drives on these machines, so we don't use swap and expect it to die if it exceeds the amount of memory requested. This article reenforced this. I have another class of application that queues up things to process. The specs work on the current hardware 99% of the time, but on holiday weekends when large projects are delivering things slow down because work is submitted and people leave so nobody cares. Reloading the state from disk can take 20m+ and without swap if you were to exceed memory you're dead in the water until you purchase more hardware. Our contingency hardware has identical specs as the original.

by pfranz 7y ago

eikenberry 7y ago

> Swap allows you to deal with peak workloads more gracefully for many applications. This is almost always false in practice though. Peak workloads means more than just lots of memory, it means high CPU and high IO (disk and network). If you under-spec your servers such that they need to hit swap during peak loads they are going to generally cause more problems than if they just die. A server dying is something you have to prepare for and deal with anyways, and is much simpler to plan for than the weird latency issues you'll get with a server hits swap. Think of it as similar to Erlang's fail-fast model. Better for things to just die and be recovered than to continue on in a bad state.

pfranz 7y ago
I'm not really sure what you're getting at. You and I are both emphasizing a different behavior for different classes of applications. I feel like my comment and the article were pretty clear about that. I've had the opposite experience than "almost always false in practice" but my domain is fairly different than most here so I try and be very careful when generalizing. If your hardware is underspeced for the workload, there's still a business case to be made before you buy new hardware. Sometimes the preferred failure mode is to slow down, other times it's preferred to die and restart. Hardware speced for peak loads can sometimes cost multiple times otherwise appropriate hardware...assuming you even know what peak loads will be. I have one class of application that is fairly idempotent, we don't have hard drives on these machines, so we don't use swap and expect it to die if it exceeds the amount of memory requested. This article reenforced this. I have another class of application that queues up things to process. The specs work on the current hardware 99% of the time, but on holiday weekends when large projects are delivering things slow down because work is submitted and people leave so nobody cares. Reloading the state from disk can take 20m+ and without swap if you were to exceed memory you're dead in the water until you purchase more hardware. Our contingency hardware has identical specs as the original.