[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RAM question for everyone!



On Fri, Jan 23, 2009 at 04:54:24PM +0000, Dan Track wrote:
> On Fri, Jan 23, 2009 at 4:25 PM, Patrick O'Callaghan
.....
> >> >
> >> > I'm really curious.
> >> >
> >>
> >> SATA Hard drive speeds - 70 megs to 150 megs a second unless you're RAIDing
> >> DDR2 RAM speeds - 6000 megs a second and up.
> >>
> >> If performance is a key issue, which I'm sure it is, you don't want swap.
> >
> > In which case the real question is not "how much swap do I need?" but
> > "how much RAM do I need to avoid swapping?".
> >
> > poc
> 
> Hi All,
> 
> This wasn't addressed to any paricular architecture, it was more of a
> query. Why do I even need swap or a large disk if all my app does is
> read a few pieces from a database on disk and if I load the database
> into RAM is there ever a need to look at the hardisk, given that the
> database never changes.
> 

The most missed VM issue in discussing swap space is the classic
"fork() --> exec(something_smaller)" sequence.

If you have a 10GB application that wants to print it will
commonly do a fork() which will cause the VM system to make
reservations for a second copy (10GBx2=20GB).  For the short
time up to the exec(and_now_print) the system must convince itself that the
fork() will succeed.   i.e. the sum of RAM and swap needs to 
be big enough for both copies to survive copy on write VM 
activity.  In the normal case there is almost no copy on write so
the swap pages on disk are never needed except to satisfy the
book keeping.

Like the banking industry the kernel can have a bit set to
"trust me" and blindly extend credit.  While vm.overcommit_memory 
exists it can set the stage for a system VM page credit crunch and crash
(not just a slow down).

Another good reason for swap use is 'job control' on servers.  Almost no
one does this any more but it can make sense to have a set of programs
running such that running one at a time is the only way the system can
avoid thrashing.  A batch system can signal them to sleep or continue and
time slice them on tens of minute basis rather than 100 slices per second.
The bash man pages mentions job control in passing see this stuff: "selectively stop
distributed prime factor programs can watch this in action.

Sadly this 'VM' issue, so close to financial credit activity, is 
simply not understood.   I suspect if it was understood the world credit
markets would be in less trouble.  Yet, it can be taught with 3x5 cards
in primary schools. Yea modeled with 3x5 cards and Monopoly money in a 
business meeting.     Same for mutual exclusion locks and queues....
most companies (and families) operate on a 'race' and spend it first
greedy model.  

 

-- 
	Regards,
	T o m   M i t c h e l l


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]