How to monitor memory usage of "Memory-based Snapshot" executable (MRCNSP) in Linux?

Question

We have noticed in the past that MRCNSP/Memory-based Snapshot program executable consumes around 3.8 GB of memory on the linux VM. I understand that value change planning  is 32 bit executable so 4 GB is the limit. I want to monitor the memory usage of the executable when the program runs. The program usually runs overnight. I wanted to check with you experts if you have any MRP executable memory usage monitoring script that I could use.
I found the metalink note OS Environment and Compile Settings for Value Chain and MRP/Supply Chain Planning Applications (Doc ID 1085614.1) which talks about "top -d60 >>$HOME/top.txt". Please share your ideas for monitoring this process.
We do not use Demand Planning or Demanta or Advanced Supply Chain Planning which are 64 bit application. That is our future direction.
Environment:
EBS : R12.1.2 on Linux. The concurrent manager is on 64 bit linux VM, web services on 32 bit VMs.
DB: Oracle DB 11.2.0.3 on HP UX Itanium 11.31. Single database instance.
Thanks
Cherrish Vaidiyan

Answer 1

RAM on the controller is not the same as the C: drive. With respect to the controller, you can think of it in the same terms as your computer. RAM is volatile memory and your C: drive is non volatile flash memory.
Depending on the frequency of the temperature excursions above and below your 70C threshold, the service life of the controller and the method you used to append to the file, there could be a number of issues that may creep up over time.
The first, and the one you brought up is the size of the file over time. Left unchecked this file could grow continuously until the system literally runs out of flash memory space and chokes. Depending on how your are appending data to this file, you could also use more than a trivial slice of processor time to read and write this big file on disk. While I have not personally ever run one of the RT controllers out of "disk space", I can't imagine that any good could come of that.
One thought is to keep a rolling history of say the last 3 months. Each month, start a new file and append your data to it during the course of the month. Each time a new file is created, delete the data file from something like 3 months ago. This will ensure that you will always have the last 3 months of history on the system, however the monthly deletion of the oldest data file will limit you to say 3 files at whatever size they happen to be. Unless there are hundreds of thousands of transitions above and below your threshold this should keep you in good shape.
I also eluded to the method you use to write to this file. I would ensure that you are appending data using the actual file functions and not first reading in the file, appending your data as a string then writing the entire file contents back to disk. In addition to causing the highest load on the file system this method also has the largest system RAM requirements.