baweaver / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

File descriptor usage statistics #284

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Proposal

psutil is missing a function that displays full FD usage for a process. The 
combination of get_open_files() and get_connections() doesn't list all FDs as 
psutil skips unknown types and stdin/out/err. The total amount of FDs is a very 
useful information as the amount is usually small (1024-4096) on most platforms.

On what platforms would this be available?

All

Proposed API

process.get_fd_usage() -> fdinfo(count=int, softlimit=int, hardlimit=int)

Are there existent implementations we can use as an example?

In Linux, the implementation is pretty straight forward. count = 
len(os.listdir("/proc/PID/fd"), the hard and softlimit can be acquired with 
prlimit() or from "/proc/PID/limits".

Original issue reported on code.google.com by tiran79 on 15 Jun 2012 at 11:44

GoogleCodeExporter commented 8 years ago
I like the idea. prlimit() is Linux only though, and I don't like returning a 
tuple which makes sense on 1 platform out of 4. We can probably add a 
get_num_fds() method returning an int (POSIX only as on Windows we already have 
get_num_handles which is similar).

Original comment by g.rodola on 17 Jun 2012 at 9:44

GoogleCodeExporter commented 8 years ago
Implemented in r1349, r1350, r1351.

Original comment by g.rodola on 18 Jun 2012 at 12:48

GoogleCodeExporter commented 8 years ago
0.5.0 is finally out. Closing out as fixed.

Original comment by g.rodola on 27 Jun 2012 at 6:54

GoogleCodeExporter commented 8 years ago
Thanks! Your implementation is more than sufficient for my needs. The idea with 
hard and soft limit was more like gimmick. I just need the information for the 
current Linux process so I can use the resource module.

Original comment by tiran79 on 27 Jun 2012 at 9:47

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Updated csets after the SVN -> Mercurial migration:
r1349 == revision ???

Original comment by g.rodola on 2 Mar 2013 at 12:09