On Fri, 2002-09-13 at 14:13, Jim Sibley wrote:
>
>
> Tim wrote:
> > There is another solution. And that is never >allocate memory unless
> >you have swap space. Yes, the issue is that you >need to have lots of
> >disk allocated to swap but on a big machine you >will have that space.
>
> How do you predict if a program is going to ask for more memory? Maybe it only
> needs additional memory for a short time and is a good citizen and gives it
> back?
>
Well its been a bit so the details are fuzzy but you have a pointer
to how much space you have left in you allocated swap and when you get
memory you decrement space and when you release memory in increment it
so that it indicates how much you have left. If you try and malloc
more than you free then you go and reserve another chunk of swap.
> How much disk needs to be allocated for swap? In 32 bit, each logged in user
> is limited to 2 GB, so do we need 2 GB for each logged on user? 250 users, 500
> GB of disk?
>
It turns out that for the high load database machines this is about
3 to 4 times the actual physical memory.
> In a 64 bit system, how much swap would you reserve?
>
Same as 32 bit machines doesn't apply.
> Actually, another OS took this approach in the early 70's and this was quickly
> junked when they found out how much disk they really had to keep in reserve
> for paging.
>
But there are many current OS's that do this and are quite successful.
> > This way the offending process that asks for >more memory will be
> >the one that gets killed. Even if the 1st couple >of ones aren't the
> >misbehaving process eventually it will ask for >more memory and suffer
> >process execution.
>
> It may not be the "offending process" that is asking for more memory. How do
> you judge "offending?"
>
In this case the offense is asking for more memory. So it is the
process that asks for more memory that goes away. Again sometimes
it will be an innocent bystander but hopefully it will eventually
be the process that is causing the problem.
Many databases program for this condition. The stuff that absolutely
must be up and running preallocates all of the memory that it needs
at startup. Any new memory requests that are denied might cause a
transaction to fail but they won't bring down the whole database.
Tim
>
>
>
>
-- Timothy D. Witham - Lab Director - wookie@osdlab.org Open Source Development Lab Inc - A non-profit corporation 15275 SW Koll Parkway - Suite H - Beaverton OR, 97006 (503)-626-2455 x11 (office) (503)-702-2871 (cell) (503)-626-2436 (fax)- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:35 EST