<br><br><div class="gmail_quote">On Mon, Jun 30, 2008 at 10:48 AM, Jerry Yu <<a href="mailto:jjj863@gmail.com">jjj863@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So, are we saying kernel 2.6 is smart enough not to page out idle<br>
pages allcated for Samba (no prod purpose. Example only) in<br>
anticipation of better of thses pages by running or new programs,<br>
merely since no swap is available?</blockquote><div><br>In short, yes. When swap space is activated, there is a map of the available swap space. Each write to swap has a corresponding write to a memory allocation map table that reflects the start and size of the swap write. That 's how the kernel keeps track of where the memory is it needs. Once it needs more memory that is available (total RAM and swap with all caching flushed out for allocated RAM), the box will no longer start new application or threads and may crash unless an app can be killed without needing a ram write.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
What happens when kernel decisdes to page out these idle pages when<br>
the swap is full?<br>
It is an enterprise-grade RDBMS, with mem preallocated, similar to oracle's SGA.<br>
This question was initially raised so to make an informed decision<br>
whether remedial measures need to be considered or applied. The latter<br>
include adding swap and down the swappiness (even to 0).<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
On 6/29/08, Jeff Lightner <<a href="mailto:jlightner@water.com">jlightner@water.com</a>> wrote:<br>
> Maybe but does Linux not do virtual memory pool of both swap and<br>
> physical memory? On UNIX such as HP-UX there is value in having larger<br>
> swap simply because it allows a larger preallocation of virtual memory<br>
> by processes thereby allowing more to be started at the same time.<br>
> This preallocation is for memory that is never really used for the most<br>
> part.<br>
><br>
><br>
><br>
> The key in the OP though was DB and that is a little different. It<br>
> doesn't say what DB. I haven't done anything with MySQL but Oracle uses<br>
> its own SGA which is in Shared Memory for the most part. Swap really<br>
> isn't the issue for DB. Your DB ought to be using space that isn't<br>
> using buffer cache either because it and the SGA's own caching mechanism<br>
> interfere with each other. Since I've only done Oracle on OCFS (Oracle<br>
> Cluster Filesystem) or ASM raw devices I haven't investigated disabling<br>
> buffer cache for ext3 or other filesystems. It is something we<br>
> routinely do for our Veritas filesystems on HP-UX.<br>
><br>
><br>
><br>
> ________________________________<br>
><br>
> From: <a href="mailto:ale-bounces@ale.org">ale-bounces@ale.org</a> [mailto:<a href="mailto:ale-bounces@ale.org">ale-bounces@ale.org</a>] On Behalf Of Jim<br>
> Kinney<br>
> Sent: Saturday, June 28, 2008 1:09 PM<br>
> To: <a href="mailto:ale@ale.org">ale@ale.org</a><br>
> Subject: Re: [ale] Kernel 2.6 : worst-case scenarios if swap full<br>
><br>
><br>
><br>
><br>
><br>
> On Sat, Jun 28, 2008 at 10:42 AM, Ed L. Cashin <<a href="mailto:ecashin@noserose.net">ecashin@noserose.net</a>><br>
> wrote:<br>
><br>
> 2008/6/28 Jim Kinney <<a href="mailto:jim.kinney@gmail.com">jim.kinney@gmail.com</a>>:<br>
> ...<br>
><br>
>> It's pretty easy to add more swap space. Anthing over 2G is pretty<br>
> useless<br>
>> though.<br>
><br>
> I think there was a time when the kernel could not use more<br>
> than 2 GB from a swap partition, but unless there has been<br>
> a regression, I would expect today's kernels to use large swap<br>
> areas without trouble.<br>
><br>
><br>
> It is not a problem for the kernel to TB's of swap. It simply becomes<br>
> useless due to access speeds after about 2GB.<br>
><br>
><br>
><br>
> If there's a limit, though, I'd like to know about it. So any<br>
> references where I could read about it would be appreciated.<br>
><br>
> --<br>
> Ed Cashin <<a href="mailto:ecashin@noserose.net">ecashin@noserose.net</a>><br>
><br>
> _______________________________________________<br>
> Ale mailing list<br>
> <a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
> <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
><br>
><br>
><br>
><br>
> --<br>
> --<br>
> James P. Kinney III<br>
> ----------------------------------<br>
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential<br>
> information and is for the sole use of the intended recipient(s). If you are<br>
> not the intended recipient, any disclosure, copying, distribution, or use of<br>
> the contents of this information is prohibited and may be unlawful. If you<br>
> have received this electronic transmission in error, please reply<br>
> immediately to the sender that you have received the message in error, and<br>
> delete it. Thank you.<br>
> ----------------------------------<br>
><br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III <br>