Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there a way to collect the real-time network speed of each process and the total traffic of each process? #2131

Closed
LRF520 opened this issue Aug 15, 2022 · 4 comments

Comments

@LRF520
Copy link

LRF520 commented Aug 15, 2022

Hello, I've tried for a long time but haven't solved it. I want to ask two questions:

(1)Is there a way to collect the real-time network speed of each process and the total traffic of each process?

(2)Is there a plan for GPU monitoring?

@dbwiddis
Copy link
Contributor

(1)Is there a way to collect the real-time network speed of each process and the total traffic of each process?

Can you define "real-time network speed"? To avoid an XY problem, what is the actual goal of obtaining this data?

(2)Is there a plan for GPU monitoring?

What exactly do you want to monitor? And why? There are at least 3 major GPU manufacturers and each of them has their own highly specialized software providing a lot more information than a cross-platform program trying to generalize statistics across multiple hardware vendors could even hope to achieve.

@LRF520
Copy link
Author

LRF520 commented Aug 18, 2022

(1)Is there a way to collect the real-time network speed of each process and the total traffic of each process?

Can you define "real-time network speed"? To avoid an XY problem, what is the actual goal of obtaining this data?

(2)Is there a plan for GPU monitoring?

What exactly do you want to monitor? And why? There are at least 3 major GPU manufacturers and each of them has their own highly specialized software providing a lot more information than a cross-platform program trying to generalize statistics across multiple hardware vendors could even hope to achieve.

Thank you very much for your reply. I actually want to express the following two meanings:

  1. Now psutil can monitor the CPU and memory utilization of a specific process, but psutil can only monitor the network speed of the entire computer, and cannot monitor the network speed of a specific process. However, in many cases, the network speed of the whole computer is much higher than that of a single process, so it is impossible to explain the problem in combination with the CPU and memory utilization of a specific process. So I think if psutil can add the function of monitoring the network speed of a specific process, I can collect some historical data to make a complete statistical chart, which can include the CPU, memory utilization and network speed of a specific process. These three indicators can explain some important issues at the same time.

  2. The rendering function of GPU is becoming more and more important. I just want to see the GPU utilization rate of the whole computer, or the GPU utilization rate of a specific process.

20220818_110732

20220818_104127

@dbwiddis
Copy link
Contributor

dbwiddis commented Aug 18, 2022

Hey @LRF520, before I provide some more commentary, I first want to point out that I am not a maintainer at this project and have limited python and C skills. I maintain a Java-based project similar to this one so there is a very large overlap in how both projects fetch native information, so this answer is more from the perspective of "what is available from the OS" than any intention to add information here.

The general answer to both questions is "it can be done but it is very hard to do and there already exist better tools to do this than anything we could cobble together."

Network Statistics

Based on your screen capture I'm assuming you mean bandwidth/usage, rather than speed. The problem we have is that to have that generally available we have to actively monitor every connection on the system.

  • On Windows, GetExtendedTcpTable tells you which processes are connected to which interfaces. Using these connections:
    • SetPerTcpConnectionEStats starts collecting statistics
    • GetPerTcpConnectionEStats retrieves the statistics
  • On Linux and other *nix, lsof tells you which processes are connected to which interfaces, but it's insanely slow (try it!). The same information is available in the proc filesytem using /proc/pid/fd but isn't much faster if you are iterating over every file descriptor for every process (what lsof is doing anyway). And then you'd have to use netstat to try to correlate with the bandwidth. (Compare to iftop that gives you the worst offenders quickly.)

I could go on, but at this point hopefully you see that monitoring every process and every network connection is an incredibly wasteful use of CPU compared to waiting until you actually have a network issue and then troubleshooting using a utility program already built in to these OS's.

Thus my original question about XY problem. Do you really want to monitor every process and every network connection on the system? Or do you just want to identify problems when they occur? The answers are going to be different.

GPU usage

