%wio

[sycncs]

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.

[Michael Tully]

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.

[sycncs]

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?

[Michael Tully]

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.

[sycncs]

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.

[T G Manikandan]

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

[sycncs]

runq-sz is in the range of 1.0 to 2.6

[T G Manikandan]

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

[sycncs]

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.

[Stefan Farrelly]

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.

[T G Manikandan]

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

[Dave Wherry]

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.