Really big ramdisk: a bad idea?

[Kevin O'Gorman]

On Thu, 12 Sep 2002, Net Llama! wrote:

> Kevin O'Gorman wrote:
> > On Thu, 12 Sep 2002, Net Llama! wrote:
> > 
> > 
> >>Before you go this route, are you sure that the bottleneck is memory?  If
> >>you look at the output from free, is it all consumed?  What about in top,
> >>how much of the memory is it using?
> > 
> > 
> > It stands to reason.  The CPU is 90% free overall, so something is 
> > blocking progress besides the CPU.  What could it be but disk access.
> > The easiest way to avoid disk I/O is to not do any, by doing it in RAM.
> > 
> > Am I missing something?
> 
> No, not really, however the problem could be slow RAM or slow disk I/O.

Disk I/O is always slow, as far as I'm concerned; that's why I'm thinking
large ramdisk.

As for slow RAM, are you sure?  I think that would show up as CPU time
as the CPU stalls waiting for responses from the RAM controller,
and instead I'm seeing under 10% CPU busy.  I infer that neither RAM nor
CPU is the current bottleneck.  The problem is random access to a gdbm
file that grows to around 250MB, about the size as the machine's total
RAM.  These accesses accordingly become (in large part) disk I/O, and
the percentage will increase as my database does, because the buffer
cache will become less efficient.  I've been holding off some major
growth in the database because of these concerns.  If I can solve them
the database will quickly double in size, and will continue to grow.

With a ramdisk most of this should go away.  I'm really just asking if
anyone has experience with large ramdisks under Linux.  I'm thinking
in the gigabyte range, so all accesses are to RAM.

++ kevin


-- 
Kevin O'Gorman, PhD  (805) 650-6274  mailto:kevin at kosmanor.com
Permanent e-mail forwarder: mailto:Kevin.O'Gorman.64 at Alum.Dartmouth.org
Permanent e-mail forwarder  mailto:kogorman at umail.ucsb.edu
Web: http://kosmanor.com/~kevin/index.html