While most OS's provide at least some kernel-level support for network ports, the same can not be said for GPU. There is no standard API by which this information is available, primarily because there are multiple GPU vendors (NVidia, AMD, ASUS, Intel, etc.). They each have different software using highly specialized drivers associated with their proprietary cards. The best a cross-platform program like psutil can do is try to parse the command-line output of these cards' own command-line software. See for example the gpustat project in python. That's a whole lot of code for only a portion of GPU in one operating system. Windows 10+ has a performance counter that you can get GPU "ticks" similar to CPU usage but you'd need to run a daemon to collect these over time to calculate percentages. macOS has the best support here, actually giving a percentage number in the IO Registry (it helps to control your own hardware!) but the names have changed across macOS versions so trying to implement that here would mean trial and error across a range of different registry keys until one worked.

Summary

It's hard to do both of these things and there are ample specialized tools out there that give far better, more detailed, and useful information than psutil could ever hope to provide.

In the case of bandwidth, often we don't care unless there's a problem and then you can troubleshoot the problem.

In the case of GPU, different vendors and specialized drivers for their hardware make it impractical to try to cover every possibility on every operating system.

@LRF520
Copy link
Author

LRF520 commented Aug 18, 2022

@LRF520,在我提供更多评论之前,我首先想指出我不是这个项目的维护者,并且对 python 和 C 技能的了解有限。我维护了一个与此类似的基于 Java 的项目,因此两个项目如何获取本机信息有很大的重叠,所以这个答案更多是从“操作系统可用的内容”的角度来看,而不是任何在此处添加信息的意图.

这两个问题的一般答案是“可以做到,但很难做到,而且已经存在比我们可以拼凑的任何东西更好的工具来做到这一点。”

网络统计

根据您的屏幕截图,我假设您的意思是带宽/使用率,而不是速度。我们遇到的问题是,要使该功能普遍可用,我们必须主动监视系统上的每个连接。

  • 在 Windows 上,GetExtendedTcpTable告诉您哪些进程连接到哪些接口。使用这些连接:

    • SetPerTcpConnectionEStats开始收集统计数据
    • GetPerTcpConnectionEStats检索统计信息
  • 在 Linux 和其他 *nix 上,lsof告诉您哪些进程连接到哪些接口,但速度非常慢(试试看!)。proc 文件系统 using 中提供了相同的信息,/proc/pid/fd但如果您迭代每个进程的每个文件描述符(lsof无论如何都在做),则速度不会快得多。然后你必须使用 netstat 来尝试与带宽相关联。(相比之下iftop,你很快就会遇到最严重的违规者。)

我可以继续,但在这一点上,希望你看到监控每个进程和每个网络连接与等到你真正遇到网络问题然后使用这些操作系统中已经内置的实用程序进行故障排除相比,对 CPU 的使用是非常浪费的.

因此,我最初关于 XY 问题的问题。您真的要监视系统上的每个进程和每个网络连接吗?或者您只是想在问题发生时找出问题?答案会有所不同。

GPU 使用率

虽然大多数操作系统至少为网络端口提供了一些内核级别的支持,但 GPU 却不能这样说。没有提供此信息的标准 API,主要是因为有多个 GPU 供应商(NVidia、AMD、ASUS、Intel 等)。他们每个人都有不同的软件,使用与其专有卡相关的高度专业化的驱动程序。像 psutil 这样的跨平台程序可以做的最好的事情是尝试解析这些卡自己的命令行软件的命令行输出。参见例如gpustatpython中的项目。对于一个操作系统中的一部分 GPU,这是一大堆代码。Windows 10+ 有一个性能计数器,您可以获得类似于 CPU 使用率的 GPU“滴答”,但您需要运行一个守护程序来收集这些随着时间的推移来计算百分比。macOS 在这里有最好的支持,实际上在 IO 注册表中给出了一个百分比数字(它有助于控制您自己的硬件!)但是名称在 macOS 版本之间发生了变化,所以在这里尝试实现这意味着在一系列不同的试验和错误中注册表项,直到一个工作。

概括

这两件事都很难做到,而且有大量的专业工具可以提供比 psutil 所能提供的更好、更详细和更有用的信息。

在带宽的情况下,我们通常不在乎,除非出现问题,然后您可以解决问题。

就 GPU 而言,不同的供应商及其硬件的专用驱动程序使得试图涵盖每个操作系统上的所有可能性变得不切实际。

Thank you very much for sharing your experience. I believe this set of tools will become better and better.

@LRF520 LRF520 closed this as completed Aug 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants