a*****a
发帖数: 46 | 1 现在有个程序，使用的内存在10G左右，在有24G内存的机器上运行，有时候还是会报内
存不足的错误，主要表现为vector扩大size的时候申请不到内存，然后就挂了。有什么
建议或者资料可以参考？ |
N******K
发帖数: 10202 | 2 std::vector ? 这个在内存中是连续存储的
比如当前10G 打算扩大到12G
但是内存周围都被占了
那么 就重新申请 12G的连续内存 这个时候 总共耗费内存22G 就挂了
【在 a*****a 的大作中提到】
: 现在有个程序，使用的内存在10G左右，在有24G内存的机器上运行，有时候还是会报内
: 存不足的错误，主要表现为vector扩大size的时候申请不到内存，然后就挂了。有什么
: 建议或者资料可以参考？
|
a*****a
发帖数: 46 | 3 不是一个vector，是很多很多的vector，每个vector的size 大概最多有几千个成员。
【在 N******K 的大作中提到】
: std::vector ? 这个在内存中是连续存储的
: 比如当前10G 打算扩大到12G
: 但是内存周围都被占了
: 那么 就重新申请 12G的连续内存 这个时候 总共耗费内存22G 就挂了
|
b*******s
发帖数: 5216 | 4 先全部reserve
【在 a*****a 的大作中提到】
: 现在有个程序，使用的内存在10G左右，在有24G内存的机器上运行，有时候还是会报内
: 存不足的错误，主要表现为vector扩大size的时候申请不到内存，然后就挂了。有什么
: 建议或者资料可以参考？
|
N******K
发帖数: 10202 | 5 和我上面帖子说的一个道理 原地址周围连续空间不够 就要申请新空间 一下子消耗2
倍多内存
【在 a*****a 的大作中提到】
: 不是一个vector，是很多很多的vector，每个vector的size 大概最多有几千个成员。
|
N******K
发帖数: 10202 | 6 推荐换成java 有GC 多舒服
【在 b*******s 的大作中提到】
: 先全部reserve
|
h****r
发帖数: 2056 | 7 这个就是memory fragmentation问题。
【在 a*****a 的大作中提到】
: 现在有个程序，使用的内存在10G左右，在有24G内存的机器上运行，有时候还是会报内
: 存不足的错误，主要表现为vector扩大size的时候申请不到内存，然后就挂了。有什么
: 建议或者资料可以参考？
|
w***x
发帖数: 105 | 8 什么系统？程序运行了多长时间？如果运行了若干天，试试google的tcmalloc, |
k**********g
发帖数: 989 | 9
Rewrite your code to allow use of non-contiguous backing memory instead. C++
allows overloading of index operators among many things.
Whether this will affect algorithm performance depends on how much random
access (low spatial locality) is performed. If your algorithm is mostly
sequential on memory access, this restructuring will not impact performance
much.
【在 a*****a 的大作中提到】
: 现在有个程序，使用的内存在10G左右，在有24G内存的机器上运行，有时候还是会报内
: 存不足的错误，主要表现为vector扩大size的时候申请不到内存，然后就挂了。有什么
: 建议或者资料可以参考？
|
h****r
发帖数: 2056 | 10 tcmalloc相gnu libc malloc, 对多线程环境下的memory fragmentation有点帮助，但
是不大。
主流的几个allocator对数组性质的连续内存（比如vector或者其他的固定size的数组
）的管理都有自己的保留，
在free后，并不立即返还给系统，而是留着备用。这个不是memory fragmentation，但
是和memory fragmentation造成同样的问题。
一般vector的resize都是装满一半后开始，如果多个vector的初使size都差不多。
【在 w***x 的大作中提到】
: 什么系统？程序运行了多长时间？如果运行了若干天，试试google的tcmalloc,
|
|
|
N******K
发帖数: 10202 | 11 在free后，并不立即返还给系统 你是说 std::vector的clear函数吧
std::vector 还有一个 shrink_to_fit 是把内存还给系统
【在 h****r 的大作中提到】
: tcmalloc相gnu libc malloc, 对多线程环境下的memory fragmentation有点帮助，但
: 是不大。
: 主流的几个allocator对数组性质的连续内存（比如vector或者其他的固定size的数组
: ）的管理都有自己的保留，
: 在free后，并不立即返还给系统，而是留着备用。这个不是memory fragmentation，但
: 是和memory fragmentation造成同样的问题。
: 一般vector的resize都是装满一半后开始，如果多个vector的初使size都差不多。
|
S*A
发帖数: 7142 | 12 这种情况似乎是自己管理写底层的 mmap/unmap/remap area 大概是最
直接管理内存的。
C++ 自己悄悄做很多内存分配怕是很难简单搞定这个问题。
【在 h****r 的大作中提到】
: tcmalloc相gnu libc malloc, 对多线程环境下的memory fragmentation有点帮助，但
: 是不大。
: 主流的几个allocator对数组性质的连续内存（比如vector或者其他的固定size的数组
: ）的管理都有自己的保留，
: 在free后，并不立即返还给系统，而是留着备用。这个不是memory fragmentation，但
: 是和memory fragmentation造成同样的问题。
: 一般vector的resize都是装满一半后开始，如果多个vector的初使size都差不多。
|
k**********g
发帖数: 989 | 13
刚才回覆前没看清楚原文，现在深想一层，
64-bit process是不容易出现virtual address space fragmentation的。
在CPU MMU (Paging system)的作用下，物理地址的fragmentation从来不是问题
（就好像把香肠的碎渣收集起来，又灌注一条新香肠一样）。
你遇见的问题，有三个可能性∶
（1）内存泄漏，有一些应该要释放的内存，实际上因为某种原因没有被释放。
（2）C++ 的建构或赋值重载代码，或调用的代码，或类库介面设计有缺陷，导致临时
对象产生，因此出现了短暂的内存泄漏或冗馀占用。
（3）标准库内的缺陷或不足，导致临时对象产生，或短暂的冗馀占用。
以上所有可能性都可以透过 debugger step execution 排解。
【在 a*****a 的大作中提到】
: 现在有个程序，使用的内存在10G左右，在有24G内存的机器上运行，有时候还是会报内
: 存不足的错误，主要表现为vector扩大size的时候申请不到内存，然后就挂了。有什么
: 建议或者资料可以参考？
|
S*A
发帖数: 7142 | 14
谁说的。64 位和 32 位都一样回出现 fragment。64位就是地址大些。
但是paging 都是 4K 的（有2M paging 但是那个fragment 更大）。
前面有人指出了，这个内存是因为 lib 内部自己扩容数组的时候没有
完全用满。这样内存使用率就不高。如果加上不断 free object。
必然出现 4K 页内部不能完全用满的情况。但是你也不能压缩。
因为这个涉及所有使用的指针都要跟着变。有 GC 就好很多。
C 没有 GC 就没法灌个新香肠。
【在 k**********g 的大作中提到】
:
: 刚才回覆前没看清楚原文，现在深想一层，
: 64-bit process是不容易出现virtual address space fragmentation的。
: 在CPU MMU (Paging system)的作用下，物理地址的fragmentation从来不是问题
: （就好像把香肠的碎渣收集起来，又灌注一条新香肠一样）。
: 你遇见的问题，有三个可能性∶
: （1）内存泄漏，有一些应该要释放的内存，实际上因为某种原因没有被释放。
: （2）C++ 的建构或赋值重载代码，或调用的代码，或类库介面设计有缺陷，导致临时
: 对象产生，因此出现了短暂的内存泄漏或冗馀占用。
: （3）标准库内的缺陷或不足，导致临时对象产生，或短暂的冗馀占用。
|
k**********g
发帖数: 989 | 15
64位也就足够大了。
你下面说的情况不是fragmentation而是memory page under-utilization（虽然我承认
这是咬文嚼字）。
你说的对，我看漏了三楼的描述。
但另一方面，作业系统也会把使用频率不高的内存页移到硬碟分页分区。
实际上，很多作业系统都可以设置成容许over-commit。
不得不问楼主∶神马作业系统？
【在 S*A 的大作中提到】
:
: 谁说的。64 位和 32 位都一样回出现 fragment。64位就是地址大些。
: 但是paging 都是 4K 的（有2M paging 但是那个fragment 更大）。
: 前面有人指出了，这个内存是因为 lib 内部自己扩容数组的时候没有
: 完全用满。这样内存使用率就不高。如果加上不断 free object。
: 必然出现 4K 页内部不能完全用满的情况。但是你也不能压缩。
: 因为这个涉及所有使用的指针都要跟着变。有 GC 就好很多。
: C 没有 GC 就没法灌个新香肠。
|
S*A
发帖数: 7142 | 16
只有完整页都不用才可以swap out。
如果页里面有频繁使用的数据就没法
swap out。 如果反复分配不是4k对其
的内存然后释放必然有碎片。
【在 k**********g 的大作中提到】
:
: 64位也就足够大了。
: 你下面说的情况不是fragmentation而是memory page under-utilization（虽然我承认
: 这是咬文嚼字）。
: 你说的对，我看漏了三楼的描述。
: 但另一方面，作业系统也会把使用频率不高的内存页移到硬碟分页分区。
: 实际上，很多作业系统都可以设置成容许over-commit。
: 不得不问楼主∶神马作业系统？
|
a*********a
发帖数: 3656 | 17 yeah, easiest ways out:
if you know the max size require, reserve first.
if not,
you can change to a non contiguous container and suck up the speed loss.
if your vector contains big objects, it might be better to allocate them on
a boost::pool, and use a vector of pointers to them. then the vectors
themselves become much smaller and resizing them would probably cause no mem
issue and faster. and you never copy those big objects around.
【在 b*******s 的大作中提到】
: 先全部reserve
|
A*********l
发帖数: 2005 | 18 还有一个可能性是memory corruption，表现症状是在 new 的时候程序崩溃，这个我在
工作中实际遇到过，同事也遇到过。
如果楼主的症状是有明确的 out of memory exception的话，或者new返回null的话，
那这条不适用，否则，要考虑这个可能性。
【在 a*****a 的大作中提到】
: 现在有个程序，使用的内存在10G左右，在有24G内存的机器上运行，有时候还是会报内
: 存不足的错误，主要表现为vector扩大size的时候申请不到内存，然后就挂了。有什么
: 建议或者资料可以参考？
|
w***x
发帖数: 105 | 19 通常memory fragmentation发生在长时间运行并频繁malloc/free memory，我曾经遇到
多这种问题，系统连续运行3天，还有近1G的可用空间，可是却无法提供4M大小的物理
连续的内存...
不清楚stl的alloctor做了何种优化，不过malloc实际上已经做了相当多的工作来避免
这些问题，所以如果程序运行时间不长就出现问题，基本可以肯定是程序本身的错误，
如果是stl的resize问题debug进去很快就能查清楚了。 |
S*A
发帖数: 7142 | 20 很好奇什么东西要用 4M 物理
连续地址。如果是user space
程序不应该关心物理地址。
就算对Linux内核，4M也是非常
大。vmalloc是另一回事。
很难想象什么可以合理必须用到
4M物理连续地址。
【在 w***x 的大作中提到】
: 通常memory fragmentation发生在长时间运行并频繁malloc/free memory，我曾经遇到
: 多这种问题，系统连续运行3天，还有近1G的可用空间，可是却无法提供4M大小的物理
: 连续的内存...
: 不清楚stl的alloctor做了何种优化，不过malloc实际上已经做了相当多的工作来避免
: 这些问题，所以如果程序运行时间不长就出现问题，基本可以肯定是程序本身的错误，
: 如果是stl的resize问题debug进去很快就能查清楚了。
|
|
|
w***x
发帖数: 105 | 21 是硬件的driver。4M不算大了。
另外vmalloc分配的是vaddr contiguous mem。
【在 S*A 的大作中提到】
: 很好奇什么东西要用 4M 物理
: 连续地址。如果是user space
: 程序不应该关心物理地址。
: 就算对Linux内核，4M也是非常
: 大。vmalloc是另一回事。
: 很难想象什么可以合理必须用到
: 4M物理连续地址。
|
h****r
发帖数: 2056 | 22 这个不足为奇，产生新的thread的时候，预先给thread分配stack空间（这个是在heap
里面），
8M, 4M，2M，1M, 512k都是常用的size，这一步在调用clone之前发生。
【在 S*A 的大作中提到】
: 很好奇什么东西要用 4M 物理
: 连续地址。如果是user space
: 程序不应该关心物理地址。
: 就算对Linux内核，4M也是非常
: 大。vmalloc是另一回事。
: 很难想象什么可以合理必须用到
: 4M物理连续地址。
|
S*A
发帖数: 7142 | 23 硬件的 driver 要随时分配 4M 的连续地址也很大了。
这个基本上要在启动的时候reserve。
kmalloc 4M 的内存是非常大的了。
实际上，kmalloc的上限是 4M.
而且实际运行中这个经常 fail 的。
所以很好奇你得是什么情况需要用到 4M 而不会
用 SG list。
我知道，所以是另外说阿。
【在 w***x 的大作中提到】
: 是硬件的driver。4M不算大了。
: 另外vmalloc分配的是vaddr contiguous mem。
|
S*A
发帖数: 7142 | 24 这个我非常确定你说的 thread 是 Virtual address 不是物理address。
要求连续 4M 物理 address 非常罕见。
heap
【在 h****r 的大作中提到】
: 这个不足为奇，产生新的thread的时候，预先给thread分配stack空间（这个是在heap
: 里面），
: 8M, 4M，2M，1M, 512k都是常用的size，这一步在调用clone之前发生。
|
h****r
发帖数: 2056 | 25 mmap is used in malloc if the allocation size is more than 128k.
【在 S*A 的大作中提到】
: 这个我非常确定你说的 thread 是 Virtual address 不是物理address。
: 要求连续 4M 物理 address 非常罕见。
:
: heap
|
a*****a
发帖数: 46 | 26 多谢分析
原文没有说环境，我是在HPC的cluster的一个node上。现在我怀疑有可能是有个参数设
置的不合理
有个参数是 per-process virtual memory limit. 之前使用的之前默认的5gb，一个
node上有24gb，有8个处理器，我申请了整个node，然后只跑一个process。
后来我把这个参数去掉后，目前看起来就没有挂了
【在 k**********g 的大作中提到】
:
: 64位也就足够大了。
: 你下面说的情况不是fragmentation而是memory page under-utilization（虽然我承认
: 这是咬文嚼字）。
: 你说的对，我看漏了三楼的描述。
: 但另一方面，作业系统也会把使用频率不高的内存页移到硬碟分页分区。
: 实际上，很多作业系统都可以设置成容许over-commit。
: 不得不问楼主∶神马作业系统？
|
S*A
发帖数: 7142 | 27 Mmap 还是在 virtual address，不是保证物理地址连续。
mmap我很熟悉的。
【在 h****r 的大作中提到】
: mmap is used in malloc if the allocation size is more than 128k.
|
w***x
发帖数: 105 | 28 我的情况是，不用kmalloc分配内存，而是上来就保留了一大块内存，从64M到512M不等
，然后自己管理内存，动态分配，但要保障每个object的内存是处在连续的空间内。所
以4M对我来说不算大，但对kmalloc可就要命了。
【在 S*A 的大作中提到】
: 硬件的 driver 要随时分配 4M 的连续地址也很大了。
: 这个基本上要在启动的时候reserve。
: kmalloc 4M 的内存是非常大的了。
: 实际上，kmalloc的上限是 4M.
: 而且实际运行中这个经常 fail 的。
: 所以很好奇你得是什么情况需要用到 4M 而不会
: 用 SG list。
:
: 我知道，所以是另外说阿。
|
w***x
发帖数: 105 | 29 是的，mmap分配的不能保障物理连续。
【在 S*A 的大作中提到】
: Mmap 还是在 virtual address，不是保证物理地址连续。
: mmap我很熟悉的。
|
S*A
发帖数: 7142 | 30 这个和我猜的一样。这么大得空间一般只有在启动的时候 reserve。
启动以后要这样分配是不能保证的。
我明白有物理连续很方便。我好奇的是为什么不能用 scatter gather list。
是因为编程方便（偷懒）的原因还是硬件不支持 DMA fragment。
连 Intel 的显卡这种占用很多内存做特殊用途的硬件都可以用单
个的 page，不需要物理连续。 你的驱动非要物理连续是有正当理由吗？
而且我怀疑你的驱动是自己玩玩没有 merge 到官方内核吧。
我以前投过改动包含 kmalloc > 32K 都被别人批评，你的 4M 如果没有
正当理由肯定被痛贬。
【在 w***x 的大作中提到】
: 我的情况是，不用kmalloc分配内存，而是上来就保留了一大块内存，从64M到512M不等
: ，然后自己管理内存，动态分配，但要保障每个object的内存是处在连续的空间内。所
: 以4M对我来说不算大，但对kmalloc可就要命了。
|
|
|
w***x
发帖数: 105 | 31 dma支持sg当然好，不过那是外部看，有些硬件内部还是需要连续地址的。
比如你说的Intel显卡，就我所知，system mem可以用sg传递给gpu，但在gtt地址空间
内，是不可以用sg，还是需要连续地址，这和虚拟地址分配一样。这种情况下，碎片是
无法避免的。我做的是嵌入式下的，不是linux。
【在 S*A 的大作中提到】
: 这个和我猜的一样。这么大得空间一般只有在启动的时候 reserve。
: 启动以后要这样分配是不能保证的。
: 我明白有物理连续很方便。我好奇的是为什么不能用 scatter gather list。
: 是因为编程方便（偷懒）的原因还是硬件不支持 DMA fragment。
: 连 Intel 的显卡这种占用很多内存做特殊用途的硬件都可以用单
: 个的 page，不需要物理连续。 你的驱动非要物理连续是有正当理由吗？
: 而且我怀疑你的驱动是自己玩玩没有 merge 到官方内核吧。
: 我以前投过改动包含 kmalloc > 32K 都被别人批评，你的 4M 如果没有
: 正当理由肯定被痛贬。
|
S*A
发帖数: 7142 | 32 GTT 这个我熟悉。你说的 GTT 是一个显卡的物理虚拟地址。Intel 显卡没有
自己的内存。显卡在 PCI BAR 上有保留了一段物理地址空间，的确是连续的。
这个就是 GTT。这个物理虚拟地址不是被固定内存来 back 的，而仅仅是读
写显卡内存的一个窗口。这段空间不能用 kmalloc 来获得，因为根本不是
内存。使用 PCI reserve 来保留。
Intel 显卡内部有自己的 page table。所以这个 GTT 仅仅是通过显卡来读写
内存的窗口。当显卡需要使用内存的时候，这个内存就必须被显卡的 pg table
map 到 GTT 地址上。这时候，同样的内存就有两个物理地址都可以访问到。
一个是原来的内存地址，另外一个是 GTT 窗口里的显卡搞的虚拟物理地址。
被 MAP 在GTT 的内存，必须通过 GTT 窗口来读写。在这个窗口里，有
显卡来维护这个内存的 caching。如果直接访问原来内存的物理的地址
就会造成显卡内存的cache不一致。后果自负。
然后真正使用到的内存，是page size大小的，也就是 4K 一个。
不同的物理地址的 page 可以在 GTT 窗口的虚拟地址连续，这个由 Intel
显卡上的 pg table 来实现的。所以 Intel 显卡使用的内存是 4K page size。
所以从 Linux 分配内存给显卡是不需要连续的。
我是非常不幸的少数几个需要真正理解Intel那套特别复杂的内存使用机制的
倒霉蛋。 Nvidia 有自己显卡内存，不需要做这种超级复杂两级物理地址
mapping，也不参与 swapping。Intel 的显卡内存是间接参与swapping 的。
片是
【在 w***x 的大作中提到】
: dma支持sg当然好，不过那是外部看，有些硬件内部还是需要连续地址的。
: 比如你说的Intel显卡，就我所知，system mem可以用sg传递给gpu，但在gtt地址空间
: 内，是不可以用sg，还是需要连续地址，这和虚拟地址分配一样。这种情况下，碎片是
: 无法避免的。我做的是嵌入式下的，不是linux。
|
w***x
发帖数: 105 | 33 写的挺好，gtt在cpu角度看，就是保障cache一致的一个窗口，不过芯片如果支持llc，
也可以绕过gtt直接访问sysmem,。intel的内存管理，实际上有两个，一个是gtt的空间
管理，另一个是它的stolen mem管理，用的都是一套东西，但和系统的virtual内存一
样，都有碎片化的问题，所以都需要把一些内存块swap出去。这方面，我想nv也一样，
独立显存也是有限的。
关于物理连续的内存分配，有时候还是需要的，有些老旧的video capture设备，硬件
需要物理连续的buffer，需要在效率和碎片之间做平衡，就比较讨厌了。
【在 S*A 的大作中提到】
: GTT 这个我熟悉。你说的 GTT 是一个显卡的物理虚拟地址。Intel 显卡没有
: 自己的内存。显卡在 PCI BAR 上有保留了一段物理地址空间，的确是连续的。
: 这个就是 GTT。这个物理虚拟地址不是被固定内存来 back 的，而仅仅是读
: 写显卡内存的一个窗口。这段空间不能用 kmalloc 来获得，因为根本不是
: 内存。使用 PCI reserve 来保留。
: Intel 显卡内部有自己的 page table。所以这个 GTT 仅仅是通过显卡来读写
: 内存的窗口。当显卡需要使用内存的时候，这个内存就必须被显卡的 pg table
: map 到 GTT 地址上。这时候，同样的内存就有两个物理地址都可以访问到。
: 一个是原来的内存地址，另外一个是 GTT 窗口里的显卡搞的虚拟物理地址。
: 被 MAP 在GTT 的内存，必须通过 GTT 窗口来读写。在这个窗口里，有
|
S*A
发帖数: 7142 | 34 多谢夸奖。
GTT 主要是管理显卡使用的虚拟地址空间。然后显卡有个 pg table 映射到
真正的内存上。其实没有很多碎片的问题，碎片的大小就是 page。 显卡
驱动需要用的时候就拿 page。不用的时候就把 page 放会去。 swapping
是看内核有压力的时候，就释放多一点内存。Intel 的好处是显卡的内存
几乎是无限的，虽然一次只能有 GTT 窗口地址那么多同时用。
GTT 的碎片化其实不是什么问题。因为操作完的东西就可以释放了，
你基本上可以理解为一个 FIFO，在 Fence 以内的是显卡正在用的。
如果紧急需要，可以全部清除出去的，例如 hibernate to disk 的时候。
GTT 里面基本上没有什么需要长时间锁在里面的。
【在 w***x 的大作中提到】
: 写的挺好，gtt在cpu角度看，就是保障cache一致的一个窗口，不过芯片如果支持llc，
: 也可以绕过gtt直接访问sysmem,。intel的内存管理，实际上有两个，一个是gtt的空间
: 管理，另一个是它的stolen mem管理，用的都是一套东西，但和系统的virtual内存一
: 样，都有碎片化的问题，所以都需要把一些内存块swap出去。这方面，我想nv也一样，
: 独立显存也是有限的。
: 关于物理连续的内存分配，有时候还是需要的，有些老旧的video capture设备，硬件
: 需要物理连续的buffer，需要在效率和碎片之间做平衡，就比较讨厌了。
|
