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

我有相当不错的networking(专用)服务器具有良好的内存资源

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) 

正如你所看到的,当有足够的可用内存可用时,我的服务器正在使用交换,

这是正常的还是一些configuration或编码的错误?

NB我的MySQL进程正在使用超过160%的CPU电源由于某种原因,我不知道为什么,但我没有超过70同时用户…

这是非常正常的。

在系统启动时,许多服务启动。 这些服务会自行初始化,读取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的内存分配,以便在所有内核上分配内存(请参阅上面的链接了解更多详细信息)。