jared, processing RSS is a wrong way of calculating memory usage. It's alrights for private memory/PGA, but oracle uses shared memory, in which the SGA resides. That memory is not bound to a specific process, rather a linux/unix system keeps track of the processes which access them, so current PID and creater pid are kept. the RSS is calculated of private memory + touched shared memory pages this means accumulating all RSS amount for all database processes, the chance you calculate memory twice is fairly big, and gets higher once the instance is longer alive (the background processes are able to touch more shared memory)
this means it's impossible to calculate database memory usage in a simple way by examining the processes at OS level.
it's also worth to note that shared memory usage display is turned off by default in linux (at least in the recent 2.4 kernels and the RHEL3 and 4 2.6kernels) in /proc/meminfo. A way to get linux display shared memory pages is (of course) ipcs -ma, and also with (as root): echo m > /proc/sysrq-trigger ; dmesg | grep shared
so I'd go with kevin's recommandation to use some tool to look at global OS level to see memory usage. besides the omitted shared memory, it's accurate.
Does anyone have a fairly accurate method for determining how much memory is actually being used on a Linux box?
The linux in question is RedHat Enterprise Server 4.
Before dashing off a reply to use 'ps -F' to get the RSS column, or using pmap -qx to get the various memory segment sizes, or using /proc/PID/stats|statsm|status|, please consider that these methods do not work, as Linux does not always correctly report the memory in use.
Is there any other method that you have found to work correctly? I will define 'correctly' here as within 10% of what the actual memory use is.
-- Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist