npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

roar-pidusage

v1.1.7

Published

Cross-platform process cpu % and memory usage of a PID — Edit

Downloads

7

Readme

pidusage

Build Status Build status

Cross-platform process cpu % and memory usage of a PID

Ideas from https://github.com/arunoda/node-usage/ but with no C-bindings

Please note that if you need to check a nodejs script process cpu usage, you can use process.cpuUsage since node v6.1.0. This script remain useful when you have no control over the remote script, or if the process is not a nodejs process.

API

var pusage = require('pidusage')

pusage.stat(process.pid, function(err, stat) {

	expect(err).to.be.null
	expect(stat).to.be.an('object')
	expect(stat).to.have.property('cpu')
	expect(stat).to.have.property('memory')

	console.log('Pcpu: %s', stat.cpu)
	console.log('Mem: %s', stat.memory) //those are bytes

})

// Unmonitor process
pusage.unmonitor(process.pid);

How it works

A check on the os.platform is done to determine the method to use.

Linux

We use /proc/{pid}/stat in addition to the the PAGE_SIZE and the CLK_TCK direclty from getconf() command. Uptime comes from proc/uptime file because it's more accurate than the nodejs os.uptime().

/!\ As stated in #17, memory will increase when using pidusage.stat in an interval because of readFile. Use --expose-gc and release the garbage collector to avoid such leaking.

Cpu usage is computed by following those instructions. It keeps an history of the current processor time for the given pid so that the computed value gets more and more accurate. Don't forget to do unmonitor(pid) so that history gets cleared. Cpu usage does not check the child process tree!

Memory result is representing the RSS (resident set size) only by doing rss*pagesize, where pagesize is the result of getconf PAGE_SIZE.

On darwin, freebsd, solaris (tested on 10/11)

We use a fallback with the ps -o pcpu,rss -p PID command to get the same informations.

Memory usage will also display the RSS only, process cpu usage might differ from a distribution to another. Please check the correspoding man ps for more insights on the subject.

On AIX

AIX is tricky because I have no AIX test environement, at the moment we use: ps -o pcpu,rssize -p PID but /proc results should be more accurate! If you're familiar with the AIX environment and know how to get the same results as we've got with Linux systems, please help. #4

Windows

Windows is really tricky, atm it uses the wmic.exe: wmic PROCESS {PID} get workingsetsize,usermodetime,kernelmodetime.

The memory usage here is what windows calls the "Working Set":

Maximum number of bytes in the working set of this process at any point in time. The working set is the set of memory pages touched recently by the threads in the process. If free memory in the computer is above a threshold, pages are left in the working set of a process even if they are not in use. When free memory falls below a threshold, pages are trimmed from working sets. If they are needed, they are then soft-faulted back into the working set before they leave main memory.

The CPU usage is computed the same as it is on linux systems. We have the kernelmodetime and the usermodetime processor use. Every time pidusage.stat is called, we can calculate the processor usage according to the time spent between calls (uses os.uptime() internally).

Note that before we used wmic path Win32_PerfFormattedData_PerfProc_Process WHERE IDProcess= (which is slow as hell) and Win32_PerfRawData_PerfProc_Process (which api breaks on Windows 10 and Windows server 2012). Not every Windows bugged but just some of those. However, the wmic PROCESS call is faster, and safer as it must be used by internal programs since windows XP (this is clearly an assumption).

Why wmic?

This is the safest implementation I've found that works on most Windows version (>= XP). I've tried many other implementations but there was always some failing test case. For example, powershell would be faster but powershell needs to be attached to a console (see this comment). This means it'd have to popup a new cmd.exe every time we execute pidusage. If you know a way that doesn't imply the use of wmic, please open an issue so that I can try it!

pidusage-tree

If you want to compute a pidusage tree take a look at pidusage-tree.

Licence

MIT