No, I don't care about where you were last thursday at 8:53PM. I'm talking
about physical and virtual memory in our unix world. For quite some time
you'd look at virtual memory to be somewhere in the neighborhood of twice
physical. These days where physical memory can easily range into multi
gigs, is that necessarily practical or even useful? Has anyone done any
research as to what a new standard should be, or does the old one work
find even still?  Lastly, is there a practical upper limit to virtual
memory? I'd imagine that at some point you hit diminishing returns, due to
bus speed, seek times, etc. Am I thinking wrong on this? Enquiring minds
want to know...thanks for your input.

[ Post a follow-up to this message ]

Maitaimaker <maitaimaker@gmail.com> wrote:
> No, I don't care about where you were last thursday at 8:53PM. I'm talking
> about physical and virtual memory in our unix world. For quite some time
> you'd look at virtual memory to be somewhere in the neighborhood of twice
> physical. These days where physical memory can easily range into multi
> gigs, is that necessarily practical or even useful? Has anyone done any
> research as to what a new standard should be, or does the old one work
> find even still?  Lastly, is there a practical upper limit to virtual
> memory? I'd imagine that at some point you hit diminishing returns, due to
> bus speed, seek times, etc. Am I thinking wrong on this? Enquiring minds
> want to know...thanks for your input.

As before, this depends on your usage.

Having swap substantially larger then physical memory will give you
headroom to swap out if needed. The opposit, where the system needs to
swap out a running process but has no swap may cause deadlocks where
a hard reset is needed.

And if you can afford 32GRam then i don't see an issue of not having 80Gdisk
available as swap.

The degenerate cases where kernel-coredumps are taken also needs swap >> Ram
. If you
ever need this (and was to lazy to configure swap) you will regret it.

--
Peter Håkanson
IPSec  Sverige      ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

[ Post a follow-up to this message ]

In article <3bfe502e.0409240843.4c24de7e@posting.google.com>,
maitaimaker@gmail.com (Maitaimaker) wrote:

> No, I don't care about where you were last thursday at 8:53PM. I'm talking
> about physical and virtual memory in our unix world. For quite some time
> you'd look at virtual memory to be somewhere in the neighborhood of twice
> physical. These days where physical memory can easily range into multi
> gigs, is that necessarily practical or even useful? Has anyone done any
> research as to what a new standard should be, or does the old one work
> find even still?  Lastly, is there a practical upper limit to virtual
> memory? I'd imagine that at some point you hit diminishing returns, due to
> bus speed, seek times, etc. Am I thinking wrong on this? Enquiring minds
> want to know...thanks for your input.

The old rule of thumb was based on the assumption that most
organizations couldn't afford enough physical memory to hold all
processes' working sets.  The recommendation was typically described as
VM should be twice physical memory, but what I think was really meant
was that you should have enough RAM for at least half your typical
working set, in order to avoid thrashing.  But if you can afford more
RAM, it can hardly ever hurt.

The basic idea is that the VM size specifies how many processes can run,
and the RAM size specifies how fast they'll run when they're all
competing for memory.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[ Post a follow-up to this message ]