Link to home
Start Free TrialLog in
Avatar of rtrujill21
rtrujill21

asked on

Topas in AIX showing 100% disk busy

I noticed when i ran topas on aix 6.1 my disk is showing 100% busy on my db2vg. So I added another disk to the system via extendvg. My question is, do i actually have to spread the filesystems across to share the load? or what is a good way to spread the disk load across multiple disks?
Avatar of woolmilkporc
woolmilkporc
Flag of Germany image

Hi,

that depends on the kind of disks you have.

If your disks are all chunks of an array, let's say from a DS8000, spreading only makes sense if the disks are in different arrays, possibly located on different controllers and accessed via different adapters.

If this is the case or if you have independent disks, yes, you should spread the filesystem(s). Consider using 'reorgvg' to do so, after having set an allocation policy of "maximum" for the LV in question.

wmp

Q My question is, do i actually have to spread the filesystems across to share the load?
A Yes

Q what is a good way to spread the disk load across multiple disks?
A If the disks are attached to a RAID adapter then you could make a RADI-0 array but you will need to backup the data first because you cannot change a non-RAID disk into a RAID disk without a baclup/restore. If no RAI adapter, then you can use "migratepv" to move a whole LV and therefore the filesystem it contains onto the new disk.
Avatar of Kerem ERSOY
Kerem ERSOY

Hi,

In fact it depends on how disks are spread across your system. There are several ways that you attach a disk to an AIX system. If your system is just using a local  dsik attached to hte same physical adapter might not help you much if you don't use disk striping. Local disks are mechanical devices and there speed is deped on a mechanical movement of the head  which takes miliseconds to move from die to side. AIX disk management allows you place a partition to the various pars of the disk. The middle is being the fastest. You could try to move your parttion to the middle of a partition. You  might also want to add more adaptters to your system and assign disks to different adapters to mek it faster. But don't forget that the bottleneck here is your bus speed.

If you need more performance you might like to use SSA or DSA systems.. But you need to contatct IBM and you can work together to find the best solution for your case.

Cheers,
K.


Avatar of rtrujill21

ASKER

Thank you all for such a fast response. The output of:
lsdev -Cc disk
hdisk0 Available 04-08-00-3,0 16 Bit LVD SCSI Disk Drive
hdisk1 Available 04-08-01-3,0 16 Bit LVD SCSI Disk Drive
hdisk2 Available 04-08-ff-0,0 SCSI RAID 5 Disk Array
hdisk3 Available 00-08-02     IBM MPIO FC 2107
hdisk4 Available 00-08-02     IBM MPIO FC 2107
hdisk5 Available 00-08-02     IBM MPIO FC 2107
hdisk6 Available 00-08-02     IBM MPIO FC 2107

hdisk2 is where the db2 database resides and is currently the one with the issue. I added hdisk3, 4, 5, 6 from the DS8300 for extra space. After reading some of your solutions I was wondering, since hdisk2 appears to be a RAID 5 Array, can i spread the data across itself? or how does that work
Though it is an array it is over the sam SCSI disk with hdisk 0 and hdisk1 (04-08). If migght be a good idea to use other drives but it seesm that all your drives are accessed over the same FC HBA so this might caous trouble. I'll be sending you alink about DB2 Performance enahncements using different media..


 
hdisk2, being an RAID-5 array, consists itself of several disks. Data is spread automatically across the disks in such an array.

If the new disks are big enough, you should consider moving all data off the RAID array to the DS8000, as it's probably faster.

To do so, extend the VG in question by the new disks:
extendvg [vgname] hdisk3 hdisk4 hdisk5 hdisk6 ,
change the logical volumes contained on hdisk2 to "maximum" allocation policy:
chlv -e x lvname1 , chlv -e x lvname2 , ...
and do a
migratepv hdisk2 hdisk3 hdisk4 hdisk5 hdisk6
(You can also leave out the target disk specification, if there are no other disks in the VG).

If there is enough space on hdisk3 to hdisk6, hdisk2 will become free.
You could then remove it from the VG:
reducevg [vgname] hdisk2
to use it in another VG for other data, or levae it there for future expansion.

Should you need more detailed instructions, please ask - I will assist you.

wmp






wmp,

That sounds like a good solution, but why would the disk be pegged at 100% already when its in an array. There is still alot of space left.

bash-3.00# lspv -l hdisk2
hdisk2:
LV NAME               LPs     PPs     DISTRIBUTION          MOUNT POINT
db2vglog              1       1       01..00..00..00..00    N/A
db2logslv             96      96      00..10..41..45..00    /db2logs
db2datalv             256     256     00..256..00..00..00   /db2

bash-3.00# lspv -p hdisk2
hdisk2:
PP RANGE  STATE   REGION        LV NAME             TYPE       MOUNT POINT
  1-265   free    outer edge
266-266   used    outer edge    db2vglog            jfs2log    N/A
267-267   used    outer middle  db2logslv           jfs2       /db2logs
268-523   used    outer middle  db2datalv           jfs2       /db2
524-532   used    outer middle  db2logslv           jfs2       /db2logs
533-554   used    center        db2logslv           jfs2       /db2logs
555-778   free    center
779-797   used    center        db2logslv           jfs2       /db2logs
798-842   used    inner middle  db2logslv           jfs2       /db2logs
843-1063  free    inner middle
1064-1329  free    inner edge

Is there a way to reorganize the current setup instead of adding other disks?

Ron
You wrote that topas shows the disk 100% busy, not 100% full!

Each hdisk, whether it's backed by an array or not, can only handle a certain amount of I/O transactions in a given time.

100% busy means that topas found the disk (or array, if you prefer) busy doing I/O each time it was sampled, which comes rather close to the fact that the maximum achievable number of I/Os is reached.

So I fear that there is no way to improve the disk's throughput. The assumption that the middle of a disk gives the shortest response time is not true for arrays.

As for the MPIO disks - are they connected via multiple paths? lsdev only shows that they are all on the same DS8000 machine.
If in doubt, issue 'lspath -l hdisk[x]' and check how many paths are displayed.
With sddpcm drivers being used, you could also issue 'pcmpath query device' and see what you get.

wmp



wmp,
Sorry, i guess i should have given a little back story. When DB2 jobs are run topas shows disk busy at 100% while the job is processing. The database is in the db2vg which contains hdisk2. So I guess my question is what is the best way to solve the disk busy 100% issue? Will adding another disk to the db2vg even help at all?
Yes it will,

because it's obviously so that the hdisk2 array can't handle peak traffic (or nearly can't).
As topas shows 100% disk busy, the array itself is the tightest bottleneck, although the I/O path(s) could play a role, too.

With another disk you will get more read/wite heads and more platters, which will lead to more I/Os per time period being possible , thus either lowering the 'busy' percentage or actually allowing for more I/O.
Ok,
So now that we got that straightened out, I have added a few disks via the DS8300 to the system. Should I try and add one of the new disks to the Raid array? Or should I add the disk to the db2vg and have a whole new hdisk in that volume group?

ASKER CERTIFIED SOLUTION
Avatar of woolmilkporc
woolmilkporc
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thank You Soooo Much wpm.
I will do that right now
RAID 5 Array are not top performers when it comes to disk performance. besides you have a bottlenck of your I/O adapter and where was it placed. Adding more disks to an array would not solve the problem. I'd also observe I/O Wait though you know your aRRAY is saturated you don't know what is the impact on your database so I'll suggest you monitor your DB2 first to see ehat is caosuing High throughput and depending on the result you might want to put your tablespace in diffrent disks