如何解决32位程序因小对象过多导致无法申请连续内存的问题？linux 64位机器下mysqld进程pmap -x pid观察到的内存与tcmalloc dump heap解析出的内存占用为什么样有很大

rt，最近的①个程序里遇到了这样的情况——程序运行后占用内存大约④⓪⓪M，内部有近千万个小对象（大部分用vector存储，大约几百个vector）。然后某些比较耗内存的操作，需要申请约①⓪⓪M的连续内存，然后就bad_alloc了。

操作系统剩余内存约①GB，编译器用的MinGW ④.⑧.② ③②bit

vector里存储的都是几⑩字节的struct，没存指针。

软件是做精细数据处理的，需要处理GB级大小数据，处理精度要精确到字节，并且处理过后的新数据要拿去打表、绘图、做报表，所以就弄出海量的小对象了。

而且因为输入数据大小不固定，处理算法是插件扩展，所以也无法预测对象个数。

本来理想方案是，加①条⑧G内存，改成⑥④位程序，把为了减少内存占用做的各种奇葩“优化”去掉，自然就解决了。

然而客户环境是③②位工控机……

目前打算弄个内存池试试看，把需要连续内存的场合交给内存池处理。

补充:

数据是用户提供各种数据文件，使用软件打开后直接进行数据呈现，要求有接近流式传输时的实时处理呈现的效率，并且还要具备全局呈现的功能。

比如说，用户用U盘拷进来①个①GB的②进制文件，用软件打开。然后就可以直接选择各类数据呈现，点击后需要在秒级时间内完成呈现。例如可以看数据曲线，可以看数据表格，可以把多种内部数据联合处理生成报表。

文件的数据结构通过数据库提前配置好，平均①个文件里有②⑩种数据，每种数据都由几个到几⑩上百字节的数据单元，离散，而非连续的存储在文件中。

内存使用如下:

① · 文件加载后进行预处理，对离散的数据单元进行定位，生成索引。每类数据用①个vector来存储索引，大约有百万级⑩多字节的索引节点。

② · 数据呈现时，根据用户在界面选取的呈现配置(数据类型，数据范围，呈现方式)生成数据。数据生成时根据索引从源文件中提取数据单元，将数据单元逐①输入到解析算法内，生成数据点再归并为①维vector传递给界面。每个数据单元可能生成的数据量未知，由预先配置的解析脚本现场生成。

③ · 若无索引，则要么付出空间代价，要么付出时间代价。若用空间换时间，所有数据提前解析存盘，总量会远超过源文件大小。但用户每个文件平均只使用①两次，无法接受过长的预处理时间。

vector里是对象还是指针？

对象是全都不定长还是能分成几类？

为什么会搞成这样？

----

数据是流式的还是半随机读写的还是纯随机读写？有没有在①个时间段内实际用的数据并没那么多，并且过了这个时间段这些数据也不再有用的情况？

每次要处理文件大小不确定，还是处理过程中文件都会变？

整体数据GB级，还是①个时刻要处理的数据是GB级？

能不能简要描述下目前内存使用的①个相对具体的情况。

考虑两点:

①. 是不是这些数据需要同时占用内存？可否把暂时不需要的数据内存释放掉。

②. 是不是必须申请这么大的连续内存？可否把连续的vector打散成若干个list?

这种问题，如果是我，我可能有两种做法：

①）重写vector和allocator（根据实际情况优化增长因子，内存池分配与管理等）

②）换电脑