- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: ASM devices files constant access
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-13-2011 01:27 AM
тАО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.
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
Solved! Go to Solution.
- Tags:
- ASM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-13-2011 04:09 AM
тАО04-13-2011 04:09 AM
Solution>> 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-13-2011 04:30 AM
тАО04-13-2011 04:30 AM
Re: ASM devices files constant access
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-13-2011 06:06 AM
тАО04-13-2011 06:06 AM
Re: ASM devices files constant access
device %busy avque r+w/s blks/s avwait avserv
disk1 2.39 4.81 5 288 19.40 10.85
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-13-2011 07:45 AM
тАО04-13-2011 07:45 AM
Re: ASM devices files constant access
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-13-2011 11:17 AM
тАО04-13-2011 11:17 AM
Re: ASM devices files constant access
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-09-2011 09:27 AM
тАО05-09-2011 09:27 AM
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.