我有一个生产主机，如下：

该系统使用1GB的交换空间，同时保留近40GB的未使用的可用内存空间。我应该担心这一点，还是大多数情况下正常？

这不是问题，可能很正常。很少使用大量代码（可能还有数据），因此系统会将其换出以释放内存。

如果连续不断地交换内存，交换只是一个问题。正是这种活动会降低性能，并提示系统上其他地方存在问题。

如果要监视交换活动，可以使用几个实用程序，但是vmstat通常非常有用，例如

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 348256  73540 274600    0    0     1     9    9    6  2  0 98  0  0
 0  0      0 348240  73544 274620    0    0     0    16   28   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   29   33  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   21   23  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   24   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   23   23  0  0 100  0  0

忽略第一行，因为这是系统启动以来的活动。注意下的si和so列---swap--；他们通常应该是相当小的数字，即使在大多数情况下不为0。

还值得一提的是，可以通过内核设置来控制这种抢占式交换。位于的文件/proc/sys/vm/swappiness包含0到100之间的数字，它告诉内核如何积极地换出内存。整理文件以查看其设置。默认情况下，大多数Linux发行版默认将其设置为60，但是如果在内存耗尽之前不想看到任何交换，请在文件中回显0，如下所示：

echo 0 >/proc/sys/vm/swappiness

可以通过添加使其成为永久性

vm.swappiness = 0

到/etc/sysctl.conf。

如果没有更好的事情，Linux将抢先将页面写到磁盘上。但这并不意味着它就会收回从内存中这些网页，但。这只是在情况下，它必须在未来某个时候驱逐那些页面，它并不需要等待它们被写入磁盘，因为他们已经在那里。

毕竟，内存不足的原因可能是因为您的计算机已经在努力工作，所以您不想为交换增加负担。机器什么都不做时最好进行交换。

由于类似的原因，您的内存应该总是装满的。内存页面，文件系统缓存等tmpfs，可以在内存中保存很多东西。确实，您应该担心内存是否为空。毕竟，您为此付出了很多钱（至少与同等数量的磁盘空间相比），因此最好使用它！

交换使用还不错，但是很多交换活动是

  vmstat 1
  procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  6  0 521040 114564   6688 377308    8   13   639   173    0 1100  5  4 90  0
  1  0 521040 114964   6688 377448    0    0   256     0    0 1826  3  4 94  0
  0  0 521040 115956   6688 377448    0    0     0     0    0 1182  7  3 90  0
  0  0 521036 115992   6688 377448    4    0    16     0    0 1154 10  2 88  0
  3  0 521036 114628   6696 377640    0    0   928   224    0 1503 15 17 67  1

交换列完全没有问题。在列非零个值对，并因此是致命的服务器性能。特别是具有大量RAM的内存。

最好在具有数GB RAM的计算机上禁用交换性：

sysctl -w vm.swappiness=0

这不会禁用交换。它只会指示Linux使用交换作为最后的手段。这将浪费一些MB的程序，这些程序不需要在RAM中...但是最好是交换大量的磁盘访问队列。

编辑1：为什么默认交换值不是最佳的

我们要记得二十年前，一个大的486只有32Mb RAM。当整个RAM可以在短短的几分之一秒内移动到磁盘时，就开发了交换算法。即使当时的磁盘速度较慢。这就是默认交换策略如此激进的原因。内存是那些日子的瓶颈。从那时起，RAM的大小增加了10,000倍以上，磁盘速度也增加了10倍以下。这将瓶颈转移到磁盘带宽上。

编辑2：为什么这样的活动对服务器来说是致命的？

硅和因此与吨的RAM机活动是致命的，因为手段的系统与自身奋斗的RAM。发生的事情是，与RAM相比，磁盘甚至大型存储都太慢了。主动交换倾向于使用内核磁盘缓存而不是应用程序数据，并且是争夺RAM的最常见来源。由于操作系统将必须释放每个si上的磁盘缓存，因此交换所提供的额外缓存的生存时间太短而无法使用。结果是您占用了磁盘带宽来存储可能不会使用的缓存，并暂停了等待si页的程序。这意味着消耗大量关键资源，而对应用程序几乎没有好处。

注意响应的标题“具有大量RAM的服务器上的大量交换活动”。这不适用于具有si等活动的机器。如果操作系统中开发了更智能的交换算法，则将来可能不适用。

编辑3：“冷”页面

人们将交换算法浪漫化。有人说“占用较少的RAM页面”，但这根本不是内核要做的。关于交换的事情很难理解，因为内核不知道什么是“冷页”。内核没有很好的指标来确定页面是否已被使用或在不久的将来可能会被使用。为了避免内核将页面或多或少地随机放置在交换中，不需要的页面保留在那里。该算法的问题是页面需要转到交换区以了解应用程序是否需要它们。这意味着很多“热门”页面将进入交换。问题在于，与RAM相比，磁盘太慢了。

我建立了自己的基准，这是许多应用程序都非常常见的现实情况。从我的测试中，我发现使用交换时在吞吐量或延迟方面没有任何好处。离得很远。交换开始时，它将吞吐量和延迟都降低了至少一个数量级。

我对此做进一步介绍：我知道交换不用于处理。掉期仅用于紧急情况。那些时刻，同时有太多的应用程序在运行，您会遇到内存高峰。如果不进行交换，将导致内存不足错误。我认为交换使用是开发和生产团队的失败。这只是超越我们在此讨论的观点，而是我的想法。当然，我的应用程序本身具有出色的内存管理。

这不是您问题的答案；而是提供了更多信息来帮助您做出明智的决定。

如果您想知道哪些进程专门在使用多少交换，请使用以下shell脚本：

#!/bin/bash

set -o posix
set -u

OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` ; do
  PID=`echo $DIR | cut -d / -f 3`
  PROGNAME=`ps -p $PID -o comm --no-headers`

  SUM=0
  for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'` ; do
    let SUM=$SUM+$SWAP
  done
  echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"

  let OVERALL=$OVERALL+$SUM
done
echo "Overall swap used: $OVERALL"

我还应该补充一点，tmpfs也将换出。这在使用systemd的现代linux系统上更为常见，后者使用tmpfs创建用户空间/ tmp覆盖。

我注意到代理进行大量交换时，MySQL Cluster复制会变慢或失败。也许某些应用程序不介意，甚至可能从某些交换中受益，但数据库似乎确实遭受了它的折磨。但是，我在论坛上看到的许多讨论都讨论了从特定工作负载讨论中脱上下文而来的交换。

在DBA世界中，共识似乎是“常识是，当您运行MySQL（或实际上是任何其他DBMS）时，您不希望在交换空间中看到任何I / O。缩放缓存大小（使用在MySQL的情况下为innodb_buffer_pool_size）是一种标准做法，可确保有足够的可用内存，因此不需要交换。

但是，如果您犯了一些错误或计算错误，并且发生交换，该怎么办？它实际上对性能有多大影响？这正是我要调查的内容。”

希望读者能从以下内容找到合适的链接。

https://www.percona.com/blog/2017/01/13/impact-of-swapping-on-mysql-performance/

https://www.percona.com/blog/2010/01/18/why-swapping-is-bad-for-mysql-performance/