<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">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@eburg.com> wrote: <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Gordon Messmer <yinyang@eburg.com> Subject: Re: Ideal Swap Partition Size To: "Community assistance, encouragement, and advice for using Fedora." <fedora-list@redhat.com> Date: Tuesday, January 20, 2009, 11:06 PM <pre>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@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines </pre></blockquote></td></tr></table>