The 2x rule for swap was a rule of thumb. Considering older linux platforms, it was an excellent rule. Actually, swap sizes should be based on the number of concurrent (but potentially sleeping) processes that are in execution. With high speed computers, I believe that it is possible to even have a ratio of 10 to 1 or 50 to 1 (swapsize to memory size).
Keep on loading tasks that generate a wait, and check it out. Also, respond to the tasks in any random order. The system should unwind--- so to speak.
Les
--- On Wed, 1/21/09, Leslie Satenstein <lsatenstein@xxxxxxxxx> wrote:
From: Leslie Satenstein <lsatenstein@xxxxxxxxx>
Subject: Re: Ideal Swap Partition Size
To: "Community assistance,
encouragement, and advice for using Fedora." <fedora-list@xxxxxxxxxx>
Date: Wednesday, January 21, 2009, 8:49 PM
Regarding swap files and intel architectures. I believe swapping is not by pages, but by segment sizes, which is gruesome, because of performance.
On other architectures, swap is actually a paging file and only the needed pages are swapped out.
Even with a swap out, the program could still be in memory as the space was not reclaimed and thus, the program should not have to be swapped back in to be used.
--- On Tue, 1/20/09, Gordon Messmer <yinyang@xxxxxxxxx>
wrote:
From: Gordon Messmer <yinyang@xxxxxxxxx>
Subject: Re: Ideal Swap Partition Size
To: "Community assistance, encouragement, and advice for using Fedora." <fedora-list@xxxxxxxxxx>
Date: Tuesday, January 20, 2009, 11:06
PM
Rick Stevens wrote:
>
> Reserving a swap area and its size is rather dependent on what the
> machine is doing. We have database servers that, on occasion, get
> hammered and revert to using swap for a brief time. We use a 2X swap
> size and we've come close to using it all, so it's still valid.
You
> will have to watch it---as soon as you start really whacking swap,
> system performance is going to start suffering quite badly.
It's also important to bear in mind that under the standard configuration,
you must have at least as much "free" memory as the largest
application in your server, or else that application won't be able to call
external programs.
Let's imagine that you have a server with 2GB of RAM, and just 512MB of
swap (maybe based on the idea that swapping will cause the system to behave
badly). Let's also imagine that you've tuned your SQL server
to
keep as
much data in memory as possible, so it's 1.5GB resident. Now, if you SQL
server has helper applications that it wants to call, it has to fork() and then
exec() to start them. When it does a fork(), the system doesn't actually
copy all of its pages for the new process, but it does require that the memory
be available (the extent to which that is true depends on your overcommit
settings). However, since you don't have 1.5GB of memory available, the
fork() will probably fail, and the SQL server process can't execute its
helper script.
This situation would be much harder to diagnose if you had 1GB of swap and your
SQL server were something like 1.3 GB. In that case, it might sometimes work
and sometimes fail depending on how many other processes were using memory.
So, even if you expect to never *use* swap space, you should have at least as
much swap as physical RAM.
I thought I'd read
once
that using twice as much swap as physical RAM
actually allowed the system to use a linear map of swap pages to virtual address
space, so that it didn't have to search for free pages of swap when it paged
something out. The result was a faster swap manager, but I'm not sure if
that's actually the case. I haven't been able to find documentation to
back it up. Anyone know whether or not that's the case?
-- fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
|
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines |
