出于某种原因，我们的系统开始交换（积极使用内存）在60GB左右的内存。 （见下面的编辑，似乎I / O和磁盘caching的使用，甚至以前运行的进程有一个效果）关掉（ swapoff-a ）为testing导致bad_alloc的一次（我猜是因为有更多的进程也使用内存时间），但也加快了我的程序的速度比10倍。
这再现了这个问题（没有其他重要的进程正在运行EDIT：见下文，只有在I / O激烈的过程之前运行）：
#include <cstdio> #include <vector> int main() { size_t bytes = size_t(80) * 1024 * 1024 * 1024; // 80GB size_t* data = new size_t[bytes / sizeof(size_t)]; for (size_t i = 0; i < bytes / sizeof(size_t); ++i) { data[i] = i; } for (;;) {} }
在大约60GB使用的内存，系统开始交换和CPU使用率低于100％（因为现在我想这个过程是I / O绑定）。
系统是Ubuntu 14.04,64bit：
Linux ... 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
一旦达到了这一点，这是什么免费-m给我：
total used free shared buff/cache available Mem: 96671 55504 358 60 40808 40478 Swap: 47679 19366 28313
这个问题依然存在，swappiness = 1（如果I / O密集的东西刚刚运行，特别是对于我的实际的罪魁祸首（不是上面的代码），这两个都有很多的I / O并使用大量的内存。最近I / O，上面的程序分配所有内存，不交换！
如果长时间没有任何I / O激烈的话，问题就会消失。 似乎操作系统以某种方式让我的应用程序交换，因为它认为磁盘caching更有价值 – 即使在非常低的swappiness。 我不理解这种行为，因为磁盘caching内存应该像内存一样好，而且肯定不会触发正在运行的进程。
最初我的问题发生在读取大文件并使用大量内存的应用程序中。 之后，它坚持上面没有任何I / O的示例代码。 最后，当我稍后启动示例代码时，不会发生交换。
64 GB似乎是支持PAE的32位Ubuntu的限制： https ： //help.ubuntu.com/community/32bit_and_64bit
32位计算机的字长为32位，理论上这将内存限制为4GB。 通过使用“物理地址扩展”（或PAE）扩展了这一障碍，将限制增加到64GB，尽pipe4GB以上的内存访问会稍微慢一些。
检查vmstat以查看si ， so （交换进/出）实际上是填充任何交换。 即使swappiness设置为0，swap也可以分配swap。