Prev: Drawbacks of automatic storage?
Next: Table partitioning i DB2 9.7 LUW
From: Troels Arvin on 27 Jan 2010 20:09
Hello,

When sizing a new server, I can choose between 96GB of very fat RAM
(1333MHz DDR3), or 128GB of slightly slower RAM (1066MHz DDR3). The
server will be running DB2 v. 9.7 on Linux (64 bit). The amount of data
will be around 10TB. The database will regularly be executing a lot of
rather heavy GROUP BY operations (part of MQT refreshs).

Should I opt for the 96GB of fast RAM or 128GB of slightly slower RAM?

--
Troels
From: Hardy on 28 Jan 2010 08:30
On 1ÔÂ28ÈÕ, ÉÏÎç9ʱ09·Ö, Troels Arvin <tro...(a)arvin..dk> wrote:
> Hello,
>
> When sizing a new server, I can choose between 96GB of very fat RAM
> (1333MHz DDR3), or 128GB of slightly slower RAM (1066MHz DDR3). The
> server will be running DB2 v. 9.7 on Linux (64 bit). The amount of data
> will be around 10TB. The database will regularly be executing a lot of
> rather heavy GROUP BY operations (part of MQT refreshs).
>
> Should I opt for the 96GB of fast RAM or 128GB of slightly slower RAM?
>
> --
> Troels


personally and slightly I opt for the 128G one,if I have to choose one
for now. The disk I/O always becomes the bottleneck than memory does.
with more memory, you may have a little more flexiblity - 96G is also
a large one.

How many data partitions in your plan? How many HBAs ordered for your
box? investment on these may perform better.
From: Troels Arvin on 28 Jan 2010 13:16
Hardy wrote:
> personally and slightly I opt for the 128G one,if I have to choose one
> for now. The disk I/O always becomes the bottleneck than memory does.

Yes, that's what I used to think, as well. However, more and more, I hear
respectable people talking about "RAM as the new disk" - that RAM is
increasingly becoming a bottleneck, overall (one of the main arguments
for column oriented databases).


> How many data partitions in your plan?

You mean storage paths? It will probably have four LUNs for data storage
(one for each HBA), and a special storage system for transaction logs.

--
Troels
From: Hardy on 29 Jan 2010 07:10
On 1ÔÂ29ÈÕ, ÉÏÎç2ʱ16·Ö, Troels Arvin <tro...(a)arvin..dk> wrote:
> Hardy wrote:
> > personally and slightly I opt for the 128G one,if I have to choose one
> > for now. The disk I/O always becomes the bottleneck than memory does.
>
> Yes, that's what I used to think, as well. However, more and more, I hear
> respectable people talking about "RAM as the new disk" - that RAM is
> increasingly becoming a bottleneck, overall (one of the main arguments
> for column oriented databases).
>
> > How many data partitions in your plan?
>
> You mean storage paths? It will probably have four LUNs for data storage
> (one for each HBA), and a special storage system for transaction logs.
>
> --
> Troels

4 LUNs? each for important tablespace? the size of your database? the
size of active data?

it's good to see you have 4 HBAs. I guess they are good enough.

I again suggest more attention on database physical design to fully
utilized your HBAs, or if needed, more HBAs if you're
in a warehousing environment. This point is never to be
overemphasized.



From: Troels Arvin on 29 Jan 2010 14:47
Hardy wrote:
>> > How many data partitions in your plan?
>>
>> You mean storage paths? It will probably have four LUNs for data
>> storage (one for each HBA), and a special storage system for
>> transaction logs.
> 4 LUNs? each for important tablespace? the size of your database? the
> size of active data?

The LUNs will reside on a storage system which takes care of spreading
the data over a very large number of disks. The four paths to the storage
system accept I/Os concurrently. So, given four paths to the storage
system, it seems to me that I should provide DB2 with four file systems
(using automatic storage). Transaction logs will sit on a rather fast
local RAID10.

Does this make sense?

--
Troels
 |  Next  |  Last
Pages: 1 2
Prev: Drawbacks of automatic storage?
Next: Table partitioning i DB2 9.7 LUW