Linux:如何显式取消所有可能的交换?


59

我发布的东西占用了很多内存,现在一切都滞后了很多。我想所有应用程序的内存都已交换,以便为内存密集型进程释放一些空间,现在访问时一切都缓慢返回RAM。

有没有办法将所有可能的内容从交换显式移回RAM?也许不是全部,而只是某些特定的过程数据?

Answers:


59

我建议允许在实际使用的事物中进行常规的Linux内存控制交换,因为它们已经被使用。

我唯一能想到的就是先关闭交换,然后再重新打开

sudo swapoff -a
sudo swapon -a

假设您有足够的备用物理内存来包含交换中的所有内容...


4
它的工作,虽然很慢:)谢谢!但我仍然相信有一个更优雅的解决方案:)
kolypto 2010年

7
谨慎使用此解决方案,它将强制将所有内容从交换中移出……如果它不适合物理内存,则内核将启动致命的OOM杀手。我不知道有什么不错的“尝试将所有内容移至RAM,但如果不可能的话,会优雅地失败”命令。

1
我尝试过,发现它的工作非常缓慢。因此,有可能监视可用的RAM并swapoff在内存不足时杀死它:在这种情况下,交换空间将保持功能:)
kolypto 2010年

2
我不确定取消掉换是否会真正停止操作。取决于其实现方式。
道格拉斯·里德

2
似乎swapoff命令执行的操作类似于“不允许交换新写操作”,而其他任何正在运行的进程(正在/正在使用交换)仍可以“释放交换”。这可能就是为什么它运行如此缓慢的原因。似乎并没有引起另一个人所说的OOM(我正在使用Ubuntu Bionic)-可能只有在“其他(或现有)进程开始使用新内存”(即真正的OOM)的情况下才会出现。因此,总的来说,掉期/交换是一个很好的解决方案。温柔/稳定。这假定您不使用进程来启动更多的内存(或增加正在运行的进程的消耗)。
Roel Van de Paar,

12

您可以将其回音为0到100之间的某个数字进行调整/proc/sys/vm/swappiness

该控件用于定义内核将交换内存页面的积极程度。较高的值将增加攻击性,较低的值将减少交换量。值0指示内核在空闲和文件支持的页面数量小于区域中的高水位标记之前不要启动交换。

默认值为60。


13
不要直接使用/ proc / sys,而应使用sysctl命令。在这种情况下为sysctl vm.swappiness=x
朱利诺

7
我认为即使是零可交换性也不会导致已经被交换的页面被显式地带入主存储器?
道格拉斯·里德

1
@道格拉斯是对的。vm.swappiness将主要控制在需要内存时是否移动事物进行交换或减少高速缓存和缓冲区的数量的决定。
朱利诺

@Juliano,为什么不应该使用/ proc / sys?
詹姆斯

@James因为/ proc / sys是用于更改和查询内核配置的较低级接口(它是“实现细节”)。Linux sysctl为用户交互提供了更高级别的命令。最终结果是相同的,但是通常首选高层接口,以便用户直接进行交互。Kinda喜欢通过短路点火线(较低的水平)而不是仅仅转动钥匙(较高的水平)来启动发动机。
朱利诺2015年

5

Linux在管理内存方面做得很好,您不应该阻挠它。vm.swappiness设置(前面已经提到)没有问题。您更有可能在其他任何方式上遇到奇怪的问题。

您是从什么时候开始推出的,如此耗费内存?可以调整吗?如果没有它自己的内存限制指令,您也可以查看ulimit。


就我而言convert -density 200 file.pdf jpegs/file.jpg。由于某种原因,它占用了大量内存,但是您是对的:可以对其进行调整。无论如何,任何应用程序都可能出现这种情况:)
kolypto 2010年

1
我同意这个答案-您可能应该在机器上保留正常的操作以交换实际需要的东西。
Douglas

convert-limit参数来控制其内存与磁盘使用情况,因此您应该仔细阅读它们。设置-limit memory 512MB或类似条件会很好。指定一个显式的MAGICK_TEMPORARY_PATH并在执行完命令后清理它也可能会很好。
slacy

3

