linux - 即使在内存压力下，如何将可执行代码保留在内存中？在 Linux 中

标签 linux memory memory-management linux-kernel memory-pressure

这里的目标是在内存压力期间，在 Linux 中将每个正在运行的进程的可执行代码保留在内存中。
在 Linux 中，我能够立即(1 秒)造成高内存压力并通过以下方式触发 OOM-killer stress --vm-bytes $(awk '/MemAvailable/{printf "%d\n", $2 + 4000;}' < /proc/meminfo)k --vm-keep -m 4 --timeout 10s(来自 here 的代码) Qubes OS R4.0 Fedora 28 AppVM 内的最大 RAM 为 24000MB。 EDIT4:也许相关，但我忘了提及，我没有启用交换(即未设置 CONFIG_SWAP)

dmesg 报告:

[  867.746593] Mem-Info:
[  867.746607] active_anon:1390927 inactive_anon:4670 isolated_anon:0
                active_file:94 inactive_file:72 isolated_file:0
                unevictable:13868 dirty:0 writeback:0 unstable:0
                slab_reclaimable:5906 slab_unreclaimable:12919
                mapped:1335 shmem:4805 pagetables:5126 bounce:0
                free:40680 free_pcp:978 free_cma:0

有趣的部分是 active_file:94 inactive_file:72，它们以千字节为单位并且非常低。

这里的问题是，在内存压力期间，可执行代码正在从磁盘重新读取，导致磁盘抖动，从而导致 frozen OS 。 (但在上述情况下，它只发生不到 1 秒)

我在内核 mm/vmscan.c : 中看到一个有趣的代码

        if (page_referenced(page, 0, sc->target_mem_cgroup,
                            &vm_flags)) {
                nr_rotated += hpage_nr_pages(page);
                /*
                 * Identify referenced, file-backed active pages and
                 * give them one more trip around the active list. So
                 * that executable code get better chances to stay in
                 * memory under moderate memory pressure.  Anon pages
                 * are not likely to be evicted by use-once streaming
                 * IO, plus JVM can create lots of anon VM_EXEC pages,
                 * so we ignore them here.
                 */
                if ((vm_flags & VM_EXEC) && page_is_file_cache(page)) {
                        list_add(&page->lru, &l_active);
                        continue;
                }
        }

我认为，如果有人可以指出如何更改它，以便我们将其改为 give them one more trip around the active list 而不是 give them infinite trips around the active list ，那么应该完成工作。或者也许还有其他方法？

我可以修补和测试自定义内核。我只是不知道如何更改代码以始终将事件的可执行代码保留在内存中(我相信这实际上可以避免磁盘抖动)。

