>> Start with a clean initialization of the Linux guest to reset your memory >> footprint. >> In additional to Rob's Tools use SAR -r to illustrate the storage growth >> over time. >> Execute a ps aux to profile each process and find which ORCL process (or >> other ) is creeping.
When you run ESALPS there is no additional value in using "sar" that way. The ESALPS performance database already has the per-minute memory usage. There is imho little value in having sar also sample the same metrics with a 10-min granularity (which takes additional resources for the starting the cron task, keeping the archive on Linux, etc). The same goes for the per-process vmsize and resident memory if you want to see process memory leakage. ESALPS retains the data only for the active process, but the good thing is that a process does not leak much when fully idle... We condense the 1-minute data (by default) to 15 min granularity after a day, etc. This is probably more useful (and cheaper) for spotting trends than having each Linux zip the files after a day or discard them after a month. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/ ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
