topic Re: %wio in Operating System - HP-UX

%wio

sycncs — Wed, 30 Apr 2003 04:14:36 GMT

When I do a sar, I noticed %wio is high at over 80. But I could not find anything that is hogging the system. I did notice that memory utilisation is exceptionally high at 80% too. What could I do to bring down the high percentage? Pls advice - Thanks.

Re: %wio

Michael Tully — Wed, 30 Apr 2003 04:35:14 GMT

It could be that your buffer cache is set too high. What are the current values for 'dbc_max_pct' and 'dbc_min_pct' in your kernel?

# kmtune -l -q dbc_min_pct
# kmtune -l -q dbc_max_pct

These values should be set to around 300-500mb, no more, so on a system with 2Gb of RAM, around 15% should be set.

Re: %wio

sycncs — Wed, 30 Apr 2003 04:52:09 GMT

My results are:
kmtune -l -q dbc_min_pct
Value 5
Default 5
kmtune -l -q dbc_max_pct
Value 15
Deafult 50

My memory is 512MB.
Is my settings ok?

Re: %wio

Michael Tully — Wed, 30 Apr 2003 04:59:11 GMT

What actually runs on the server? This may determine what the problem is. It could be that you need additional RAM in your server. I don't see a real problem with the current buffer cache settings.

Re: %wio

sycncs — Wed, 30 Apr 2003 05:05:31 GMT

The server is functioning as an Omniback Cell server. We have been using this for the last 2 years and it is only a couple of weeks ago that this problem came up. It slows the whole omniback backup process by about 30% of the usual completion time.

Re: %wio

T G Manikandan — Wed, 30 Apr 2003 05:05:54 GMT

If wio% is over 80 then what about the output of runq-sz in the sar -q output.

runq-sz column indicates the the average queue of processes.

Make sure it is not more.

Revert

Re: %wio

sycncs — Wed, 30 Apr 2003 05:25:00 GMT

runq-sz is in the range of 1.0 to 2.6

Re: %wio

T G Manikandan — Wed, 30 Apr 2003 07:09:08 GMT

runq-sz looks fine.

how about the distribution of data across disks?

check using sar -d and iostat to find the I/O rate.

Does swapping/paging has increased the I/O on a specific disk.

Revert

Re: %wio

sycncs — Wed, 30 Apr 2003 07:50:24 GMT

Yes. I can see that IO rate are extremely high at /dev/dsk/c0t1d0 and /dev/dsk/c4t1d0, both belongs to vg01 and is housing Omniback datafiles.

Re: %wio

Stefan Farrelly — Wed, 30 Apr 2003 08:49:08 GMT

The Omniback database is very intensive on disk I/O. Its best to move it to a disk all of its own - something fast, and prefereabbly something you can stripe to speed it up even more. This is the only way to reduce your wio%. At 80 your compeltely i/o bound. We normally run an Omniback database over a couple of scsi channels over a few disks and striped to get good performance out of it and to not hogg the system for other applications.

Re: %wio

T G Manikandan — Wed, 30 Apr 2003 08:57:19 GMT

If that is the case,
you need to distribute the I/O among different disks.

Re: %wio

Dave Wherry — Thu, 01 May 2003 13:07:28 GMT

If you are disk constrained, really can not do much to balance the i/o, you could reduce the logging level. My guess is you are logging every file and you are backing up lots of small files. The number of files you are backing up may have recently increased on one of the systems. By reducing the level of logging you would reduce your i/o.
On the other hand, I usually like to log everything so I can find it when I need to restore a single file. Users do not always remember what directory that missing file was in.
You have to find a balance that works for you.