Per process memory accounting is tricky for a number of reasons I'll get into in a minute. For simple monitoring, gkrellmd, or nagios scripts is probably enough. If you want greater accuracy, you'll need to look harder.
smem introduces the concept of Proportional Set Size:
Because large portions of physical memory are typically shared among multiple applications, the standard measure of memory usage known as resident set size (RSS) will significantly overestimate memory usage. PSS instead measures each application's "fair share" of each shared area to give a realistic measure.
Example: You start up GNOME, causing a number of processes to start, one for each applet and program. They all link to libglib. Linux loads libglib into one block of memory and maps it into every process that wants libglib. Naive memory accounting counts the full libglib size against every process linking to it.
smem divides up the cost of libglib among the processes using it, to give a closer picture of reality. It also has a number of options to display memory usage (from website):
- Show basic process information smem
- Show system view smem -R 4G -K /path/to/vmlinux -w
- Show totals and percentages smem -t -p
- Show different columns smem -c "name user pss"
- Show processes filtered by mapping smem -M libxml
- Show mappings filtered by process smem -m -P [e]volution
- Read data from capture tarball smem --source capture.tar.gz
- Show a bar chart labeled by pid smem --bar pid -c "pss uss"
- Show a pie chart of RSS labeled by name smem --pie name -s rss
You will, however, need a very recent kernel (> 2.6.27).