如果您有所有应用程序可用的内存,则可以将swappiness设置为0,这样就不会发生交换。例如,qemu-kvm是要被VMM换出的大目标,因为qemu-kvm在大多数情况下“似乎”处于空闲状态。我已经看到qemu-kvm内存的多达80%的内存被写入交换。在qemu-kvm中运行的VM几乎没有响应,因为它们的交换用完了(尽管来宾不知道这种情况正在发生)。来宾VM会认为它的性能最出色,尽管实际上它正在拖累。当我一堆VM“醒来”并开始工作时,即使在具有足够快速内存和磁盘的企业级硬件上,它也可能使平均负载达到30级以上。我想这是开箱即用的qemu-kvm设计中的失败。

希望这对某人有帮助。


恐怕这不太准确。
Marc.2377

2

我建议不要尝试超越内核中的VM子系统。您实际上没有足够的信息来做出更好的决策,这是极不可能的。而且,如果您以某种方式强迫它做错了事,那么最终只会使事情变得更慢。


9
在某些情况下,我想做OP想要做的事情。如果我不小心让某个进程运行暴乱并占用了我所有的RAM +交换,那么我可以在每次切换应用程序时等待15秒钟,以使它的内存不再出现交换问题,或者只是强制它并使一切正常运行。
2014年


1

这个问题复制我的一些答案。

使您知道交换可调参数的工作方式。这是通过告诉VM子系统在映射到进程页表的内存的百分比+ swappiness值大于100时查找要交换的页来实现的。因此,设置为60会使系统开始从进程页表中调出陈旧的页当它使用系统内存的40%以上时。如果要允许程序使用更多内存以牺牲缓存为代价,则需要降低swappiness值。


我不认为程序内存与缓存是这里的问题-我认为它是应用程序内存与未使用的内存。而且我不认为交换会影响这一点。
Douglas Leeder '02

0

该过程仍在运行吗?打开一个终端,看看是否可以发现已启动的进程。(ps aux | grep进程名可能会使它更容易一些)如果它们仍在运行,请使用kill -9 PID将其杀死。小心要杀死的东西。如果您不知道该过程是什么,请不要杀死它!另外,发布free -m的输出,以便我们可以查看您是否实际上仍在使用大量交换。

如果一切仍在缓慢进行,则您启动的任何内容可能仍在运行。除非您真的知道自己在做什么或喜欢生活在边缘,否则我永远不会关闭交换。=)


0

我相信没有任何真正好的方法来强制Linux将数据从磁盘交换到内存。如果交换/交换是可行的解决方案,但它很脏,很容易使您的系统不稳定。对于交换中的数据多于可用内存的情况,很难想象Linux可以采用哪种有效的策略来决定哪些数据块移入内存以及哪些数据保留在磁盘上。

简介:请让Linux以正常方式逐渐恢复其性能。它的VM子系统的组织方式使其努力并不断地达到某种理想的平衡状态。


-2

清空缓冲区缓存

如果您想清空它们,可以使用此命令链。

$ free && sync && echo 3 > /proc/sys/vm/drop_caches && free

             total       used       free     shared    buffers     cached
Mem:       1018916     980832      38084          0      46924     355764
-/+ buffers/cache:     578144     440772
Swap:      2064376        128    2064248
             total       used       free     shared    buffers     cached
Mem:       1018916     685008     333908          0        224     108252
-/+ buffers/cache:     576532     442384
Swap:      2064376        128    2064248

您可以通过将上面的数字参数更改为Linux内核发出丢弃缓存项各个方面的信号。

注意:清理内存中不必要的内容(内核2.6.16或更高版本)。始终确保首先运行同步,以将有用的内容刷新到磁盘上!!!

  • 要释放页面缓存:

    $ echo 1 > /proc/sys/vm/drop_caches
    
  • 要释放牙齿和索引节点:

    $ echo 2 > /proc/sys/vm/drop_caches
    
  • 要释放页面缓存,牙科和索引节点:

    $ echo 3 > /proc/sys/vm/drop_caches
    

以上内容旨在作为root用户运行。如果您尝试使用sudo进行操作,则需要将语法稍作更改,如下所示:

$ sudo sh -c 'echo 1 >/proc/sys/vm/drop_caches'
$ sudo sh -c 'echo 2 >/proc/sys/vm/drop_caches'
$ sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.