ADSM-L

Re: A little database performance foo

2006-10-22 11:43:21
Subject: Re: A little database performance foo
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sun, 22 Oct 2006 11:41:48 -0400
>> On Sat, 21 Oct 2006 18:34:46 -0700, Jason Lee <english AT ANIM.DREAMWORKS 
>> DOT COM> said:

>> For ~350GB of DB, I've got 11 servers, 9 customer-facing, on one
>> box.  Now, I'm using relatively sucky old hardware (18G 10K SSA
>> drives), but that means I've got 9 threads wandering around a
>> smaller DB displacement.

> That's where I'm at... gotta break this bad boy up. I knew the day
> was coming, but it was just recently that I suddenly started to get
> way behind - it's a vicious cycle, the more behind you get, the more
> behind you get!

Amen there.  The good part about that is that your initial correction
efforts will have an outsize impact.  You can back down an exponential
slope, too.

> I was hoping that I had my box setup incorrectly, but it appears
> that in reality I have a "well performing database" - scary.

> I see another late night or two coming up :-)

It needn't be so.  Depending on your politics with the client admins,
it could be pretty simple.

If you're thinking of deploying multiple servers on the same hardware,
it's going to require the client admins changing a port.  If you can
set them up on different boxen you can just train them to use a
different name and the -same- port (though I recommend different ports
Just In Case you later want them on the same hardware).  That's all
the client-side config change you need.  Then it's just politics.

Least effort is you just pick a nightly batch of boxen to point at the
new server, they do a new initial incr, and you blow away the
old-server node N days downrange.  Since you say your clients are
pretty unloaded, this might be the most effective way to get the job
done.

Of course, it can get more complex than that. :) The scariest one is
backing up the database, restoring it to a second server, intended to
be simultaneously live, and deleting all the 'B' nodes from server A,
and all the 'A' nodes from server B, and playing games with the tape
locations.

I once took a stab at cataloging all the scenarios for moving data
from one server to another which folks have talked about.

http://open-systems.ufl.edu/services/NSAM/whitepapers/50ways.html

I periodically rattle cages in case someone does something I didn't
think of.



- Allen S. Rout

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