topic Re: RAM DRIVE in Operating System - HP-UX

RAM DRIVE

Larry Basford — Thu, 06 Jan 2005 14:38:25 GMT

Is there a way to keep a file in memory?
I thought with a sticky bit.
I have a 2GB file that is read over and over all day long and I'd like to keep it in memory with ocasional flush to disk.
And how much memory would I need?

Re: RAM DRIVE

A. Clay Stephenson — Thu, 06 Jan 2005 14:46:40 GMT

The sticky-bit has no effect on data files. On executables on most UNIX flavors, it kept the file in memory (or swap) for rapid loading. Let's see a 2GB file would require (using extremely complex math) 2GB of memory. The ideal approach for what you are trying to do is a memory-mapped file but the application has to do that. Man mmap for details. There are unsupported methods to create a memory-based filesystem but your best bet is to probably increase the buffer-cache and let the OS decide how much of this file should be kept in memory.

Re: RAM DRIVE

RAC_1 — Thu, 06 Jan 2005 14:46:46 GMT

0) # create a "make_tape_recovery" tape for your box!

1) #Modify your kernel to include the "ram" driver:

1) cd /stand/build

1) /usr/lbin/sysadm/system_prep -v -s system

1) vi /stand/build/system

1) # Edit the system file and add the "ram" driver

or

kmsystem -c y -S /stand/system ram

1) mk_kernel -s system

1) mv /stand/system /stand/system.good

1) cp /stand/vmunix /stand/vmunix.good

1) rm -rf /stand/vmunix/dlkm.good

1) mv /stand/dlkm /stand/dlkm.good

1) mv /stand/build/system /stand/system

1) kmupdate

1) shutdown -y -r 0

2) # set up the device files and mount the ramdisk:

2) # create the device files with major 9 (both b and c),

2) # and minor 0xVSSSSS, where "V" is the volume num,

2) # and "SSSSS" is the number of sectors in the ram

2) # disk, each sector is 256 bytes.

2) mknod /dev/rram1 c 9 0x101000

2) mknod /dev/ram1 b 9 0x101000 # that's 1MB

2) mkfs -F hfs /dev/rram1 # no point in VxFS here

2) mount /dev/ram1 /ramdisk

THIS IS UNSUPPORTED, dangerous, and such...

Re: RAM DRIVE

A. Clay Stephenson — Thu, 06 Jan 2005 14:58:34 GMT

I should add that one practical, supported method approach that does not require modifications to the code is the use of a Solid State Disk. These consist of battery backed memory that may save to built-in magnetic drives. They are very, very fast and appear to your box as simply another SCSI disk --- but they ain't cheap. One of your modest requirements wouldn't be all that expensive. If you really need high performance for a few heavily used files this is the way to go. Of course, you could achieve very similar results by housing the file on a cache-centric array.

Re: RAM DRIVE

Laurent Menase — Fri, 07 Jan 2005 03:54:20 GMT

The buffer cache is your friend :)

Ramdisk is less performant than buffercache, because access of a filesystem on a ramdisk make a lot of useless memory copy -which are made by the CPU-. Moreover it is not supported.

So fix your buffer cache to more than 2GB (dbc_max_pct), - and dimension the memory accordingly

Re: RAM DRIVE

Ted Buis — Fri, 07 Jan 2005 09:14:00 GMT

FYI,

http://www.unixguide.net/hp/faq/5.3.2.shtml

In the third case, there is third party support, and they can mirror it to disk, so that reads are very fast, but writes are posted to disk.

Re: RAM DRIVE

Larry Basford — Fri, 07 Jan 2005 10:57:58 GMT

Do you know of anybody running a high buffer cache like 4GB?

Re: RAM DRIVE

A. Clay Stephenson — Fri, 07 Jan 2005 11:15:38 GMT

I've setup boxes that are essentially NFS servers with very large buffer caches and they work well although the largest I've used is about 3GB. If this is 11.11 then it is better with large buffer caches than 11.0.
Of course, running a large buffer cache only makes sense if the box has much larger amounts of memory.

It would probably help if you better explained what this 2GB file does because I suspect that much (almost all) of it does not change between sucessive runs. It sounds as though more efficient algorithms would exceed by many orders of magnitudes your attempt at a band-aid solution.