views:

3555

answers:

7

Is there a tool that will run a command-line and report how much RAM was used total?

I'm imagining something analogous to /usr/bin/time

+4  A: 

Well, if you really want to show the memory peak and some more in-depth statistics i recommend using a profiler such as valgrind. A nice valgrind front-end is alleyoop.

alexn
+3  A: 

You can use a tool like Valgrind to do this.

Dana the Sane
No, it doesn't. That's an example of how to report how much CPU time was used.
Jim Hunziker
+2  A: 

[Edit: well, this looked useful at first but always seems to return 0]

Looks like /usr/bin/time does give you that info, if you pass -v (this is on Ubuntu 8.10). See, e.g., Maximum resident set size below:

$ /usr/bin/time -v ls /
....
        Command being timed: "ls /"
        User time (seconds): 0.00
        System time (seconds): 0.01
        Percent of CPU this job got: 250%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 0
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 315
        Voluntary context switches: 2
        Involuntary context switches: 0
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0
Jacob Gabrielson
Probably it always returns 0 because ls isn't doing much. Try a more CPU intensive command.
Jon Ericson
I seem to always get zero, even for large commands.
jes5199
me too :( at least on the stack size, which I find strange, as I ran a recursive call for stack-overflow..
Liran Orevi
From the man page:Most information shown by time is derived from the wait3(2) system call. The numbers are only as good as those returned by wait3(2). On systems that do not have a wait3(2) call that returns status information, the times(2) system call is used instead. However, it provides much less information than wait3(2), so on those systems time reports the majority of the resources as zero.
lothar
A: 

/usr/bin/time maybe does what you want, actually. Something like.

 /usr/bin/time --format='(%Xtext+%Ddata %Mmax)'

See time(1) for details...

simon
I seem to always get zeros with this, even for large commands
jes5199
I get the same...
Liran Orevi
jes5199, Liran, looking at above comments it seems time(1) may be broken for memory reporting on some linuxes...
simon
A: 

Perhaps time(1) already does what you want. For instance:

$ /usr/bin/time -f "%P %M" command
43% 821248

But other profiling tools may give more accurate results depending on what you are looking for.

Jon Ericson
I seem to always get zeros with this, even for large commands
jes5199
I get variable results, like 400% 0, and 0% 0 on the same program.. maybe is should be run for larger periods of time to be exact?
Liran Orevi
I don't know what to suggest. The code above is exactly what I got running a latex command that happened to be in history. As I say, more accurate results can be obtained with other tools.
Jon Ericson
+3  A: 

If the process runs for at least a couple seconds, then you can use the following bash script, which will run the given command line then print to stderr the peak RSS (substitute for rss any other attribute you're interested in). It's somewhat lightweight, and it works for me with the ps included in Ubuntu 9.04 (which I can't say for time).

#!/usr/bin/env bash
"$@" & # Run the given command line in the background.
pid=$! peak=0
while true; do
  sleep 1
  sample="$(ps -o rss= $pid 2> /dev/null)" || break
  let peak='sample > peak ? sample : peak'
done
echo "Peak: $peak" 1>&2
Yang
+2  A: 

(This is an already answered, old question.. but just for the record :)

I was inspired by Yang's script, and came up with this small tool, named memusg. I simply increased the sampling rate to 0.1 to handle much short living processes. Instead of monitoring a single process, I made it measure rss sum of the process group. (Yeah, I write lots of separate programs that work together) It currently works on Mac OS X and Linux. The usage had to be similar to that of time:

memusg ls -alR / >/dev/null

It only shows the peak for the moment, but I'm interested in slight extensions for recording other (rough) statistics.

It's good to have such simple tool for just taking a look before we start any serious profiling.

netj