On 2016-04-27 11:44, Xen wrote:
Carlos E. R. schreef op 26-04-2016 22:40:
On 2016-04-27 00:19, Xen wrote:
They just said (I think it was an Ubuntu page) that the default of 60 causes unresponsiveness in programs while this is less important for a server. So if you want a responsive system, reduce the value. That page
This needs expanding :-)
I mean, a server has to respond reasonably fast to a request, or everybody lags in their work. I take it that they mean fast response to the mouse or keyboard. In that case, I think that programs should classify their own code as "need fast response" and "can be delayed", so that the kernel can adjust what to swap fast or slow.
I don't know. You would consider that overall disk performance is more important to a server. If any service requires memory to be brought out of swap that can incur a delay but the delay will a small 'spike' in a landscape of higher performance.
For a server average performance is more important I think.
True.
Maybe you are right. But this tends to indicate overall a problem with prioritizing and I don't know if Linux handles it well. I think I have experienced unimportant jobs (such as high IO jobs, archiving) crippling a system where system response became impossible.
Me too. Actually, many of us have experienced what happens when one of those background jobs that peruse your files to create a content index is running. The computer feels like a tortoise.
One example was playing a YouTube video while a (Wine) game was running in the background. The YouTube video lagged so much that it was unplayable. The background game was not shown on screen.
Yes, the video should have RT resources.
Certain classes of applications require almost realtime performance, but Linux is by default not a realtime system.
No general OS is.
Anything that requires fast response, or audio-video playback, could or should really have a certain amount of "realtimeness" guaranteed to it. Most playback does not require 100% CPU and even with 10% guaranteed it would be okay. Yet I am always afraid in Linux to do some background task -- last time I was just burning a DVD and the buffers (software buffer and device buffer) went down to zero as soon as I started up a network copy task (to my harddisk, or from my harddisk). That is scary and I don't know if the write would have failed. Maybe devices are protected against that these days; they weren't in the past.
Right.
So I manually tried to ionice the thing (the copy) but in practical terms any cp, tar, rsync, whatever task is always going to be background, and always going to be something that could be classified as "lower priority" for IO. And CPU as well.
Try this one: cpulimit -- limits the CPU usage of a process
User interface elements are just higher priority than background processes or tasks.
Not all of them. Like responding to a network packet.
So I think thinking about this thing is more important than swap, and if you do want it to apply to swap, you might just as well use the same measure to begin with ?.
Regards.
-- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)