This post was originally published on my blog, find original post here.
I have been executing a lot of bash scripts and one-off processes on the linux command line recently, and was curious about how to monitor the CPU and memory usage of these processes as quickly as possible. Some of these processes seemed to bring my linux box to a screeching halt, and without instant resource monitoring I couldn't tell whether such a process was eating excessive RAM or CPU (or both?!)
What people usually do
Conventionally, suggestions about process monitoring involve the following:
Run your command line process.
Get the PID of the process with
ps auxcommand which is generally available for both Linux and Mac.-
Run the utility
topwithtop -p <pid>on Linux or
top -pid <pid>on Mac OS.
However, I wanted to run commands which would exit within a few seconds, before I could run top to start monitoring them. How could I start monitoring these commands as soon as they were invoked?
What can we do better
As always, Unix has an answer:
-
Run your command in the background and pipe the output to
/dev/nullso that it doesn't get printed on the command line while you are monitoring the CPU/memory usage, e.g.unzip ~/Downloads/sample.zip > /dev/null & -
Echo the PID of this background process with
echo $! -
Combine the two, and pass the pid of the process to
topwithtop -p `{ unzip ~/Downloads/sample.zip > /dev/null & } && echo $!`on linux or
top -pid `{ unzip ~/Downloads/sample.zip > /dev/null & } && echo $!`on Mac OS.
BOOM, you just started monitoring your process immediately with a single command. Now isn't that peachy!
Bonus: Use htop instead of top
I ❤️ htop which is a process monitoring utility available for both linux and Mac OS. Come on, you've got colours! Let's use this instead of top for better insight into the CPU/memory performance of our processes.
-
Install
htopwithsudo apt-get install htopon Ubuntu or
brew install htopon Mac OS with Homebrew
-
Run our previous monitoring command using
htopinstead oftopfor monitoring withhtop -p `{ unzip ~/Downloads/sample.zip > /dev/null & } && echo $!`
See the single command in action below!
Double Bonus: Style your editor for a more beautiful htop
Saw some chatter on Twitter about this post which mentioned that I should have added information about the terminal theme I'm using here, since htop gets styled by the terminal and theme in use. I totally agree, so here's my setup:
- Terminal emulator: iTerm2 Awesome Mac OS Terminal replacement with cool features such as grid tabs and more.
- Unix shell + theming framework:
zsh+ oh-my-zsh Check out this awesome post about how to install these (similar steps on Ubuntu or Mac OS) -
oh-my-zshtheme: Default themerobbyrussell. After setting upoh-my-zsh, you can specify the desired theme in the~/.zshrcfile, e.g.ZSH_THEME="robbyrussell"
Top comments (5)
Current style recommendations for shell scripts discourages the use of back-ticks. One would more typically do something like:
Using the
$()method allows for nesting of commands without jumping through hoops to escape one command-execution nested within another)Thanks for the tip Thomas. I usually do use
$()but didn't know that you don't need to escape nested command execution with it. Initially I used$()along with{}and it lead to errors on Mac (but not on Linux), so I switched to back-ticks which worked on both.I'll update the article once I get near my computer and can test this out on both Mac and Linux, thanks again.
Yeah... Being a long-time abuser of nested subshells, used to frustrate the hell out of me once I had to go more than about two subshells deep ...Sooner if one or more of those subshells required single- and/or double-quotes for some of their functionality.
Wasn't really until I started adding shellcheck to my TravisCi recipes that I habituated to the
$()method. That tool also caused me to start moving off a few other habitual things that had been placed on the deprecation (but had worked for decades so were just "finger memory").I'd definitely suggest checking out glances: It's an alternative to
top/htopentirely written in Python, and it's a lot easier on the eyes/to parse IMO.Nice tip