为什么我的c程序突然使用了30g虚拟内存?

发布于 2024-11-16 14:34:08 字数 959 浏览 2 评论 0原文

在顶部,我注意到我的 c 程序(使用 CUDA 3.2)从一开始的每次运行都有 28g 或更多的虚拟大小(查看 VIRT)。这对我来说没有任何意义。驻留内存是有意义的,在我最大的数据集上只有 2g 左右。我知道过去某个时候虚拟大小没有那么大,但我不确定更改何时发生。

为什么我的进程会使用 28g 虚拟内存(或者为什么 top 的 VIRT 如此大)?据我了解,VIRT 包括可执行二进制文件(仅 437K)、共享库和“数据区域”。什么是“数据区”?如何找出共享库需要多少内存?我的进程总内存的其他元素怎么样?

/proc/<的内容pid >/smaps (1022 行):http://pastebin.com/fTJJneXr

来自的条目之一smaps 显示其中一个占了大部分,但没有标签...我怎样才能找出这个有 28gb 的“空白”条目是什么?

200000000-900000000 ---p 00000000 00:00 0 
Size:           29360128 kB
Rss:                   0 kB
Pss:                   0 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            0 kB
Anonymous:             0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB

--

ubuntu 11.04 64 位
16 GB 内存

In top, I noticed that my c program (using CUDA 3.2) has a virtual size of 28g or more (looking at VIRT), on every run right from the beginning. This doesn't make ANY sense to me. The resident memory makes sense and is only around 2g on my largest data set. I know at some point in the past the virtual size was not so large, but I'm not sure when the change occurred.

Why would my process use 28g of virtual memory (or why would top's VIRT be so large)? I understand that VIRT includes the executable binary (only 437K), shared libraries, and "data area". What is the "data area"? How can I find out how much memory the shared libraries require? What about other elements of my process's total memory?

contents of /proc/< pid >/smaps (1022 lines) here: http://pastebin.com/fTJJneXr

One of the entries from smaps show that one of them accounts for MOST of it, but has no label... how can I find out what this "blank" entry is that has 28gb?

200000000-900000000 ---p 00000000 00:00 0 
Size:           29360128 kB
Rss:                   0 kB
Pss:                   0 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            0 kB
Anonymous:             0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB

--

ubuntu 11.04 64-bit
16 GB RAM

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

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

发布评论

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

评论(2

朱染 2024-11-23 14:34:08

UVA 要求 CUDA 分配足够的虚拟内存来映射所有 GPU 和系统内存。请参阅以下 NVIDIA 上的线程中的帖子 #5论坛

UVA requires CUDA to allocate enough virtual memory to map all of both GPU and system memory. Please see post #5 in the following thread on the NVIDIA forums:

時窥 2024-11-23 14:34:08

这两个区域可能是罪魁祸首:

200000000-900000000 ---p 00000000 00:00 0
Size:           29360128 kB
Rss:                   0 kB
Pss:                   0 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            0 kB
Anonymous:             0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB
7f2e9deec000-7f2f131ec000 rw-s 33cc0c000 00:05 12626                     /dev/nvidia0
Size:            1920000 kB
Rss:             1920000 kB
Pss:             1920000 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:   1920000 kB
Referenced:      1920000 kB
Anonymous:             0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB

第一个段是一个 30GB 的匿名私有段,不允许对其进行访问,映射范围为 0x200000000-0x900000000。确实有点神秘 - 可能与 nvidia 驱动程序的内部工作有关(也许它想阻止使用这些特定地址进行分配?)。但它实际上并没有占用任何内存 - Rss 为零,并且访问标志 (---p) 设置为拒绝所有访问,因此(目前)实际上不会为它分配任何内存。它只是您的地址空间中的保留部分。

另一位是 /dev/nvidia0 映射,大小为 2 GB。这可能是视频卡 RAM 部分的直接映射。它本身并不占用内存 - 它只是保留部分地址空间用于与硬件通信。

所以这并不是真正值得担心的事情。如果您想知道实际使用了多少内存,请将所有其他内存段的 Rss 数字相加(如果您想跳过共享库等,请使用 Private_* 条目)。

These two regions would be the culprit:

200000000-900000000 ---p 00000000 00:00 0
Size:           29360128 kB
Rss:                   0 kB
Pss:                   0 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            0 kB
Anonymous:             0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB
7f2e9deec000-7f2f131ec000 rw-s 33cc0c000 00:05 12626                     /dev/nvidia0
Size:            1920000 kB
Rss:             1920000 kB
Pss:             1920000 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:   1920000 kB
Referenced:      1920000 kB
Anonymous:             0 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB

The first segment is a 30GB anonymous private segment, with no access to it allowed, mapped from 0x200000000-0x900000000. A bit mysterious, indeed - probably something to do with the nvidia driver's internal workings (maybe it wants to prevent allocations with those specific addresses?). It's not actually occupying any memory though - Rss is zero, and the access flags (---p) are set to deny all access, so (at the moment) actually allocating any memory to it won't happen. It's just a reserved section in your address space.

The other bit is the /dev/nvidia0 mapping, of two gigabytes. This is likely a direct mapping of part of the video card's RAM. It's not occupying memory as such - it's just reserving part of your address space to use to communicate with hardware.

So it's not really something to worry about. If you want to know how much memory you're really using, add up the Rss figures for all other memory segments (use the Private_* entries instead if you want to skip shared libraries and such).

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