Linux:在可用内存不足时保持 GUI 响应

Linux:在可用内存不足时保持 GUI 响应

我刚刚遇到了这个问题(现在它已经自行解决了,但大约需要 5-10 分钟):几分钟前我担心这种情况可能会发生,但仍然相信 Linux 最佳地使用内存进行缓存,并在需要时释放它:https://www.binarytides.com/linux-command-check-memory-usage/

这里的问题是缓存和缓冲区列。第二行表明 4.6 GB 是可用的。这是第一行中的空闲内存加上缓冲区和缓存的内存量。

Linux 习惯于缓存大量内容以提高性能,以便在需要时可以释放和使用内存。

也许是这样,只是显然它不认为 GUI 是一个需要这种操作的重要过程,现在一个鼠标光标移动大约需要一分钟。一些键盘快捷键仍然工作正常,即更改键盘灯可以立即工作,但用于关闭当前屏幕上的 Firefox 的 Ctl-Q 不起作用(这是在我写的另一台笔记本电脑上,您可能已经猜到了)。

在我切换到 Firefox 并且可以在“冻结”之前打开几个页面之前的情况:可用内存 200Kb,缓冲区/缓存 9Gb,文档文件夹中的可用空间(如文件管理器中所示):3.4 Gb。该系统是 Linux Mint Live,toram使用swapoff.

现在大约 10 分钟后,GUI 再次恢复响应,我想问一些如何解决的问题:

  1. 让 Linux 在可用内存不足的情况下保持 GUI 响应?更广泛地保留(也通过主动释放)一定量的可用内存以允许快速启动新应用程序?
  2. 知道系统是否可以快速释放内存(对于人类来说立即)?
  3. 配置保留一些资源以允许切换到其他终端以“帮助”系统释放内存。

我刚刚读过一个一般性问题(https://ux.stackexchange.com/questions/44684/why-dont-operating-systems-reserve-a-fixed-amount-of-resources-for-the-gui),但希望在特定系统(Linux)上有一些具体的答案。

添加:我启动视频播放器,当我切换到文件管理器时,系统很快再次响应变得非常慢。我开始认为系统可能无法释放所有缓存的 9Gb 内存。但也许 3.4Gb 可以,这意味着我在 Documents 文件夹中有 3.4Gb 可用空间用于系统启动到 RAM?

现在大约 30 分钟过去了,系统还没有恢复响应。我猜想视频播放器试图缓存要播放的文件并占用可用的内存。我尝试了 Ctl-Alt-Fn 没有效果,所以我会等待几个小时,也许系统会回复我。除了关掉我还能做什么?下次我想sync; echo 1 > /proc/sys/vm/drop_caches在系统内存不足时尝试。

添加2:

晚安休息后(大约 10 个小时),我发现系统恢复了响应。drop_caches没有多大帮助,所以我回到普通用户策略并重新启动网络浏览器,释放了大约 2Gb。

请帮助了解如何检查内核占用了多少内存以及内核可以释放哪些内存(显然我的系统确实恢复了响应,另一方面,删除缓存没有释放报告为缓存的 8Gb free) :

浏览器重新启动之前的输出free -m,它没有像在网络上找到的文章那样单独列出缓冲区/缓存,所以我也发布了(更详细的)输出cat /proc/meminfo

              total        used        free      shared  buff/cache   available
Mem:          15740        4508        2366        8453        8865        2474

MemTotal:       16118172 kB
MemFree:          528472 kB
MemAvailable:     475820 kB
Buffers:            1588 kB
Cached:          8939100 kB
SwapCached:            0 kB
Active:          6711540 kB
Inactive:        8440460 kB
Active(anon):    6621624 kB
Inactive(anon):  8402256 kB
Active(file):      89916 kB
Inactive(file):    38204 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:       6211412 kB
Mapped:          1534592 kB
Shmem:           8812568 kB
Slab:             203244 kB
SReclaimable:     106932 kB
SUnreclaim:        96312 kB
KernelStack:       18736 kB
PageTables:        93880 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8059084 kB
Committed_AS:   23933660 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     1761344 kB
DirectMap2M:    14704640 kB
DirectMap1G:     1048576 kB

相关内容