In my experience, "smart load balancing" does not really exist. I
thought I had heard of it, so I went looking on my system to see if it
was doing anything to help. If the Database has plenty of room in it,
and you add a new extent in hope of spreading out the I/O load, that
extent will not be used at all. You cannot spread out the I/O load just
by adding more DBvols. Since I could find no evidence of it helping, I
suspect it can't hurt much either, in a RAID situation.
I have had to use the brute force method - "dumb load balancing". That
is, squeezing the database into the shape I want with DELETE DBVOL.
Making this work takes careful advance planning, but the payoff can be
big. RAID may make this harder, since the underlying physical disk
structure may be hidden from you.
I cannot speak for RAID, because I have avoided it, but for JBOD disks,
is not a big problem to have DB and Log on the same disk, except that
their I/O patterns are very different, so you might want to tune them
separately. It is also not a problem to have multiple DB extents on the
same physical disk, as long as they are adjacent to one another.
Considering the random I/O pattern of the ITSM database, two adjacent
extents should be similar to one larger extent, in terms of average seek
distances. Since it neither helps nor hurts, you can use this as an
opportunity to make your manual load balancing come out the way you want
it.
The performance effect of multiple Logvols is truly neutral, because the
Log is a circular buffer, so generally only one of them is used at a
time. There are exceptions, but not enough to matter for performance.
>From a practical standpoint, having the Log split into at least two
parts can give you flexibility in moving it around without taking the
server down. In the case of the Log, I/O load balancing happens
automatically, since the whole thing is one big circular buffer.
Several people here on this list have said that Database unload/reload
is a very great help. The official ITSM manuals also say this. There are
two problems, however. First, it would take more downtime than we could
afford. Second, the benefit is temporary, and will gradually be un-done
as a part of normal processing. There were rumors that IBM was
considering making a background process that could gradually reorg the
database when the system wasn't busy. This would be great, and could
achieve a permanent improvement in database disk performance. I hope
they do this.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
On Mon, 2 Sep 2002, Remco Post wrote:
>On maandag, september 2, 2002, at 11:26 , Daniel Sparrman wrote:
>
>> Hi
>>
>> The large disks you are talking about, are you meaning large as 36GB,
>> 72GB
>> an so on, or are you talking about LUN-sizes?
>>
>
>Disk size, 72 GB or so....
>
>> In a shark, you can have very large LUN:s, but they will consist of a
>> large number of smaller SSA-based hard drives. This means that you will
>> not have a performance impact on the disks.
>>
>
>I know, I also know that you will have performance impact on your disks.
>I noticed that especially the IBM ssa raid controller (4-P) gives very
>bad performance on any kind of raid. I don't have a shark, so I can't
>talk about it's raid controller. Having eg. both the db volumes and the
>logvolumes on the same raidgroup will for sure give you very bad
>performance on the disks. Also, I don't think it's a good idea to have a
>database (or log) spread across multiple partitions on the same
>raidgroup. TSM will try to do 'smart' load balancing, which will
>decrease performance in that case since the disks will have to do more
>seeks.
>
>---
>Met vriendelijke groeten,
>
>Remco Post
>
>SARA - Stichting Academisch Rekencentrum Amsterdam http://www.sara.nl
>High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167
>PGP keys at http://home.sara.nl/~remco/keys.asc
>
>"I really didn't foresee the Internet. But then, neither did the computer
>industry. Not that that tells us very much of course - the computer
>industry
>didn't even foresee that the century was going to end." -- Douglas Adams
>
|
