Yup, Windows PE uses them for loading the PE environment into memory prior to imaging a PC.
I've always been attracted to the notion of using a RAM disk for my swap file location, but never really got round to trying it out, and to be honest I'm not totally certain how well it would work in practice.
My netbook rsyncs my Firefox profile to a RAM disk on boot, removing the very slightly irritating pauses caused by the urlclassifier file being updated on the not-fast-to-write-to SSD after page loads. It rsyncs it back on full shutdown so new bookmarks and such are not lost between boots (using the inplace option which reduced the number of writes needed in the simple tests I performed) or when I command it to (i.e. after making a number of changes like installing+configuring plugins).
They are also useful for some performance tests when you don't want disk IO to have much impact on the test but /dev/zero and friends won't do for some reason.
They're most useful when going totally disk-less, or when using the disks only for a particular format that the OS wouldn't boot from.
I know it's not a server, but on old macs you used to be able to set a ram-disk up and then install a minimal OS 7 into it, set it as your boot volume, then reboot from it. It seemed scary, but it always worked, and it definitely made the finder act more responsive. Some claimed it even made photoshop run faster, but I was never clear on that.
On a firewall the hard drive was replaced with a compact flash card. A RAM drive is used because CF cards have limited write cycles. On shutdown anything in the RAM drive that needs to be preserved is transferred to the CF card and reloaded on reboot. I am currently looking into creating Linux thin clients using the same idea.
you can store small but frequently r/w files on ramdisk. Some uses I do:
- syslog goes to tmpfs /tmp on my laptop: it helps drives spinoff if I don't use the computer (reduces writes)
- /tmp is good on tmpfs, as many apps are using it as temporary dir (mysql for temptables, virus scanners and some packaging utility, for example)
- php session file store: on debian systems, /var/lib/php is always mounted by tmpfs to reduce writing to disk (as my disks are always raid1, writing is quite a pain)
- as mentioned, mail scanner tools are thankful for infinite speed block devices :)
- files for AJAX: these files here are frequently regenerated
You should check your applications where you have opportunity. A directory qualified to go under tmpfs, if the content
- would be regenerated anyway (like ajax support files)
- does not have to survive a reboot
There are legitimate uses for a RAMDISK, but not many. The system cache provides most of the benefits of a RAMDISK without the disadvantages. A RAMDISK requires tying up a substantial amount of RAM when it may be better used for other purposes. You will often optimize one aspect of performance but lose it elsewhere.
Incidentally, using a RAMDISK for the pagefile is completely nonsensical. In virtually every case it will be better to let the system use the RAM as it sees fit.
I haven't seen ram disks used for a long time, but I think that's because tools like memcached allowing for greater scaling and the fact that you can get such fast hard drives now (thinking of SSD drives) that performance is not such a consideration (see this post for how it didn't make any major differences).
An example of an interesting using of memcachd is Twitter. A very smart idea for ramdisks is a privacy system, especially for local user - just think shutdown and the data is gone (idea from Surasoft).
Back when I ran sendmail, I used a ramdisk (technically, Linux tmpfs, but it's functionally the same thing) for the hoststat database. It takes up very little room, but it creates a ton of inodes. Sendmail didn't (at the time) do any housekeeping on it, and it grows quickly even on a modestly busy mail server. I used a ramdisk so my cleanup script wouldn't cause the disks to thrash about due to all the directory lookups.
Solaris mounts /tmp in ram (or swap, depending on how you look at things), and you can set up Linux to do the same. Ages ago, I had a the same set up on my OS/2 box, I'd unpack stuff there, and it was good for a speed improvement (original was on disk, not having to hit disk was a win, and OS/2 had a fixed size disk cache).
Although it's not literally a RAM disk, the architecture of Mailinator is in the same spirit. Basically, since the content Mailinator handles is not 'valuable', they can afford the risk of its loss to dramatically improve performance.