RAM DRIVE

[Larry Basford]

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?

[A. Clay Stephenson]

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.

[RAC_1]

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...

[A. Clay Stephenson]

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.

[Laurent Menase]

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

[Ted Buis]

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.

[Larry Basford]

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

[A. Clay Stephenson]

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.