我的应用程序在后台为可能的请求缓冲数据。目前，我根据命令行参数限制缓冲区的大小，并在达到此限制时开始转储较少使用的数据。这并不理想，因为它依赖于用户指定性能关键参数。有没有更好的方法来处理这个？有没有办法在系统开始崩溃之前自动监控系统内存使用并转储最旧/最近最少使用的数据？
这里的一个复杂因素是我的应用程序在 Linux、OSX 和 Windows 上运行。但我会采取一种好方法，只在一个平台上做到这一点。
【问题讨论】：
标签： c++ windows linux macos memory-management
您最好的选择可能是监控您的应用程序工作集/驻留集大小，并在分配后它没有增长时尝试做出反应。关于寻找什么的一些指示：
Windows 还具有 GlobalMemoryStatusEx，它为您提供了一个不错的可用物理内存数据。
【讨论】：
我喜欢您当前的解决方案。让用户决定是好的。不是每个人都希望缓冲区尽可能大，是吗？如果你确实投资了某种内存监视器来自动调整缓冲区/缓存大小，至少让用户在用户设置限制和自动/动态限制之间进行选择。
【讨论】：
我知道这不是一个直接的答案，但我会说退一步，也许不要这样做。
即使您拥有查看当前物理内存使用情况的 API，也不足以选择理想的缓存大小。这将取决于程序和机器（以及运行该程序的所有客户端的整体系统 + 他们正在查询的服务器）的典型和未来工作负载、平台的缓存行为、是否应该调整系统吞吐量或延迟等。在内存紧张的情况下，您将与其他机会性缓存（包括操作系统的磁盘缓存）竞争内存。一方面，您想对他们施加一些压力，以迫使其他低价值数据。另一方面，如果您在内存充足的情况下变得贪婪，您将影响其他自适应缓存的行为。
对于推测性缓存/预取，LRU 值函数很奇怪：您将（希望）首先获取最有可能被调用的数据，然后再获取不太可能的数据，因此预取中的 LRU 数据缓存可能不如旧数据有价值。通过人为地“加热”不常用的数据，这可能会导致系统范围的缓存集出现异常行为。
您的程序似乎不太可能做出比简单的固定大小更好的缓存大小选择，可能会根据机器上整体物理内存的大小进行缩放。而且它几乎不可能击败了解机器典型工作负载及其性能目标的系统管理员。
使用自适应缓存大小策略意味着您的程序的资源使用将是可变的和不可预测的。 （关于内存以及用于填充预取缓存的 I/O 和服务器请求。）对于很多服务器情况，这并不好。 （特别是在 HPC 或 DB 服务器中，这听起来可能适用于高利用率/高吞吐量环境。）一致性、可配置性和可用性通常比最大资源利用率更重要。并且引用的局部性往往会迅速下降，因此随着缓存大小的增加，您可能会获得非常递减的收益。如果这将在服务器端使用，至少保留显式控制缓存大小的选项，并且可能将其设为默认选项（如果不是唯一选项）。
【讨论】：
有一种方法：称为虚拟内存（vm）。列出的所有三个操作系统都将使用虚拟内存 (vm)，除非没有硬件支持（在嵌入式系统中可能是这样）。所以我会假设存在 vm 支持。
这是 Varnish 项目的架构说明中的一段引述：
真正简短的答案是计算机不再有两种存储。
我建议你在这里阅读全文：http://www.varnish-cache.org/trac/wiki/ArchitectNotes
这是一本好书，我相信会回答你的问题。
【讨论】：
您可以尝试分配一些较大的内存块，然后检查内存分配异常。如果发生异常，转储数据。问题是，这仅在达到所有系统内存（或进程限制）时才有效。这意味着您的应用程序可能会开始交换。
try {
char *buf = new char[10 * 1024 * 1024]; // 10 megabytes
free(buf);
} catch (const std::bad_alloc &) {
// Memory allocation failed - clean up old buffers
}
这种方法的问题是：
【讨论】：