ADSM-L

Re: [ADSM-L] DB2: SSD vs more RAM

2010-11-22 15:59:44
Subject: Re: [ADSM-L] DB2: SSD vs more RAM
From: "Colwell, William F." <bcolwell AT DRAPER DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 22 Nov 2010 15:57:36 -0500
Hi Henrik,

I have 2 TSM (6.1.4.2) instances on one server.  One instance db size
(the size of the full db backup) is
558 GB, the other is 1,448 GB.

The server (IBM x3850 m2, running RHEL 5.5) started with 16 GB of ram, I
bumped it to 40 GB and then max'ed it out
with 128 GB.  I can't say I did a though performance analysis because it
was such a cheap thing to do.
When there are 2 or more instances on a server you need to use the
DBMEMPERCENT parameter in
dsmserv.opt to keep the instances from fighting for the memory and leave
some for the OS.  I have 
each set to 45%.

I started out with both databases on a Netapp, sharing 1 aggregate.  The
aggregate was 27 300 GB 15k sas
disks.  I wasn't satisfied with the performance and the usage was up to
70% so I bought a 
Nexsan "SASbeast" unit with 2 raid 10 arrays.  12 600GB 15k disks for
the smaller db and 16 disks for the 
larger DB.  I just finished moving the databases on to the arrays.  The
speed of the db backups increased dramatically.
Here is an sql query showing the last 6 dbbackups -

Activity           Start Time       End Time         Elapsed (hh:mm:ss)
Gigs
--------------     ------------     ------------     -------------------
----------
FULL_DBBACKUP      10-24-13.00      10-24-23.10      10:10:15
1390.90
FULL_DBBACKUP      10-31-15.52      11-01-00.46      08:54:39
1399.24
FULL_DBBACKUP      11-07-13.00      11-07-23.12      10:11:46
1432.42
FULL_DBBACKUP      11-14-13.00      11-14-21.22      08:21:49
1436.85
FULL_DBBACKUP      11-20-07.04      11-20-13.46      06:42:09
1442.77
FULL_DBBACKUP      11-21-15.00      11-21-17.35      02:35:54
1448.55

Line 4 is the last 'normal' backup from the Netapp (other things going
on during the backup).
Line 5 is the 'special' backup just before the restore (nothing else
going on)
Line 6 is the first 'normal' backup from the raid 10 array.  Much
faster.

Since the topic is about SSD or RAM, I can say I never considered SSD.
I expected it would be too expensive
for DB's this size.  If you are planning on doing dedup, expect the db
to grow very big very fast.

Thanks,

Bill Colwell
Draper Lab

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Henrik Ahlgren
Sent: Monday, November 22, 2010 4:25 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: DB2: SSD vs more RAM

Or maybe he has a huge amount of DB entries?  If his options are either
six SAS 15K or eight SSDs (50GB each), it means his DB is propably in
the multi-hundred gigabyte range. If he just needs the IOPS for smaller
DB, then he would not need 8 SSDs to beat 6 platters, even one or two
could be enough. (Just one Intel X25E does 35K IOPS random 4K read.) I'm
not sure how much doubling the RAM would help with operations such as
expiration, DB backup etc. compared to nice SSD setup.

I'm wondering why so little discussion here on using solid state devices
for TSM databases? Some of you must be doing it, right?

On Nov 17, 2010, at 7:50 PM, Remco Post wrote:

> SSD to me seems overkill if you already have 24 GB of RAM, unless you
need superfast performance and are going to run a very busy TSM server
with a huge amount of concurrent sessions.
> 
> -- 
> 
> Gr., Remco
> 
> On 17 nov. 2010, at 12:16, "Pretorius, Louw <louw AT sun.ac DOT za>"
<louw AT SUN.AC DOT ZA> wrote:
> 
>> Hi all,
>> 
>> I am currently in the process of setting up specifications for our
new TSM6.2 server.  
>> 
>> I started by adding 8 x SSD 50GB disks to hold OS and DB, but because
of the high costs was wondering if it's possible to rather buy more RAM
and increase the DB2 cache to speed up the database.
>> 
>> Currently I have RAM set at 24GB but its way cheaper doubling the RAM
than to buy 8 x SSD's
>> Currently I have 8 x SSD vs 6 x SAS 15K 


-- 
Henrik Ahlgren
Seestieto
+358-50-3866200

<Prev in Thread] Current Thread [Next in Thread>