为什么在剩余大量空闲内存时使用Swap？

这是非常正常的。

在系统启动时，许多服务启动。 这些服务会自行初始化，读取configuration文件，创build数据结构等等。 他们使用一些记忆。 由于您没有使用这些服务，所以这些服务中的许多将永远不会再运行。 其中一些可能会在数小时，数天或数周内运行。 然而，所有这些数据都在物理内存中。

当然，系统不能丢弃这些数据。 它不能certificate它将永远不会被访问。 例如，其中一种服务可能是为您提供远程访问的服务。 你可能没有在一个星期内使用它，但如果你使用它，它有更好的工作。

但是系统知道它可能喜欢将这个物理内存用于磁盘caching之类的东西，或者以其他方式来提高性能。 所以它做机会主义的交换。 当没有更好的办法的时候，它使用交换空间将很长时间内没有使用的数据写入磁盘。 但是，它仍将页面保留在物理内存中。 所以他们仍然可以访问，而不必交换。

现在，如果系统稍后需要该物理内存作为其他内容，则可以简单地将这些页面扔掉，因为它已经将它们写入交换。 这给系统两全其美。 数据仍然保存在内存中，因此无需从磁盘读取即可访问。 但是，如果系统需要这种内存用于其他目的，则不必先写出来。 大赢全场。

如果在过去的某个时候需要更多的内存，而不是机器中的物理RAM，则可能发生这种情况。 那时候一些数据将被写入交换空间。

当以后的内存被释放时，交换的数据不会自动读回到RAM中：这只有在某些进程实际需要交换的数据时才会发生。 这是非常正常的。

至于你的mysql进程：这一切都取决于你运行的查询types。 理论上，2个非常复杂的查询可能足以获得这样的负载，无论用户数量多less。 您可以启用慢速查询日志，以更深入地了解哪些查询是负载密集型的。

你也可以通过sysctl -w vm.swappiness=10来改变这个行为，这将大大减lessswap的使用，直到实际需要为止。

至于MySQL，你有没有使用tuning-primer.sh脚本至less执行一个基线configurationtesting？

正如David所解释的，这可能是Linux内核的正常行为，但也可能是MySQL“交换错误”问题的发生 。 在你的情况下（8个CPU，总共16 GB RAM，使用5 GB），为了实现这一点，你的计算机应该是一个NUMA系统，每个节点有4个节点（插槽）和4 GB RAM，MySQL InnoDB缓冲池为4 GB。

总之（你应该阅读上面的链接完整的细节），这是发生了什么事情：

1. 系统启动时，所有NUMA节点上的进程都使用其内存进行传播。
2. 当MySQL启动时，它为InnoDB缓冲池分配4 GB，填充NUMA节点的RAM并在其他节点上使用一些RAM。
3. 然后，不能将分配的RAM从一个NUMA节点移动到另一个NUMA节点的Linux内核认为从饥饿的节点中交换页面是个好主意（或者因为需要交换页面而需要换出页面）。

为了避免这种情况，请更改MySQL的内存分配，以便在所有内核上分配内存（请参阅上面的链接了解更多详细信息）。