is it possible to determine how much network traffic is caused by aparticular process?

Hello:

I have multiple processes running on a single Linux 2.6.x based blade
server. I am able to determine the *total* amount of network traffic
in and out on an interface by a variety of means (including the
"sysstat" utilities http://pagesperso-orange.fr/sebastien.godard/ ),
but I can not find any means of determining per process network load.

Does anyone know if this is possible by any reasonable technique? The
"sysstat" author tells me that since the kernel does not expose any
per process network counters (via /proc system or otherwise) it is not
clear how one might do this.

How hard would it be to add the capability to expose per PID network
usage information?

G. Thaker

(E-Mail Removed) wrote:
> I have multiple processes running on a single Linux 2.6.x based
> blade server. I am able to determine the *total* amount of network
> traffic in and out on an interface by a variety of means (including
> the "sysstat" utilities
> http://pagesperso-orange.fr/sebastien.godard/ ), but I can not find
> any means of determining per process network load.

> Does anyone know if this is possible by any reasonable technique?
> The "sysstat" author tells me that since the kernel does not expose
> any per process network counters (via /proc system or otherwise) it
> is not clear how one might do this.

Not only does it not expose any, I'm not at all certain it even keeps
any. At least when I was researching if I could get netperf to report
per-connection TCP stats, what was documented as being in the TCP_INFO
getsockopt() wasn't much at all, and there isn't a corresponding
UDP_INFO I've no idea about the existence of SCTP_INFO or
DCCP_INFO.

> How hard would it be to add the capability to expose per PID network
> usage information?

Just how "realtime" does this need to be? And how many "extra" CPU
cycles do you have to toss at the task? In theory, one could build-up
a table of four-tuple to PID via lsof-like stuff and then use libpcap
to "sniff" all the traffic being sent on an interface and match the
two. I suspect it would consume a fair number of cycles. You could
get both packet and byte counts that way. You would have to decide if
pure "protocol overhead" packets for a given four-tuple (eg standalone
TCP ACKs) should be counted against the process(es) associated with
the tuple.

There may be another way via system call auditing - perhaps something
that selinux can do, but I've no idea there - I am always disabling
selinux when I install for netperf You would look at the system
calls sending data on "network" sockets and use that for your sums.
You would only really get byte counts that way - any attempt at packet
counts from the system call level would be a wild guess. You wouldn't
have to decide about pure protocol overhead packets since you would
never see them.

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...