From: wmealing <wmealing@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: wmealing@redhat.com
Subject: Counting currently open file descriptors per process.
Date: Wed, 11 Jun 2014 14:32:58 +1000 [thread overview]
Message-ID: <1402461178.24669.40.camel@localhost> (raw)
Gday,
I'm seeking some guidance on how to best (or if) to implement a feature.
Please CC me on any reply, I am not subscribed to this list.
The feature is, "an application would like to know how many files another
process has open".
>From user space, the cheapest way would be to use the call
syscall(SYS_getdents ...) in the proc/pid/fd directory.
Alternatively from kernel space one could achieve a similar behavior by
iterating through the tasks fdtable, as i have attempted to here:
https://gist.github.com/wmealing/c0836bc6a38f8f90aa0d
Colleagues of mine have pointed out that this may have performance
impacts for tools that frequently parse /proc/pid/status.
I have compiled a kernel with the above patch and here are the performance stats.
System settings
# sysctl -w fs.file-max=5000000
fs.file-max = 5000000
Increase this sessions limits.
# ulimit -n 1000000
test.py had 500002 files open each time.
Here are some of the performance benchmarks on an idle
system:
# time cat /proc/`pidof python test.py`/status |grep FD
FDSize: 524288
FDCount: 500002
real 0m0.008s
user 0m0.002s
sys 0m0.004s
# time ./test-getdents /proc/`pidof python test.py`/fd &> /dev/null
real 0m0.631s
user 0m0.001s
sys 0m0.485s
or this time with readdir(3)
# time ./test-opendir /proc/`pidof python test.py`/fd &> /dev/null
real 0m0.129s
user 0m0.001s
sys 0m0.007s
(which oddly seems faster?)
My benchmark values above are not meant for micro-benchmarking
but rather as a scale to know how far behind the code is.
Is the current method of getting a live fd count acceptable, if
not how should it be done ?
Thanks for your time.
Wade Mealing.
[1] https://github.com/wmealing/live-fd-count/
git repo with code used in the above.
reply other threads:[~2014-06-11 4:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1402461178.24669.40.camel@localhost \
--to=wmealing@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wmealing@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.