[ale] Kernel 2.6 : worst-case scenarios if swap full

[Jim Kinney]

On Mon, Jun 30, 2008 at 10:48 AM, Jerry Yu <jjj863 at gmail.com> wrote:

> So, are we saying kernel 2.6 is smart enough not to page out idle
> pages allcated for Samba (no prod purpose. Example only) in
> anticipation of better of thses pages by running or new programs,
> merely since no swap is available?


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.

>
> What happens when kernel decisdes to page out these idle pages when
> the swap is full?
> It is an enterprise-grade RDBMS, with mem preallocated, similar to oracle's
> SGA.
> This question was initially raised so to make an informed decision
> whether remedial measures need to be considered or applied. The latter
> include adding swap and down the swappiness (even to 0).
>
>
> On 6/29/08, Jeff Lightner <jlightner at water.com> wrote:
> > Maybe but does Linux not do virtual memory pool of both swap and
> > physical memory?   On UNIX such as HP-UX there is value in having larger
> > swap simply because it allows a larger preallocation of virtual memory
> > by processes thereby allowing more to be started at the same time.
> > This preallocation is for memory that is never really used for the most
> > part.
> >
> >
> >
> > The key in the OP though was DB and that is a little different.  It
> > doesn't say what DB.  I haven't done anything with MySQL but Oracle uses
> > its own SGA which is in Shared Memory for the most part.   Swap really
> > isn't the issue for DB.  Your DB ought to be using space that isn't
> > using buffer cache either because it and the SGA's own caching mechanism
> > interfere with each other.   Since I've only done Oracle on OCFS (Oracle
> > Cluster Filesystem) or ASM raw devices I haven't investigated disabling
> > buffer cache for ext3 or other filesystems.  It is something we
> > routinely do for our Veritas filesystems on HP-UX.
> >
> >
> >
> > ________________________________
> >
> > From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Jim
> > Kinney
> > Sent: Saturday, June 28, 2008 1:09 PM
> > To: ale at ale.org
> > Subject: Re: [ale] Kernel 2.6 : worst-case scenarios if swap full
> >
> >
> >
> >
> >
> > On Sat, Jun 28, 2008 at 10:42 AM, Ed L. Cashin <ecashin at noserose.net>
> > wrote:
> >
> > 2008/6/28 Jim Kinney <jim.kinney at gmail.com>:
> > ...
> >
> >> It's pretty easy to add more swap space. Anthing over 2G is pretty
> > useless
> >> though.
> >
> > I think there was a time when the kernel could not use more
> > than 2 GB from a swap partition, but unless there has been
> > a regression, I would expect today's kernels to use large swap
> > areas without trouble.
> >
> >
> > It is not a problem for the kernel to TB's of swap. It simply becomes
> > useless due to access speeds after about 2GB.
> >
> >
> >
> >       If there's a limit, though, I'd like to know about it.  So any
> >       references where I could read about it would be appreciated.
> >
> >       --
> >        Ed Cashin <ecashin at noserose.net>
> >
> >       _______________________________________________
> >       Ale mailing list
> >       Ale at ale.org
> >       http://mail.ale.org/mailman/listinfo/ale
> >
> >
> >
> >
> > --
> > --
> > James P. Kinney III
> > ----------------------------------
> > CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
> confidential
> > information and is for the sole use of the intended recipient(s). If you
> are
> > not the intended recipient, any disclosure, copying, distribution, or use
> of
> > the contents of this information is prohibited and may be unlawful. If
> you
> > have received this electronic transmission in error, please reply
> > immediately to the sender that you have received the message in error,
> and
> > delete it. Thank you.
> > ----------------------------------
> >
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
>



-- 
-- 
James P. Kinney III
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20080630/8a496275/attachment.html