我应该担心在具有近40GB空闲内存的主机上正在使用交换吗?

我有一个生产主机,如下所示:

HTOP

系统使用1GB的交换空间,同时保留将近40GB的空闲空间。 我应该关心这个还是大部分是正常的?

    这不是一个问题,可能是正常的。 很多代码(可能还有数据)很less使用,所以系统会将其交换出来以释放内存。

    如果内存连续地进出,交换只是一个问题。 正是这种活动杀死了绩效,并在系统的其他地方提出了一个问题。

    如果你想监视你的交换活动,你可以用几个实用程序,但是vmstat通常是非常有用的,例如

     $ vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- rb 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 

    从系统启动以来,忽略第一行是活动。 请注意下列的“ ---swap-- 。 他们通常应该是相当小的数字,如果大多数时间不是0。

    另外值得一提的是,这种先占式交换可以通过内核设置来控制。 /proc/sys/vm/swappiness中的/proc/sys/vm/swappiness包含一个介于0和100之间的数字,告诉内核如何积极地交换内存。 捕获该文件以查看设置为的内容。 默认情况下,大多数Linux发行版默认为60,但如果在内存耗尽之前不想看到任何交换,请将0回显到文件中,如下所示:

     echo 0 >/proc/sys/vm/swappiness 

    这可以通过添加永久化

     vm.swappiness = 0 

    /etc/sysctl.conf

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

    毕竟,你内存不足的原因可能是因为你的机器已经在努力工作,你不想额外的交换负担。 当机器什么都不做时更好地做交换。

    出于类似的原因,你的记忆应该总是充满的。 内存页面,文件系统caching, tmpfs ,有太多可以保存在内存中的东西。 真的,你应该关心你的记忆是否空虚; 毕竟,你花了很多钱(至less相当于相同数量的磁盘空间),所以最好使用!

    使用交换不坏,但交换活动很多

      vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- rb 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 

    交换完全没有问题。 在列si等非零值对服务器性能是致命的。 特别是那些有很多RAM的。

    最好在具有几GB的RAM的机器上禁用swapinness:

     sysctl -w vm.swappiness=0 

    这不会禁用交换。 它只会指示Linux使用交换作为最后的手段措施。 这将浪费几MB的程序,不需要在RAM中…但最好是交换膨胀你的磁盘访问队列。

    编辑1:为什么swappiness的默认值不是最佳的

    我们必须记得二十年前一个大的486只有32Mb的RAM。 当整个RAM可以在很小的一秒钟内移动到磁盘上时,就开发了交换algorithm。 即使是那个时候较慢的磁盘也是如此。 这就是为什么违约掉期政策如此激进。 内存是那些日子的瓶颈。 此后,RAM大小增加了1万倍以上,磁盘速度不到10倍。 这将瓶颈转移到了磁盘带宽上。

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

    Si等在有大量RAM的机器上的活动是致命的,因为这意味着系统正在为自己的RAM而战。 与RAM相比,会发生什么情况是磁盘,即使是大型存储也是太慢了。 积极的交换优先于内核磁盘caching而不是应用程序数据,是争取RAM最常见的来源。 由于操作系统将不得不释放每一个磁盘caching,交换提供的额外caching的生存时间太低,无论如何是有用的。 其结果是,您正在使用磁盘带宽来存储可能不会被使用的caching,并暂停您的程序等待si页面。 这意味着消耗大量的关键资源,而对应用程序没有多less好处。

    请注意响应的标题“有很多RAM的服务器上的很多交换活动”。 这不适用于偶尔出现si等机器的机器。 如果在操作系统中开发更智能的交换algorithm,将来可能不适用。

    编辑3:“冷”页面

    人们将交换algorithm浪漫化。 有人说“它占用了更less的RAM空间”,但这并不是内核所做的。 这个东西很难理解,swap是内核不知道什么是“冷页面”。 内核没有一个好的指标来判断这个页面在不久的将来会被使用还是可能被使用。 为了规避内核或多或less随机地将页面放入交换中,并且不需要的页面停留在那里。 该algorithm的问题是页面需要去交换,以知道它们是否是应用程序所需要的。 这意味着很多“热门”页面将进入交换。 与RAM的问题相比,磁盘太慢了。 这样做的结果是当交换开始时,所有应用程序都会随机暂停等待磁盘,这会影响延迟和吞吐量。

    我build立了我自己的基准,这是一个很实际的情况,很多应用程序体积相当常见。 从我的testing中,我发现当交换使用时吞吐量或延迟没有任何好处。 离得很远。 当交换开始时,它将吞吐量和延迟减慢至less一个数量级。

    我进一步了解这一点:我知道交换不是为了处理。 交换仅适用于紧急情况。 那些同时运行了太多应用程序的时刻,你会得到一个内存尖峰。 没有交换,这将导致内存不足的错误。 我认为交换使用是开发和生产团队的失败。 这只是一个超出我们在这里讨论的意见,而是我的想法。 当然,我的应用程序本身具有出色的内存pipe理。

    这不是你的问题的答案; 而只是额外的信息来帮助你做出明智的决定。

    如果你想知道什么进程具体使用多less交换,这里是一个小小的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创build用户空间/ tmp覆盖。

    我注意到当代理大量交换时,MySQL Cluster复制变慢或失败。 也许有些应用程序不介意,甚至可能从一些交换中受益,但数据库似乎真的受到了影响。 然而,我在论坛上看到的很多讨论都讨论了从具体的工作负载讨论中去掉语境化的交换。

    在DBA的世界中,似乎是这样的共识:“当你运行MySQL(或其他任何DBMS)时,你不希望在交换空间中看到任何I / O,这是常识。 innodb_buffer_pool_size在MySQL的情况下)是标准做法,以确保有足够的空闲内存,因此不需要交换。

    但是,如果你犯了一些错误或错误的计算,并发生交换? 它对性能有多大影响? 这正是我着手调查。 “

    我希望读者能find以下链接。

    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/