Operating System - HP-UX
1747988 Members
4967 Online
108756 Solutions
New Discussion юеВ

Re: ASM devices files constant access

 
SOLVED
Go to solution
Michael O'brien_1
Regular Advisor

ASM devices files constant access

Hi,

I've noticed in Glance the root filesystem has constant "Logl IO" as does /usr filesystems (please glance output below, the root filesystem is has a larger load than /usr.

I ran lsof against both filesystems. It seems Oracle ASM is constantly accessing the disk devices files assign for the ASM disk groups, is this normal ?

Also Oracle also seems to be constantly acessing the /usr/lib/hpux64/lib* files. This doesn't seem very efficient. This accounts for the "LOG IO" on the /usr filesystem.

Thanks
Michael

File System Device Type Logl IO Phys IO

/ /dev/vg00/lvol3 vxfs 295.9/182.0 0.2/0.4
/usr /dev/vg00/lvol7 vxfs 81.5/ 81.4 0.2/0.5
6 REPLIES 6
Solution

Re: ASM devices files constant access

Michael,

>> Also Oracle also seems to be constantly acessing the /usr/lib/hpux64/lib*

What evidence do you have for that? Whikts I'd expect ASM daemons to open libraries in /usr/lib when they start up, and keep them open whilst they are running, I wouldn't expect them to do any significant read IO from those libraries once they have been opened...

What other processes does lsof show as having files open on / and /usr ?

HTH

Duncan

I am an HPE Employee
Accept or Kudo
Michael O'brien_1
Regular Advisor

Re: ASM devices files constant access

Duncan,

I noticed in glance I was seeing constant logical io to disk1_p2. So I then looked at which filesystems are we being accessed on the root disk. The 2 filesystems which were being accessed was / & /usr.

I then ran lsof against the filesystem to see which processes were accessing the filesystems.

The device files used by ASM were shown as accessing / filesystem and /usr was accessed by Oracle processes, please see extract below. The same lib files are access by 15+ pid's so the output was repeated for eaxh pid

oracle 29794 oracle mem REG 64,0x7 4792616 21004 /usr/lib/hpux64/libc.so.1
oracle 29794 oracle mem REG 64,0x7 1503200 21059 /usr/lib/hpux64/libnsl.so.1
oracle 29794 oracle mem REG 64,0x7 298848 20993 /usr/lib/hpux64/libxti.so.1
oracle 29794 oracle mem REG 64,0x7 179696 21025 /usr/lib/hpux64/libnss_files.so.1
oracle 29794 oracle mem REG 64,0x7 85680 20932 /usr/lib/hpux64/libuca.so.1
oracle 29794 oracle mem REG 64,0x7 674752 21051 /usr/lib/hpux64/libunwind.so.1
oracle 29794 oracle mem REG 64,0x7 1528360 21033 /usr/lib/hpux64/libpthread.so.1
oracle 29794 oracle mem REG 64,0x7 2214112 21024 /usr/lib/hpux64/libm.so.1
oracle 29794 oracle mem REG 64,0x7 78488 21011 /usr/lib/hpux64/libdl.so.1
oracle 29794 oracle mem REG 64,0x7 90880 21061 /usr/lib/hpux64/libnss_dns.so.1
oracle 29794 oracle mem REG 64,0x7 85568 21037 /usr/lib/hpux64/librt.so.1
oracle 29794 oracle mem REG 64,0x7 1091608 20998 /usr/lib/hpux64/dld.so
oracle 29794 oracle mem REG 64,0x7 182872 21058 /usr/lib/hpux64/uld.so
Michael O'brien_1
Regular Advisor

Re: ASM devices files constant access

Please see the average timings from sar -d for disk1

device %busy avque r+w/s blks/s avwait avserv
disk1 2.39 4.81 5 288 19.40 10.85

Re: ASM devices files constant access

Michael,

I'll re-iterate that I think you are looking in the wrong place here - it's quite usual for a process to keep the shared libraries it accesses open throughout its execution, but these won't be doing any IO to speak of - I would look elsewhere to see what other processes apart from ASM has files open on /

HTH

Duncan

I am an HPE Employee
Accept or Kudo
Michael O'brien_1
Regular Advisor

Re: ASM devices files constant access

Thanks Duncan, I just thought it was a bit unusual for asm device files to be constantly accessed. But I guess that what happens when you run a 3rd party volume manager
klb
Valued Contributor

Re: ASM devices files constant access


A third party VM written and marketed by an RDBMS vendor for use exclusively with and for their own RDBMS.

Let the RDBMS handle the DB while your VM tasks are handled by a legitimate Volume Manager and you end up with less frustration and and I/O subsystem that is easily diagnosed using standard tools and expertise.