Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are currently designing our new database servers, and have come up with a trade off I'm not entirely sure of how to answer.

These are our options: 48GB 1333MHz, or 96GB 1066MHz.

My thinking is that RAM should be plentiful for a Database Server (we have plenty and plenty of data, and some very large queries) rather than as quick as it could be. Apparently we can't get 16GB chips at 1333MHz, hence the choices above.

So, should we get lots of slower RAM, or less faster RAM?

Extra Info:

Number of DIMM Slots Available: 6
Servers: Dell Blades CPU: 6 core (only single socket due to Oracle licensing).

share|improve this question
12  
IMO, 100% more RAM capacity beats an added 20% in RAM speed. –  Joe Internet Sep 27 '11 at 6:22
3  
Especially because it is not even 20% ;) –  TomTom Sep 27 '11 at 8:19
    
Thanks everyone. I was fairly sure of this also, but wanted confirmation. –  Josh Smeaton Sep 27 '11 at 10:50
add comment

7 Answers 7

up vote 59 down vote accepted

You will want to go with the large and slow RAM. The difference in RAM performance is negligible compared to the difference between RAM performance and disk performance.

share|improve this answer
    
Of course, this depends on database size - basic details but important still. –  Morg. Nov 21 '12 at 9:21
    
Yes, and Josh clearly specified that the scenario at hand involves "plenty and plenty of data." –  Skyhawk Nov 21 '12 at 19:23
    
For some people, a million rows looks like "plenty and plenty of data" Hardly a reason not to have everything in memory though ;) –  Morg. Dec 1 '12 at 15:55
add comment

Alright, it's very very very simple :

Does your database fit in 48GB of RAM with OS and all ? if yes, take that. Else, take 96GB

Also, database fitting in xyz GB of RAM means it fits with index's, views and all that.

SSD comments are complete utter nonsense, both the bandwidth and access time are not on the same level and no SSD can justify taking less RAM.

share|improve this answer
5  
This is very important info. If the database is only 5GB and isn't planned to get much bigger, then you might as well go with a smaller amount of faster RAM. –  Kibbee Sep 27 '11 at 20:26
add comment

Database only? Depending on the database, I would think the larger RAM would be better. Speed difference has been proven to be miniscule at best, but the additional 48gb will / may make a huge difference.

share|improve this answer
add comment

Definitely large RAM, speed be damned.

Access to random data for RAM technology from XX century '90 is below 100 ns. That's using practically ancient chips that won't even physically fit into anything borderline contemporary.

Access to random data for cutting edge 15k rpm hard drives is in measured in miliseconds. 100 ns is 10 000 times shorter (nano -> micro -> milli) than 1 ms. Current RAM is faster, and HDD needs several milliseconds to access data. I couldn't care less if my RAM was 50 000 faster or only 30 000 times faster than HDD, if I could get more.

share|improve this answer
add comment

You must take your attention in some points:

  • Memory lantecy Memory speed depends on two factors: bus speed and latency. Usally chips with more density result in a higher latency, wich finaly means less speed
  • Total index data The most critical y to load the entire index data into memory. Index data is the most critical data you need in memory (higher penalty effect in performance).
  • Disk speed Do you have the DB data stored in SSD? If the answer is yes, take care specially of memory latency.
share|improve this answer
add comment

MEMORY BANDWIDTH =/= SPEED!

Probably the most important piece of missing information information is the memory timings and CPU/FSB type. lower the CPU memory load delay by a few cycles and you will blast ram double the bandwidth in certain calculations. Some databases dont use massive amounts of ram due to operating system and technical reasons, what database server are you using? CPU type? L[123] cache levels? type of queries to be run? size of the database?

share|improve this answer
2  
-1. Factualy wrong in 99.9% of the cases. –  TomTom Sep 28 '11 at 4:18
    
What part are you referring to? –  Silverfire Sep 28 '11 at 5:42
2  
Any database larger than memory slows down immediately. cpu cycles are a joke compared to - unless it is a very special OLAP case - the IO latency introduced. Most databases use hugh amounts of ram - the samllest dataase SERVER I have seen that is not a joke for a tiny database is many times bigger in RAM usage than the average workstation. Unless you insist on using hughely outdated technology ("os system limits"). And neither cpu speed nor fsb type make a difference - databases need memory. –  TomTom Sep 28 '11 at 5:49
add comment

Before spending too much money on wrong hardware, I would do some tests and analysis before buying hardware.

  • First of all, think about your SLA.
  • any hard requirements to performance and response times?

You choice should depend on many factors:

  • under different workloads and usages, what is actually the bottleneck?
  • CPU, memory, storage, network?
  • Is it perhaps more important to spend more money on faster storage than more memory?
  • faster CPU than more memory? faster network? minor redesign on sofware/sql?

  • you analysis could also be very much relevant to the developers, database and software architcts, and sql query designers.....

If you are using windows - you could easily run perfmon to see some statics on the current running system and mayby be very lucky to get a clear idea of your your needs.

share|improve this answer
1  
I am a developer, and am helping to weigh in on this decision. We lack a real sys admin, so we all (6 of us) have input into the discussion. Our current servers are 32 bit, and are incapable of doing very much due to the memory limit per process. Our network/storage is (should be) fine for the moment. The storage backend is a SAN. Our CPU is never maxed. Most of the cost associated with our queries is I/O, which should be relieved by the ability to use more RAM. We're also upgrading to RAC. We have a clear idea of what we need. It's the minutia that's questionable. –  Josh Smeaton Oct 30 '11 at 23:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.