使用 Proc 文件系统计算进程的内存

发布于 2024-12-18 02:58:10 字数 275 浏览 0 评论 0原文

我正在 Perl 中通过读取 Proc 文件系统中的值来编写小型进程监视器脚本。现在我可以使用 /proc/[pid]/status/proc/[pid]/io 文件。现在我想计算一个进程的内存使用情况。经过搜索,我发现内存使用情况会出现在 /proc/[pid]/statm 中。但我仍然无法弄清楚该文件需要哪些必要字段来计算内存使用情况。有人能帮我解决这个问题吗?提前致谢。

I am writing small process monitor script in Perl by reading values from Proc file system. Right now I am able to fetch number of threads, process state, number of bytes read and write using /proc/[pid]/status and /proc/[pid]/io files. Now I want to calculate the memory usage of a process. After searching, I came to know memory usage will be present /proc/[pid]/statm. But I still can't figure out what are necessary fields needed from that file to calculate the memory usage. Can anyone help me on this? Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

我乃一代侩神 2024-12-25 02:58:10

您可能需要residentsize。来自 kernel.org

  • 大小 程序总大小
    • 这是整个程序,包括从未交换过的内容
  • 常驻驻留集大小 中从未交换的内容
    • 当前 RAM 中的内容(不包括换出的页面)

You likely want resident or size. From kernel.org.

  • size total program size
    • This is the whole program, including stuff never swapped in
  • resident resident set size
    • Stuff in RAM at the current moment (this does not include pages swapped out)
辞旧 2024-12-25 02:58:10

了解进程的“内存使用情况”是极其困难的。 VM 大小和 RSS 是已知的、可测量的值。

但你可能想要的是别的东西。在实践中,“VM 大小”似乎太高,而 RSS 通常看起来太低。

主要问题是:

  • 多个进程可以共享相同的页面。您可以将所有正在运行的进程的 RSS 相加,最终得到的值远远超过机器的物理内存(这是在计算内核数据结构之前),
  • 属于该进程的私有页面可以被换出。或者它们可能尚未初始化。他们算数吗?
  • 到底如何计算内存映射文件页数?脏的?干净的? MAP_SHARED 还是 MAP_PRIVATE?

因此,您确实需要考虑什么才算是“内存使用量”。

在我看来,从逻辑上讲:

  • 不与任何其他进程共享的私有页面(注意:私有页面仍然可以是写时复制!)必须计数,即使换出的
  • 共享页面应该计数除以它们的进程数由例如两个进程共享的页面重新共享计数为一半
  • 驻留的文件支持的页面可以以相同的方式计数
  • 文件支持的非驻留页面可以被忽略
  • 如果同一页面多次映射到以下地址空间同样的过程,可以忽略第二次及以后。这意味着,如果 proc 1 的页面 X 映射了两次,而 proc 2 的页面 X 映射了一次,那么它们都被“充电”了半页。

我不知道有任何实用程序可以做到这一点。不过,这看起来并不简单,并且涉及(至少)读取 /proc/pid/pagemap 以及可能的其他一些 /proc 接口,其中一些是仅限 root 的。

It is extremely difficult to know what the "memory usage" of a process is. VM size and RSS are known, measurable values.

But what you probably want is something else. In practice, "VM size" seems too high and RSS often seems too low.

The main problems are:

  • Multiple processes can share the same pages. You can add up the RSS of all running processes, and end up with much more than the physical memory of your machine (this is before kernel data structures are counted)
  • Private pages belonging to the process can be swapped out. Or they might not be initialised yet. Do they count?
  • How exactly do you count memory-mapped file pages? Dirty ones? Clean ones? MAP_SHARED or MAP_PRIVATE ones?

So you really need to think about what counts as "memory usage".

It seems to me that logically:

  • Private pages which are not shared with any other processes (NB: private pages can STILL be copy-on-write!) must count even if swapped out
  • Shared pages should count divided by the number of processes they're shared by e.g. a page shared by two processes counts half
  • File-backed pages which are resident can count in the same way
  • File-backed non-resident pages can be ignored
  • If the same page is mapped more than once into the address-space of the same process, it can be ignored the 2nd and subsequent time. This means that if proc 1 has page X mapped twice, and proc 2 has page X mapped once, they are both "charged" half a page.

I don't know of any utility which does this. It seems nontrivial though, and involves (at least) reading /proc/pid/pagemap and possibly some other /proc interfaces, some of which are root-only.

Hello爱情风 2024-12-25 02:58:10

另一种(不太简单,但更精确)的可能性是解析 /proc/123/maps 文件,也许可以使用 pmap 实用程序。它为您提供有关“虚拟内存”(即进程的地址空间)的信息。

Another (less simple, but more precise) possibility would be to parse the /proc/123/maps file, perhaps by using the pmap utility. It gives you information about the "virtual memory" (i.e. the address space of the process).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文