问题标签 [virtual-memory]

在我正在编写的应用程序中，我使用了很多内存容器（C++ std 容器，但我认为这无关紧要）。

在我的应用程序的一个“任务”中，在大量使用的边缘情况下，私有字节内存使用量达到 1GB。

就像一点上下文一样，这个任务是一个用户启动的任务，涉及 100,000 个文件。用户很可能会启动它，然后让机器运行。

（不，我不会做任何愚蠢的事情，比如将文件加载到内存中——这个足迹是与正在进行的任务相关的所有元数据）。

对于大多数用户而言，此任务期间的内存使用量可以忽略不计——只有 1% 的用户想要执行 500,000 件“事情”中的 5000 件“事情”。

我正要着手将大量内存中的内容以某种方式移动到磁盘上，例如暂存文件、嵌入式数据库。

但后来我想 - “等一下。所有这些解决方案本质上都是将内存缓存到磁盘。这不就是虚拟内存的用途吗？”。

我对保留这些数据不感兴趣——这纯粹是我在任务运行时需要访问的临时/临时内容。

所以我的问题是，我该怎么办？

我不想对那 1% 做重大的重构，但我想知道运行具有如此高内存占用的应用程序的影响。

我是否正确地说我可能无法比 Windows VM 管理器做得更好？

在什么情况下这会变得有害？好的，是的，如果我用完所有的真实内存，那么重新加载页面会很糟糕。但是，如果是嵌入式数据库，我不会有这种情况吗？

干杯，

约翰

I'm writing a program that for performance reasons uses shared memory (sockets and pipes as alternatives have been evaluated, and they are not fast enough for my task, generally speaking any IPC method that involves copies is too slow). In the shared memory region I am writing many structs of a fixed size. There is one program responsible for writing the structs into shared memory, and many clients that read from it. However, there is one member of each struct that clients need to write to (a reference count, which they will update atomically). All of the other members should be read only to the clients.

Because clients need to change that one member, they can't map the shared memory region as read only. But they shouldn't be tinkering with the other members either, and since these programs are written in C++, memory corruption is possible. Ideally, it should be as difficult as possible for one client to crash another. I'm only worried about buggy clients, not malicious ones, so imperfect solutions are allowed.

I can try to stop clients from overwriting by declaring the members in the header they use as const, but that won't prevent memory corruption (buffer overflows, bad casts, etc.) from overwriting. I can insert canaries, but then I have to constantly pay the cost of checking them.

Instead of storing the reference count member directly, I could store a pointer to the actual data in a separate mapped write only page, while keeping the structs in read only mapped pages. This will work, the OS will force my application to crash if I try to write to the pointed to data, but indirect storage can be undesirable when trying to write lock free algorithms, because needing to follow another level of indirection can change whether something can be done atomically.

Is there any way to mark smaller areas of memory such that writing them will cause your app to blow up? Some platforms have hardware watchpoints, and maybe I could activate one of those with inline assembly, but I'd be limited to only 4 at a time on 32-bit x86 and each one could only cover part of the struct because they're limited to 4 bytes. It'd also make my program painful to debug ;)

Edit: I found this rather eye popping paper, but unfortunately it requires using ECC memory and a modified Linux kernel.

我正在通过 c/c++ 阅读 Windows。我只是想知道一个大文件可以映射到内存。

当我们执行一个应用程序时，一个 PE 文件被映射到它们的进程地址（用户分区）。

在 32 位 Windows 中，可以将大文件（大于 2GB）加载到用户分区吗？否则会失败？
如果可能，分页文件是否有助于加载？

操作系统从磁盘读取的内容比程序实际请求的要多，因为程序将来可能需要附近的信息。在我的应用程序中，当我从磁盘获取项目时，我想显示元素周围的信息间隔。在我请求和显示的信息量与速度之间需要权衡取舍。但是，由于操作系统已经读取了比我请求的更多的内容，因此访问内存中已经存在的这些字节是免费的。我可以使用什么 API 来找出操作系统缓存中的内容？

或者，我可以使用内存映射文件。在这种情况下，问题就归结为找出页面是否交换到磁盘。这可以在任何常见的操作系统中完成吗？

编辑：相关论文http://www.azulsystems.com/events/mspc_2008/2008_MSPC.pdf

操作系统内核是否使用虚拟内存或操作系统内核的某些部分是否可以驻留在硬盘中？

现代 x86 CPU 能够支持比传统 4K 更大的页面大小（即 2MB 或 4MB），并且有操作系统工具（Linux、Windows）可以访问此功能。

上面的微软链接指出大页面“提高了翻译缓冲区的效率，这可以提高频繁访问的内存的性能”。这对于预测大页面是否会改善任何给定情况并不是很有帮助。我对移动一些程序逻辑（或整个应用程序）以使用大页面导致一些性能改进的具体的、最好是量化的示例感兴趣。有人有成功案例吗？

我自己知道一个特殊情况：使用大页面可以显着减少分叉大型进程所需的时间（大概是因为需要复制的 TLB 记录的数量减少了大约 1000 倍）。我感兴趣的是大页面是否也可以在不那么奇特的场景中带来好处。

32 位系统上的应用程序可用（理论上）多少内存？不同的操作系统？2 或 1 Gb？

谢谢！

Linux/proc/meminfo显示了许多内存使用统计信息。

它们之间有相当多的重叠。例如，据我了解，可以有活动页面缓存（属于“缓存”和“活动”）和不活动页面缓存（“不活动”+“缓存”）。

我想做的是测量“空闲”内存，但它包括可能被丢弃的已用页面，而不会对整体系统的性能产生重大影响。

起初，我倾向于使用“free”+“inactive”，但是 Linux 的“free”实用程序在其“buffer-adjusted”显示中使用了“free”+“cached”，所以我很好奇有什么更好的方法。

当内核内存不足时，要丢弃的页面的优先级是什么？衡量可用内存的更合适的指标是什么？

如果我有一个 2 GB 的内存，并且我有一个对象的 2 个实例，每个实例为 1.5 GB，操作系统将帮助和上下文在硬盘之间切换页面。

如果我有 1 个实例但为 3 GB，该怎么办。相同的分页方法可以将此实例分解为 2 个页面吗？或者我会遇到内存不足的问题吗？

我还想将相同的问题应用于对象旁边的其他数据结构，分页会将其作为一个整体进行分页，还是将其分解为更小的单元。

谢谢。

再一次，我发现自己有一套破碎的假设。这篇文章本身是关于通过修改一个经过验证的最佳算法来考虑虚拟内存的 10 倍性能提升：

在以千兆赫时钟频率运行的现代多问题 CPU 上，最坏情况下的损失是每个 VM 页面错误几乎 1000 万条指令。如果您使用旋转磁盘运行，那么这个数字更像是 1 亿条指令。

如果这些操作导致页面错误和缓慢的磁盘操作，那么 O(log2(n)) 算法有什么好处？对于大多数相关数据集，避免页面错误的 O(n) 甚至 O(n^2) 算法将围绕它运行。

周围还有更多这样的算法吗？我们是否应该重新审视我们教育的所有这些基本组成部分？自己写的时候还需要注意什么？

澄清：

所讨论的算法并不比经过验证的最优算法快，因为 Big-O 表示法存在缺陷或毫无意义。它更快，因为经过验证的最佳算法依赖于现代硬件/操作系统中不正确的假设，即所有内存访问都是平等的和可互换的。