swap tuning
in [Setup]
|
Prev: always create the locations that need frequent I/O /home, swap on the outer tracks ?
Next: Clarifications needed to configure NFS client
From: Pascal Hambourg on 20 Jul 2010 11:47 Hello, Aragorn a �crit : > > RAID 1 (mirroring) on the other hand offers RAID 0 > performance during reads [...] > During reads, the RAID controller - or the software RAID code in > the Linux kernel, depending on your set-up - will behave somewhat like > RAID 0 in that part of the data will be read from one disk and part > form the other disk. This is not true for Linux software RAID 1.
From: Jean-David Beyer on 20 Jul 2010 11:57 Doug Freyburger wrote: > The Natural Philosopher wrote: >> If you need to tune swap, you are already in such bad trouble, that its >> time to fit more RAM. My view is that if you are running much swap, even if you are not thrashing, it is time to increase the memory. Sort of like my days when I built optimizers for the C compilation system. My view was that it was kind-of silly to do this, because you could make your computer faster by using a newer or better processor that you could by improving an optimizer. Optimizers work very well on the benchmarks of the day, when speed-ups of 2:1 were fairly easy to obtain. 10:1 was not unheard of, and on one benchmark, a few optimizations got a loop that executed quite a bit of floating point arithmetic 10,000 times to execute something like 14 instructions executed once each. That was on a benchmark known as Whetstone. The optimizations were loop invariant code motion that noticed everything in the loop was done with no changes, so it moved the instructions out of the loop. Then live-dead analysis removed the looping instructions. Then expansion of functions inline moved the function entry and return, and the single execution of the former loop contents into the calling program. Then live-dead analysis removed all that. But notice that it took a year to program, write, test, and integrate all that into the compilation system. And in real programs, the improvements were usually just a factor between 1 and 2. Two loaded salaries for a year. And in that year, processors got just that much faster. > > Incidentally this includes memory leaks. Since memory leaks are slow > there is no motivation to tune swap space to optimize it. The solution > is to patch the executible that's leaking memory not to optimize swap. Right: optimizing swap will make it run a little faster. But if there is really a memory leak, you will ultimately run out of swap too, so place your order for an additional swapping disk at the same time. ;-) > The only time I have experienced memory leaks was when running Windows 95 on an Intel 166 MHz Pentiun machine. I also experienced crashes and blue screens of death. I have been running Linux (Red Hat Linux 5.0 up to Red Hat Enterprise Linux 5.4) for over 10 years (closer to 12, I guess). I have not noticed memory leaks. If there are any, they must be very slow. The longest I have had a Linux system up was Red Hat Linux 7.3 that ran 24/7 on a dual Pentium III machine for somewhere between 6 and 9 months (I no longer remember exactly), and it did not crash then, but I upgraded it to CentOS 4 when that came out. In all that time, I never ran out of memory or saw much swapping. I saw swapping on Red Hat Linux 9 on an old machine with 64 Megs of ram. But swapping stopped at 128 Megs. But those were from greedy (in those days) programs that were not memory leaking. My present machine has been up almost 13 days now, and has only 684 KBytes of swap used. $ vmstat 5 5 procs -----------memory---------- ---swap-- r b swpd free buff cache si so 4 0 684 470484 230872 5661648 0 0 4 0 684 470484 230896 5661640 0 0 4 0 684 470352 230912 5661648 0 0 4 0 684 469988 230912 5661660 0 0 5 0 684 470360 230928 5661660 0 0 -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key: 9A2FC99A Registered Machine 241939. /( )\ Shrewsbury, New Jersey http://counter.li.org ^^-^^ 11:30:01 up 12 days, 20:16, 3 users, load average: 4.47, 4.69, 4.70
From: Keith Keller on 20 Jul 2010 12:20 On 2010-07-20, Grant <omg(a)grrr.id.au> wrote: > > I usually put swap in at partition five, first in the logicals, on each > drive than run them at same priority. Large swap rarely comes in handy, > but is good for the occasional large or silly task. Better than have > the kernel start killing off processes in response to out-of-memory. I don't think this is necessarily true. If your process is a runaway task, it's much much better to have the kernel kill it off right away than to let it fester in swap, dragging everything else down with it. This is of course assuming that the runaway process in question is using the most memory, which might not be the case if you have a big RDBMS running, for example. The OOM killer can be customized in recent kernels to help protect certain classes of processes. --keith -- kkeller-usenet(a)wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt see X- headers for PGP signature information
From: Grant on 20 Jul 2010 16:14 On Tue, 20 Jul 2010 09:20:19 -0700, Keith Keller <kkeller-usenet(a)wombat.san-francisco.ca.us> wrote: >On 2010-07-20, Grant <omg(a)grrr.id.au> wrote: >> >> I usually put swap in at partition five, first in the logicals, on each >> drive than run them at same priority. Large swap rarely comes in handy, >> but is good for the occasional large or silly task. Better than have >> the kernel start killing off processes in response to out-of-memory. > >I don't think this is necessarily true. If your process is a runaway >task, it's much much better to have the kernel kill it off right away >than to let it fester in swap, dragging everything else down with it. >This is of course assuming that the runaway process in question is >using the most memory, which might not be the case if you have a big >RDBMS running, for example. The OOM killer can be customized in recent >kernels to help protect certain classes of processes. I ignore runaways as a valid thing to plan for. After all, in the last ten years I think only time I lost a Linux box is when I played with a recursion bomb, out of curiosity. And, in that circumstance, a large swap area can give one time to take action before the machine dies. Can be a fun race, particularly if one forgots the 'killall' command at the time. Much more likely to lose the box on power failure. Grant.
From: unruh on 20 Jul 2010 17:11
On 2010-07-20, Grant <omg(a)grrr.id.au> wrote: > On Tue, 20 Jul 2010 09:20:19 -0700, Keith Keller <kkeller-usenet(a)wombat.san-francisco.ca.us> wrote: > >>On 2010-07-20, Grant <omg(a)grrr.id.au> wrote: >>> >>> I usually put swap in at partition five, first in the logicals, on each >>> drive than run them at same priority. Large swap rarely comes in handy, >>> but is good for the occasional large or silly task. Better than have >>> the kernel start killing off processes in response to out-of-memory. >> >>I don't think this is necessarily true. If your process is a runaway >>task, it's much much better to have the kernel kill it off right away >>than to let it fester in swap, dragging everything else down with it. >>This is of course assuming that the runaway process in question is >>using the most memory, which might not be the case if you have a big >>RDBMS running, for example. The OOM killer can be customized in recent >>kernels to help protect certain classes of processes. > > I ignore runaways as a valid thing to plan for. After all, in the > last ten years I think only time I lost a Linux box is when I played > with a recursion bomb, out of curiosity. And, in that circumstance, > a large swap area can give one time to take action before the machine > dies. Can be a fun race, particularly if one forgots the 'killall' > command at the time. How in the world could you "lose" the box? Do you mean it crashed, or that some irretrievable badness occured (CPU caught fire, hard disk was erased, screen exploded in a shower of glass....) > > Much more likely to lose the box on power failure. |