more about osysmond.bin

We have some questions on this guess:
1.What kind of operation osysmond.bin will do when a new disk device is scaned by os?

Currently osysmond detects disks only when it starts. If osysmond is running and a new disk is added to system, Osymond will not detect it right away. It will detect it only when it restarts;

What do you exactly mean by a new disk? If you are referring to hot plugging a new OS disk, then currently it won’t be detected by osysmond unless and until the process/stack is restarted. If by a new disk, you mean adding a new asm disk on top of existing os disks then it should ideally get marked as an ASM disk.

– osysmond collects the list of disks during its startup and creates a static list. This list do not change dynamically.
So when a new disk is scanned by O/S as of now that may not be detected by osysmond.bin. There is an enhancement request filed for detecting new disks added dynamically at run time.

2.Which disks osysmond.bin will read/write on during crfmond_refresh, disk matching asm_diskstring? or all disks which lsdev can found?

crfmond_refresh runs every 1 hour and checks for configuration change. For example if a normal disk(which was detected by osysmond at start) has been added to ASM disk
group in last hour, osymond will tag with “ASM” type.

Currently the disks are marked based on what kfod API returns(it uses disk string internally) using stat64() function. sysmond as such doesn’t read/write from/to any OS disk. The ASM disk marking mechanism is changing in 12.1 and in the new mechanism it doesn’t make a call to stat64() during the marking process.

– it will only read specific disks Voting, ASM, OCR etc. For getting this list osysmond internally calls APIs from those layers CSS/ASM/OCR etc.

3.Why osysmond.bin need to tag voting/ocr disks when gathering performance data?

This is done for customer to see disk configuration on their system in a glance. Oclumon tool display disk type along with various other metrics(like I/O, queue length etc).

sysmond tags the OS disks as voting/ocr/asm etc only once in every hour. This data is used for diagnostics and by upstream tools for detecting problems in the system.

– it will only read specific disks Voting, ASM, OCR etc. For getting this list osysmond internally calls APIs from those layers CSS/ASM/OCR etc.

4.What’s the meanings of get ID failed, is this a common info in all 11g RAC deployment? if not , how to fixed it?

For tagging purpose osysmond internally maintains unique ID for each disk. We need to look a bit more to figure out why it is failing.

The disk tagging mechanism is changing in 12.1 and this issue should be resolved there. But this message as such should be benign. What is the exact problem that you guys see? As i mentioned earlier osysmond doesn’t try to read/write the disks. It tags the disks by making a stat64() call to find the device id of the disk to be tagged and this happens once in every hour. Is it the stat64() call which is taking long and locking the disk. Do you have the output of strace etc to confirm the same?

– This means osysmond is not able to find device Id for certain disks for tagging ASM/VOTING etc disks. This is known issue and there are bugs filed for it.
We are working on it.






Leave a Reply

Your email address will not be published. Required fields are marked *