当剩余大量可用内存时，为什么要使用交换？

我有一个不错的Web（专用）服务器，具有良好的内存资源：

System information
Server load     2.19 (8 CPUs)   
Memory Used     29.53% (4,804,144 of 16,267,652)    
Swap Used   10.52% (220,612 of 2,097,136)   

如您所见，当有足够的可用内存时，我的服务器正在使用交换。

这是正常现象还是配置或编码有问题？

注意：
由于某种原因，我的MySQL进程占用了超过160％的CPU能力。我不知道为什么，但同时用户不超过70个...

这是完全正常的。

在系统启动时，将启动许多服务。这些服务会自行初始化，读取配置文件，创建数据结构等。他们使用一些内存。这些服务中的许多服务在系统启动期间将永远不会再运行，因为您没有使用它们。其中一些可能会在数小时，数天或数周内运行。但是所有这些数据都在物理内存中。

当然，系统无法丢弃这些数据。它不能证明它实际上不会被访问。例如，其中一项服务可能是为您提供对包装盒的远程访问的服务。您可能在一周内没有使用过它，但是如果您确实使用过它，则效果更好。

但是系统知道，它可能希望将该物理内存用于磁盘缓存之类的事情，或以其他可提高性能的方式使用。因此，它确实是机会交换。当没有更好的事情可做时，它会使用交换空间将很长时间未使用的数据写入磁盘。但是，它仍将页面保留在物理内存中。因此，仍然可以访问它们而无需交换它们。

现在，如果系统以后需要该物理内存用于其他用途，则可以将这些页面丢弃，因为它已经将它们写入了交换空间。这为系统提供了两全其美的优势。数据仍保留在内存中，因此无需从磁盘读取数据即可对其进行访问。但是，如果系统需要该内存用于其他用途，则不必先将其写出。大获全胜。

如果过去某个时候您需要的内存多于计算机中的物理RAM，则可能发生这种情况。到那时，一些数据将被写入交换空间。

当以后的内存被释放时，交换中的数据不会自动读回RAM：仅当交换中的数据实际上由某个进程需要时才会发生。这是完全正常的。

至于您的mysql进程：这全部取决于您运行的查询的类型。从理论上讲2，非常复杂的查询可能足以满足这样的负载，而无论您的用户数量如何。您可以启用慢查询日志，以更深入地了解哪些查询是负载密集型的。

您还可以通过更改此行为sysctl -w vm.swappiness=10，这将大大减少交换的使用，直到实际需要它为止。

至于MySQL，您至少使用Tuning-primer.sh脚本执行了基线配置测试吗？

正如David解释的那样，这可能是Linux内核的正常行为，但也可能是MySQL“交换疯狂”问题的发生。在这种情况下（8个CPU，总共16 GB RAM，已使用5 GB），您的计算机应该是具有4个节点（插槽）和每个节点4 GB RAM以及4个MySQL InnoDB缓冲池的NUMA系统。 GB。

简而言之（您应该阅读上面的链接以获取完整的详细信息），这是发生的情况：

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

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