If you have an AR System environment which consists of more than one server, it is important to monitor the system resources. An incident can happen at any time. AR Server or some other process may crash if physical server is out of resources. If you do not have enough input to investigate the root-cause, then you would wait till the same error occurs again. For this reason, it is worth to build any kind monitoring which is checking and logging the memory or resources for you. I am using a very simple shell script to check memory:
date >> /opt/remedy/node/ars5/db/check_memory.log
echo "______________________PRSTAT______________________________" >> /opt/remedy/node/ars5/db/check_memory.log
prstat -c 1 1 >> /opt/remedy/node/ars5/db/check_memory.log
echo "________________________TOP_______________________________" >> /opt/remedy/node/ars5/db/check_memory.log
top >> /opt/remedy/node/ars5/db/check_memory.log
echo "__________________________________________________________" >> /opt/remedy/node/ars5/db/check_memory.log
echo "__________________________________________________________" >> /opt/remedy/node/ars5/db/check_memory.log
For 32 bit AR Server processes, there is a limit of 4 GB of memory. It means it can grow to 4 GB memory. What I experienced is it tries to live with this 4 GB however if you force it or put more load on the server, then it would give a Segmentation Fault with Signal 11. For 64 bit AR Server process, BMC states that there is no memory limit for the process but my observation is that AR Server can not work efficiently if memory usage of 10 GB is exceeded. In the following articles, I will try to give you more hints regarding monitoring.
No comments:
Post a Comment