This is a GREAT question and I find the responses fascinating. I am going to comment on this as an Oracle DBA and my answers are SPECIFIC to the Oracle database. This is a major mistake a lot of people make when working with Oracle. I am not sure if this applies to other applications as well. This is not meant to be off-topic, but is meant as a specialized answer.
When you tune performance with Oracle, you are really looking to clear up bottlenecks. Though most of us don't say it, it is based on the Theory of Constraints: https://en.wikipedia.org/wiki/Theory_of_constraints
Memory may not be your bottleneck. Oracle has complex mechanisms for managing memory and just increasing memory can actually slow things down if other areas are where the bottleneck is. Let me give you one example that is VERY common.
Queries seem to be slow. The consensus is if we increase RAM, we should increase the response time of queries since memory is faster than disc. Well... This is how Oracle handles memory management for data. Oracle has a variety of memory locations that are allocated to specific duties. So you can increase these memories. The area used for data is called the 'buffer cache'. This is a series of linked lists (the number of them tend to increase with each version). Every time a block is found on disc during a query, a hash algorithm is run on it to determine which list to stick it in. Where to put it in the list is based on a touch count algorithm (explained on the Oracle support site, so you have to pay to get it... it's not really important).
HOWEVER, when you run a query, Oracle takes out a latch on the buffer chain you search at the time. This LATCH (note: this is not a lock. Google "latch" if you don't know the difference) blocks all other operations on that chain for the duration of your read. So it blocks reads AND writes (this is entirely different than Oracle claiming locks don't block reads).
This is necessary because as you read the block in the chain, Oracle moves it around based on how often it is 'requested'. More frequently requested blocks are moved to the top and less frequently requested blocks are left at the bottom and aged out. You cannot have 2 sessions reading a linked list and moving blocks around or you will hit pointers that point to non-existent locations.
When you increase the size of memory, you increase the size of each linked list. This increases the time it takes to read the list. A single poor query or complex query can do tens of thousands or even millions of reads down linked lists. Each read is fast, but the number of them leads to latches taken and these will block other sessions. Oracle calls this a 'logical IO' (or buffer get or some other stuff. This lingo is specific to Oracle and may mean something else in other parts of IT).
So, if the list is longer and you have really bad SQL, then the SQL statements will hold their latches longer. Increasing memory can occasionally REDUCE performance. Most of the time, this won't happen. People will spend a lot of money and see no benefit. That being said, there are times when you need more memory in the buffer cache, but you have to properly identify the bottleneck to know whether this is appropriate. I can't discuss how to analyze this in this post. See the DBA forums. Some people discuss it there. It is rather complex.
Does anyone have specific examples with other pieces of software where this can happen? There is a terrific business book called 'The Goal' that discusses alleviating constraints in a factory. This process is very similar to what Oracle DBAs do when assessing performance issues. It is often standard reading in MBA programs. It is very valuable to read for IT professions.
https://en.wikipedia.org/wiki/Eliyahu_M._Goldratt
1
@AlanShutko - cheap & cheap
– vsync – 2015-12-08T17:56:25.337109You assume RAM is cheap. How much does 1TB of RAM cost? – Alan Shutko – 2013-08-27T15:28:39.477
39What you describe is called a RAMDisk and people already do what you describe. I load most of my programs in memory using a RAMDisk. You also don't need special hardware you can use system memory and software to do this. – Ramhound – 2013-08-27T15:38:54.990
Computers used to work this way, before there was permanent storage. The problem was when you turned the computer off and on, you had reenter a program from scratch. – Keltari – 2013-08-27T15:54:40.073
16We do, under the covers, to the extent that a given OS supports it. Windows uses "unused" RAM for "disk cache", and I assume that many versions of Linux do too. But there is far too much disk to ever fit it all into RAM. – Daniel R Hicks – 2013-08-27T20:03:33.680
19"cheap" is a relative term. Each bit of memory is cheaper than it was a couple years ago, but it's more expensive than storage on a hard drive. And anyway the march of progress will ensure that programs always fill up all available RAM no matter how much is available; if everybody's computer suddenly had more RAM available, developers would put more stuff into their programs. – jhocking – 2013-08-27T20:40:20.450
15Google loads the internet to RAM – Ari – 2013-08-27T22:07:29.477
Short of early boot stages of Linux kernel images, nobody has used anything called "ram disk" since the days of DOS, early Windows or 68K Macintoshes. In modern systems, demand paged virtual memory takes care of caching used portions of executables. – Kaz – 2013-08-27T23:38:27.073
3RAM is cheap, but programs are huge. A PC XT with a 10 Mb (!) hard disk was huge once. Some decade and a half later, so was a 486 with an 800 Mb drive. Today, a cell phone with a Gb of RAM somehow has barely enough. You can have everything in RAM perhaps if you cob together a really spartan GNU/Linux distro. – Kaz – 2013-08-28T00:08:49.387
There are people who are very interested in doing exactly this. In particular several folks at Stanford are working on a project called ramcloud. Read more here: https://ramcloud.stanford.edu/wiki/display/ramcloud/RAMCloud
– None – 2013-08-28T00:46:45.6106@kaz Linux actually offers RAM disks during operation and they are frequently used for /tmp on modern distros. – mikebabcock – 2013-08-28T03:10:07.167
2@Doov RAMCloud is totally stupid. The bottleneck in the cloud is the delivery network, not the storage. (And not just the network hardware but basically the entire software stack from the kernel and up. What good is it to access the data in nanoseconds when it has to be copied several times and go through a chain of 25 function calls). Servers already make use of virtual memory: things are served from RAM. – Kaz – 2013-08-28T03:11:52.140
This is what memcache for... – Rudy – 2013-08-28T06:28:02.543
1I used to work on a Toshiba HX-20. That's a Z80 computer with MSX BASIC interpreter, and had 32KiB of RAM + 32KiB of RAMDISK. So we were using ramdisks more than 20 years ago :) Also, there was the RAMDISK utility for MS-DOS and some people did set up AUTOEXEC.BAT to copy some stuff there at every boot. – Luke404 – 2013-08-28T13:27:38.973
1RAM is still more expensive per GB than SSD or HD storage. – fortran – 2013-08-28T13:35:03.773
1@luke404: I remember booting an Amiga of a reset surviving ramdisk (The disk commonly called
RAD:
, not the drive calledRAM:
which changed its size when needed, but did not survive a reboot. – Hennes – 2013-08-28T16:40:05.920ReRAM and other upcoming technologies designed to replace flash based SSDs are in the works that have ram like performance that is non volatile. Although these most likely will not be priced like hard drives. I mean 1TB for $70 US not going to happen on these any time soon. – drescherjm – 2013-08-28T18:17:34.297
1If you hibernate and then resume a computer, you are pretty much doing what the OP is asking for. – Adrian – 2013-08-28T18:19:42.043
There had been a product called HyperOS. It uses RAM Sticks as SSD Drives. I've bookmarked their website long time ago, way long before flash based SSD's came up.
– GaryP – 2013-08-28T20:34:04.9531
SGI has already products allowing single host running RHEL or SUSE with up to 64T memory. See: SGI - Products: Servers: SGI UV However, the price and size is not the same as a traditional computer you use everyday.
– Wei – 2013-08-28T09:47:41.070Operating systems already essentially do this. That's why you never have much free RAM, even when you're not running much. Otherwise, it goes to waste. – asmeurer – 2013-08-29T04:51:15.180
4Also, what does "everything" (in "load everything to RAM") mean? Every program on the hard disk? But you could have, say, 10 huge games installed and only want to play one -- why waste all the time (and RAM!) to load them all? You practically never need everything you have installed at the same time! – nplatis – 2013-08-30T20:42:50.370
We are limited by the limits of the current consumer memory-technology – Lorenz Lo Sauer – 2013-09-01T05:56:14.447