My Processors Can Beat Up Your Processors!


Bill Cole, Competitive Sales Specialist,Information Management, IBM

I grew up a fan of Formula 1 and the Indianapolis 500. One of the great F1 racers was a British fellow named Sterling Moss.  Look him up.  Won lots of races for Mercedes-Benz and then went back to England and drove only British marquees.  They were underpowered but he still won races.  The other drivers hated it that he was driving a four-cylinder machine while they were driving V-8s and he still passed them.  And he waved and smiled as he went around them!  To paraphrase the song, every car’s a winner and every car’s a loser….

The moral of the story?  Make the most of the equipment you’ve got.  Sterling was a master of that concept.  We have the same issue in computing.  We assume that brute force will give us better performance.  Bigger is always better.  Speed comes from executing instructions faster.  Over-clocking is a wonderful thing.  More processors!!!  Gotta have more processors!  We’re geeks, so our “measuring” against each other is about our computers.  We’re dead certain that more and faster is the answer to the ultimate question of performance and capacity.

Oh really?  I know a red database that uses multiple processors to execute a single query in parallel.  Good idea?  Uh, not if you need to execute more than one query at a time on those processors.  You see, each query in that database believes it’s the only query on the system and should consume all of the resources.  No thought of tuning the workloads on the system, just single queries.  You see the white hair?  Getting the best use of all the processors was an art form with a moving target.

It’s really a matter of using your resources wisely and DB2 10.5 was created from the outset to use the system resources to enhance the performance of the all the workloads on a system.  In the example above, a simple parallel query with a low priority could essentially stop a queue full of high-priority jobs because it seized all the processors and wouldn’t give them back until the query was complete.  Explaining that one gets to be a bit technical.  Not to mention uncomfortable.

DB2 10.5 sizes up the running workloads and allocates resources according to priorities and needs.  Each new workload gets the same scrutiny before it’s added to the mix.  In fact, a low priority workload might even get held momentarily to make sure that the highest priority workloads complete quickly.  It’s that simple.

 And it’s not just processors, folks.  Memory is a valuable resource, too.  If every workload requires all the available, you’re going to have a problem.  So, in the same way as with processors, DB2 10.5 allocates memory to workloads on the basis of need and priority so that workloads complete properly.

That red database I mentioned.  It seems to believe that lots of badly used memory is the cure for everything.  They confuse the terms in-memory database and database in memory.  I’ve seen users pull an entire database into memory and still get lousy performance because the memory is managed badly.  I once re-tuned a Production database’s cache due to memory limitations causing queries to fail.  I dropped the cache size by 75% and didn’t mention it to anyone.  The next day I pointed out that we no longer had memory problems and everything was working well – and performance was what it always had been.

Note that DB2 10.5 does all this for you.  No resource groups or complicated formulas to get wrong.  No additional software to purchase or manage.  It’s all part of the package.  You don’t have to go back and modify your tables or applications.  Just load and go!  Get the benefits immediately.  Nice.

All this speaks to sizing our systems, too.  We inspect the workloads that will run on the system, not just a few queries, and fill out the necessary expenditure request.  We even add a fudge factor, right?  Maybe we add a few extra processors and a bit of extra memory as room for expansion.  But the workloads grow faster than anyone’s predictions and the hardware we ordered with all that extra capacity is going to be strained if we just throw workloads at it and hope for the best.  Making intelligent use of that capacity is our job – and the job of the software we deploy.  We can do the sizing with the confidence that our software has our back.

Finally, my uncle Emil kept a pair of draft horses on his farm long after he stopped farming with them.  He loved his horses and refused to part with these last two.  Other than being very large pets, they were good for one thing: Pulling cars out of the mud.  Folks would get stuck in the mud at the bottom of the hill after a good storm.  Inevitably, there’d be a knock on his door and he’d hitch one of the horses to the car and pull it out.  One night a truck got stuck after a good rain.  Emil hitched both horses to the truck.  The driver protested that horses couldn’t pull his truck out of the mud.  Emil smiled and talked to the horses.  They leaned into their collars and walked the truck out of the mud.  The driver opened his wallet.  Emil waved the man down the road and put the horses away.  Just being a good neighbor.  Getting the most out of our equipment is part of our compact with the business and BLU’s got that going on like no one else.  You’ll be a hero for thinking so far ahead!

Try DB2 10.5 today , and experience the innovative features and benefits that DB2 has to offer!

One Response to My Processors Can Beat Up Your Processors!

  1. Jack Vamvas says:

    Interesting point about diffferent query types i.e reporting versus oltp . Capacity planning is key :

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: