33

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

3
  • 12
    IMO, 100% more RAM capacity beats an added 20% in RAM speed. Sep 27, 2011 at 6:22
  • 3
    Especially because it is not even 20% ;)
    – TomTom
    Sep 27, 2011 at 8:19
  • Thanks everyone. I was fairly sure of this also, but wanted confirmation. Sep 27, 2011 at 10:50

7 Answers 7

59

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.

3
  • Of course, this depends on database size - basic details but important still.
    – Morg.
    Nov 21, 2012 at 9:21
  • Yes, and Josh clearly specified that the scenario at hand involves "plenty and plenty of data."
    – Skyhawk
    Nov 21, 2012 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, 2012 at 15:55
16

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.

1
  • 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, 2011 at 20:26
13

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.

11

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.

5

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

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?

3
  • 2
    -1. Factualy wrong in 99.9% of the cases.
    – TomTom
    Sep 28, 2011 at 4:18
  • What part are you referring to?
    – Silverfire
    Sep 28, 2011 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, 2011 at 5:49
0

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.

1
  • 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. Oct 30, 2011 at 23:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .