04-13-2011 01:27 AM
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.
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
Solved! Go to Solution.
04-13-2011 04:09 AM
>> 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 ?
04-13-2011 04:30 AM
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
04-13-2011 07:45 AM
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 /
04-13-2011 11:17 AM
05-09-2011 09:27 AM
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.