Tru64 5.1b error

[Ivan Ferreira]

It seems that the database should be tuned. Also, could be helpful if you post your /etc/sysconfigtab file and the results of ipcs -a.

You can also post the results of collect -sd -i 10 -R 40s

[Adam Strobel]

Hi Ivan

Attached are the ipcs -a, sysconfigtab and collect -sd -i 10 -R 40s which said Ouch! at the end.


thanks,

Adam

[Adam Strobel]

how can I find out what disks these are on my storage device?


# DISK Statistics
#DSK NAME B/T/L R/S RKB/S W/S WKB/S AVS AVW ACTQ WTQ %BSY
0 dsk0 0/0/0 0 0 0 1 18.07 0.00 0.00 0.00 0.30
1 dsk1 0/1/0 0 0 0 0 0.00 0.00 0.00 0.00 0.00
2 dsk15 1/0/3 23 2530 0 0 178.42 0.00 4.12 0.00 99.98
3 dsk16 1/0/1 0 0 0 0 0.00 0.00 0.00 0.00 0.00
4 dsk20 1/0/2 0 0 0 0 0.00 0.00 0.00 0.00 0.00
5 dsk12 1/0/11 4 1638 0 0 722.51 0.00 3.40 0.00 99.38
6 dsk22 1/0/4 0 0 0 0 0.00 0.00 0.00 0.00 0.00
7 dsk17 1/1/2 0 0 0 12 2.93 0.00 0.00 0.00 0.10
8 dsk18 1/1/3 0 0 0 12 3.91 0.00 0.00 0.00 0.10
9 dsk19 1/1/4 0 0 56 2815 15.97 0.00 0.91 0.00 6.60
10 dsk21 1/1/1 0 6 0 12 5.05 0.00 0.00 0.00 0.30
11 dsk13 1/1/10 0 25 0 0 7.93 0.00 0.01 0.00 0.60
12 cdrom0 4/0/0 0 0 0 0 0.00 0.00 0.00 0.00 0.00

#### RECORD 2 (1130437845:0) (Thu Oct 27 13:30:45 2005) ####

[Ivan Ferreira]

Normally, if you run

show storage

In the storage, you will see the storagesets with an ID.

When you run in the o.s.

hwmgr v d

You will see the same ID. If you don't then you may match the size in the storage and the size on the server.

[Adam Strobel]

thanks,

What I'm trying to figure out is from the "collect" data if I can match it up with the drive configs if I do a "df"

attached is the output from my "collect" and "df". I would like to know more about the two disks show 99.80 %BSY and what a0? it belongs to.

[Ivan Ferreira]

The ipcs was cutted and I could not see the size of the shared memory, also I would like to know the total size of the RAM, use vmstat -P (Is it 5 GB?) If so, memory kernel parameters are good.

Your I/O to the disks is too high, there are no kernel parameters (in /etc/sysconfigtab) that can help to reduce significativelly this, you need to tune the database and applications.

Anyway, you can tune these parameters:

Create a file called /tmp/sysconfig.stanza, and in the file put:

rt:
aio_task_max_num = 8193

vfs:
fifo_do_adaptive = 0

Then run:

sysconfigdb -m -f /tmp/sysconfig.stanza

You need to reboot the server after that.

[Adam Strobel]

thanks!

Attached is the vmstat -P


--Adam

[Ivan Ferreira]

Look, collect data shows the device names, you can know the domain that use that device name by using ls /etc/fdmns/* or by using showfdmn domain_name.

For example:

sample_domain#sample 125829120 74867088 50962032 60% /sample

showfdmn sample_domain

Id Date Created LogPgs Version Domain Name
41637d45.0106fc56 Wed Oct 6 09:06:13 2004 512 4 sample_domain

Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name
1L 125829120 52343200 58% on 256 256 /dev/disk/dsk31c


Another thing, after you discovered the device-domain match, you should verify why only two of all disks are too busy. You should try to balance de I/O among the other disks. Try moving datafiles or log files to the other disks.

[David_854]

Ivan,
Good point and tips.


Adam,
Let us know how it went after you look at the drives.

David

[Robert Walker_8]

Adam,

To find out what disks you have do a showfdmn on the disk in question this should return a /dev/disk/dsknn in the config:

Eg:
# df -k
( note data trimmed for example)
dd5#temp 49306800 65104 38522960 1% /data/temp
#
# showfdmn dd5
Id Date Created LogPgs Version Domain Name
42150e88.000ec089 Thu Feb 17 21:37:12 2005 512 4 dd5

Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name
1L 98613600 77045920 22% on 256 256 /dev/disk/dsk5c

This points out which dsk it is in this example dsk5c.

# hwmgr show scsi
SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH
-------------------------------------------------------------------------
78: 10 fred disk none 2 2 dsk5 [2/6/0]

This disk dsk5c is on a lun of 2/6/0 on in our case and EMC san.

Hope this helps.

Also another area if your database is doing lots of lookups may be that an index on your database has been dropped - usual practice when doing large uploads is to remove indexes and recreate later, however if someone forgot to apply an index then the whole process can slow down considerably when users get access to the system.

Regards,

Robert.