编辑:这是我到目前为止所做的工作(应用在内核 4.18.5 之上):

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 32699b2..7636498 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -208,7 +208,7 @@ enum lru_list {

 #define for_each_lru(lru) for (lru = 0; lru < NR_LRU_LISTS; lru++)

-#define for_each_evictable_lru(lru) for (lru = 0; lru <= LRU_ACTIVE_FILE; lru++)
+#define for_each_evictable_lru(lru) for (lru = 0; lru <= LRU_INACTIVE_FILE; lru++)

 static inline int is_file_lru(enum lru_list lru)
 {
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 03822f8..1f3ffb5 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2234,7 +2234,7 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,

    anon  = lruvec_lru_size(lruvec, LRU_ACTIVE_ANON, MAX_NR_ZONES) +
        lruvec_lru_size(lruvec, LRU_INACTIVE_ANON, MAX_NR_ZONES);
-   file  = lruvec_lru_size(lruvec, LRU_ACTIVE_FILE, MAX_NR_ZONES) +
+   file  = //lruvec_lru_size(lruvec, LRU_ACTIVE_FILE, MAX_NR_ZONES) +
        lruvec_lru_size(lruvec, LRU_INACTIVE_FILE, MAX_NR_ZONES);

    spin_lock_irq(&pgdat->lru_lock);
@@ -2345,7 +2345,7 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc
             sc->priority == DEF_PRIORITY);

    blk_start_plug(&plug);
-   while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
+   while (nr[LRU_INACTIVE_ANON] || //nr[LRU_ACTIVE_FILE] ||
                    nr[LRU_INACTIVE_FILE]) {
        unsigned long nr_anon, nr_file, percentage;
        unsigned long nr_scanned;
@@ -2372,7 +2372,8 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc
         * stop reclaiming one LRU and reduce the amount scanning
         * proportional to the original scan target.
         */
-       nr_file = nr[LRU_INACTIVE_FILE] + nr[LRU_ACTIVE_FILE];
+       nr_file = nr[LRU_INACTIVE_FILE] //+ nr[LRU_ACTIVE_FILE]
+           ;
        nr_anon = nr[LRU_INACTIVE_ANON] + nr[LRU_ACTIVE_ANON];

        /*
@@ -2391,7 +2392,8 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc
            percentage = nr_anon * 100 / scan_target;
        } else {
            unsigned long scan_target = targets[LRU_INACTIVE_FILE] +
-                       targets[LRU_ACTIVE_FILE] + 1;
+                       //targets[LRU_ACTIVE_FILE] + 
+                       1;
            lru = LRU_FILE;
            percentage = nr_file * 100 / scan_target;
        }

在 github 上也看到了 here，因为在上面的代码中，制表符变成了空格! ( mirror1 , mirror2 )
我已经测试了上面的补丁(现在在 4000MB 最大 RAM 上，是的，比以前少了 20G!)即使使用已知的 Firefox 编译会导致磁盘将操作系统永久卡住，并且它不再发生(oom-killer 是几乎立即杀死有问题的进程)，同样使用上面的 stress 命令现在产生:

[  745.830511] Mem-Info:
[  745.830521] active_anon:855546 inactive_anon:20453 isolated_anon:0
                active_file:26925 inactive_file:76 isolated_file:0
                unevictable:10652 dirty:0 writeback:0 unstable:0
                slab_reclaimable:26975 slab_unreclaimable:13525
                mapped:24238 shmem:20456 pagetables:4028 bounce:0
                free:14935 free_pcp:177 free_cma:0

这是 active_file:26925 inactive_file:76 ，将近 27 兆的事件文件...
所以，我不知道这有多好。我是否在内存中保留所有事件文件而不仅仅是可执行文件？在 Firefox 编译期间，我有 500meg 的 Active(file)(EDIT2: 但这是根据:cat /proc/meminfo|grep -F -- 'Active(file)' 显示的值与 dmesg 中的上述 active_file: 不同!!!)这让我怀疑它只是 exes/库...
也许有人可以建议如何只保留可执行代码？(如果这不是已经发生的事情)
想法？

EDIT3: 使用上述补丁，似乎有必要(定期？)运行 sudo sysctl vm.drop_caches=1 以释放一些陈旧的内存(？)，这样如果我在 firefox 编译后调用 stress，我会得到: active_file:142281 inactive_file:0 isolated_file:0 (142megs) 然后删除文件缓存(另一种方式: echo 1|sudo tee /proc/sys/vm/drop_caches )然后再次运行 stress ，我得到: active_file:22233 inactive_file:160 isolated_file:0 (22megs) - 我不确定......

没有上述补丁的结果:here
使用上述补丁的结果:here

最佳答案

警告:如果您启用了交换，请不要使用此补丁，因为两个用户 reported更糟糕的影响。我只在内核中禁用了交换的情况下测试了这个补丁! (即未设置 CONFIG_SWAP)

在另行通知(或有人提出更好的方法)之前，我正在使用(对我来说它有效)以下 patch为了避免在即将运行内存不足时出现任何磁盘抖动/操作系统卡住，因此 OOM-killer 会尽快触发(最多 1 秒):

revision 3
preliminary patch to avoid disk thrashing (constant reading) under memory pressure before OOM-killer triggers
more info: https://gist.github.com/constantoverride/84eba764f487049ed642eb2111a20830

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 32699b2..7636498 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -208,7 +208,7 @@ enum lru_list {

 #define for_each_lru(lru) for (lru = 0; lru < NR_LRU_LISTS; lru++)

-#define for_each_evictable_lru(lru) for (lru = 0; lru <= LRU_ACTIVE_FILE; lru++)
+#define for_each_evictable_lru(lru) for (lru = 0; lru <= LRU_INACTIVE_FILE; lru++)

 static inline int is_file_lru(enum lru_list lru)
 {
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 03822f8..1f3ffb5 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2086,9 +2086,9 @@ static unsigned long shrink_list(enum lr
                 struct scan_control *sc)
 {
    if (is_active_lru(lru)) {
-       if (inactive_list_is_low(lruvec, is_file_lru(lru),
-                    memcg, sc, true))
-           shrink_active_list(nr_to_scan, lruvec, sc, lru);
+       //if (inactive_list_is_low(lruvec, is_file_lru(lru),
+       //           memcg, sc, true))
+       //  shrink_active_list(nr_to_scan, lruvec, sc, lru);
        return 0;
    }

@@ -2234,7 +2234,7 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,

    anon  = lruvec_lru_size(lruvec, LRU_ACTIVE_ANON, MAX_NR_ZONES) +
        lruvec_lru_size(lruvec, LRU_INACTIVE_ANON, MAX_NR_ZONES);
-   file  = lruvec_lru_size(lruvec, LRU_ACTIVE_FILE, MAX_NR_ZONES) +
+   file  = //lruvec_lru_size(lruvec, LRU_ACTIVE_FILE, MAX_NR_ZONES) +
        lruvec_lru_size(lruvec, LRU_INACTIVE_FILE, MAX_NR_ZONES);

    spin_lock_irq(&pgdat->lru_lock);
@@ -2345,7 +2345,7 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc
             sc->priority == DEF_PRIORITY);

    blk_start_plug(&plug);
-   while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
+   while (nr[LRU_INACTIVE_ANON] || //nr[LRU_ACTIVE_FILE] ||
                    nr[LRU_INACTIVE_FILE]) {
        unsigned long nr_anon, nr_file, percentage;
        unsigned long nr_scanned;
@@ -2372,7 +2372,8 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc
         * stop reclaiming one LRU and reduce the amount scanning
         * proportional to the original scan target.
         */
-       nr_file = nr[LRU_INACTIVE_FILE] + nr[LRU_ACTIVE_FILE];
+       nr_file = nr[LRU_INACTIVE_FILE] //+ nr[LRU_ACTIVE_FILE]
+           ;
        nr_anon = nr[LRU_INACTIVE_ANON] + nr[LRU_ACTIVE_ANON];

        /*
@@ -2391,7 +2392,8 @@ static void shrink_node_memcg(struct pglist_data *pgdat, struct mem_cgroup *memc
            percentage = nr_anon * 100 / scan_target;
        } else {
            unsigned long scan_target = targets[LRU_INACTIVE_FILE] +
-                       targets[LRU_ACTIVE_FILE] + 1;
+                       //targets[LRU_ACTIVE_FILE] + 
+                       1;
            lru = LRU_FILE;
            percentage = nr_file * 100 / scan_target;
        }
@@ -2409,10 +2411,12 @@ static void shrink_node_memcg(struct pgl
        nr[lru] = targets[lru] * (100 - percentage) / 100;
        nr[lru] -= min(nr[lru], nr_scanned);

+       if (LRU_FILE != lru) { //avoid this block for LRU_ACTIVE_FILE
        lru += LRU_ACTIVE;
        nr_scanned = targets[lru] - nr[lru];
        nr[lru] = targets[lru] * (100 - percentage) / 100;
        nr[lru] -= min(nr[lru], nr_scanned);
+       }

        scan_adjusted = true;
    }

不幸的是，上面将制表符转换为空格，所以如果你想要原始补丁，它是 here .

这个补丁所做的不是在内存压力下驱逐 Active(file) 页面，因此不会导致 kswapd0(但在 iotop 中可以看到) > 作为每个程序本身)在每次出现 context switch 时重新读取每个正在运行的进程的可执行页面为了让程序(继续)运行。因此，避免了大量的磁盘抖动，并且操作系统不会卡住成爬行。

以上内容已在 Qubes OS 4.0 的 dom0(Fedora 25) 和我正在使用的所有虚拟机 (Fedora 28) 中使用内核 4.18.5(现在测试 4.18.7)进行了测试。

对于 first version这个补丁，也可以正常工作(显然)，请参阅 EDIT 关于这是答案的问题。

更新:在具有 16G RAM(减去 512M 为集成显卡保留)且没有交换(在内核中也禁用)的 ArchLinux 笔记本电脑上使用此补丁一段时间后，我可以说系统与没有 le9d.patch(rev. 3)相比，内存可能会更快耗尽，因此如果没有补丁，OOM-killer 会触发 Xorg 或 chromium 或其他。因此，作为一种缓解措施，到目前为止，这似乎对我有用，我一直在运行 echo 1 >/proc/sys/vm/drop_caches 每当 Active(file)/proc/meminfo 中的数字超过 2G，即 2000000 KB(例如，通过以下代码获取 KB 数:grep 'Active(file):'/proc/meminfo|tr -d ''|cut -f2 - d:|sed 's/kB//') 并在之后使用 sleep 5 进行检查。但是最近为了在/tmp 中编译 firefox-hg ，它是 tmpfs 并且最终使用 12G 并确保它不会被 OOM 杀死，我一直在使用 500000 而不是 2000000 KB。这肯定比卡住整个系统(即没有 le9d.patch 时)要好，这在这个 firefox 编译案例中会发生。如果没有这个检查，Active(file) 不会超过 4G，但如果某些东西需要更多内存，这足以 OOM 杀死 Xorg，例如在这个 firefox 编译案例中，甚至只是通过复制很多 GB 时午夜指挥官(如果我没记错的话)。

关于linux - 即使在内存压力下，如何将可执行代码保留在内存中？在 Linux 中，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52067753/

上一篇：python - ctypes内存管理: how and when free the allocated resources?

下一篇：memory - 使用什么来查看 Spark 的内存使用情况(使用 YARN)？

相关文章：

linux - 计算bash中每个进程的CPU使用率%

替换大型 Pandas 数据框中的 NaN 值时遇到 Python 内存错误

c++ - 内存泄漏/管理建议(方法中的新数组)(c++)

linux - Shell——将 'od'命令的输出记录到一个变量中

linux - wait_event_interruptible 代码

linux - 使用 Bash 发送多个 SSH 命令

matlab - 我可以删除占位符变量以节省 Matlab 中的内存吗？

memory - 取消注册 M3 型号

c# - 如何在 C# 中分配超过 MaxInteger 字节的内存

iOS 7 应用程序因内存压力而终止

©2024 IT工具网  联系我们