0

我在 AWS(m4.15xlargem5.12xlarge实例)上运行一些内存密集型服务,并注意到在某些条件下(通常在某个内存限制之后)分配额外内存所需的时间显着增加(高达 50 倍)。

当它发生时,htop在内核模式下显示 100%(红色),perf top看起来像这样:

  62.82%  [kernel]                                           [k] pageblock_pfn_to_page                                                              
  15.21%  [kernel]                                           [k] clear_page_c_e                                                                     
   5.78%  [kernel]                                           [k] get_pfnblock_flags_mask                                                            
   3.06%  [kernel]                                           [k] compaction_alloc                                                                   
   1.59%  [kernel]                                           [k] clear_huge_page                                                                    
   1.49%  [kernel]                                           [k] _raw_spin_lock                                                                     
   1.41%  [kernel]                                           [k] async_page_fault                                                                   
   1.29%  a.out                                              [.] memTest                                                                            
   0.99%  [kernel]                                           [k] get_page_from_freelist                                                             
   0.85%  [kernel]                                           [k] compact_zone                                                                       
   0.69%  [kernel]                                           [k] try_charge                                                                         
   0.51%  [kernel]                                           [k] error_entry                                                                        
...

在正常操作期间,它看起来像这样:

  66.29%  [kernel]                                           [k] clear_page_c_e
   7.05%  [kernel]                                           [k] clear_huge_page
   3.91%  a.out                                              [.] memTest
   3.66%  [kernel]                                           [k] _raw_spin_lock
   3.12%  [kernel]                                           [k] async_page_fault
   2.68%  [kernel]                                           [k] get_page_from_freelist
   1.93%  [kernel]                                           [k] _cond_resched
   1.49%  [kernel]                                           [k] try_charge
   1.12%  [kernel]                                           [k] error_entry
   1.01%  [kernel]                                           [k] retint_user
   0.93%  [kernel]                                           [k] handle_mm_fault
   0.77%  [kernel]                                           [k] mem_cgroup_try_charge
   0.67%  [kernel]                                           [k] pmd_pfn
   0.66%  [kernel]                                           [k] __rmqueue.isra.80
...

我不完全明白是什么触发了这种行为。有时它很难重现,但有时它一直在发生。

我有一个假设,这与 AWS 虚拟化有关(因此问题是间歇性的,我将其归因于“邻居”上发生的事情)(请参阅下面的更新)。我也无法在m5.metal机器上重现该问题。

我能够使用一个简单的 C 程序来重现该问题,该程序在循环中分配和初始化内存:

void memTest(long chunk, long total) {
    struct timeval prev, cur = {0,0}, lastProgress = {0,0};
    int i, j;
    int num = total / chunk;
    int p, progress = -1;
    uint8_t *data[num];

    get_now(&prev);

    for (i = 0; i < num; i++) {
        data[i] = malloc(chunk);
        for (j = 0; j < chunk; j += 4096) {
            data[i][j] = rand()%265;
        }

        get_now(&cur);
        add(delta(&prev, &cur));
        prev = cur;

        p = (i * 20) / num * 5;

        if (p != progress) {
            if (lastProgress.tv_sec == 0) {
                printf("%s: %02d%%\n", format(&cur), p);
            } else {
                double elapsed = delta(&lastProgress, &cur);
                printf("%s: %02d%% (%gms)\n", format(&cur), p, elapsed);
            }
            lastProgress = cur;
            progress = p;
        }
    }
}
m5.12xlarge$ ./a.out --total 182714368000 --chunk 16777216
2019-03-27 05:03:22.805827: 00%
2019-03-27 05:03:25.035575: 05% (2229.75ms)
2019-03-27 05:03:27.244955: 10% (2209.38ms)
2019-03-27 05:03:29.458160: 15% (2213.2ms)
2019-03-27 05:03:31.665313: 20% (2207.15ms)
2019-03-27 05:03:33.871949: 25% (2206.64ms)
2019-03-27 05:03:36.075955: 30% (2204.01ms)
2019-03-27 05:03:38.284512: 35% (2208.56ms)
2019-03-27 05:03:40.489039: 40% (2204.53ms)
2019-03-27 05:03:42.697444: 45% (2208.41ms)
2019-03-27 05:03:44.902268: 50% (2204.82ms)
2019-03-27 05:03:47.110703: 55% (2208.43ms)
2019-03-27 05:03:49.315001: 60% (2204.3ms)
2019-03-27 05:03:51.523370: 65% (2208.37ms)
2019-03-27 05:03:53.728535: 70% (2205.16ms)
2019-03-27 05:03:55.936081: 75% (2207.55ms)
2019-03-27 05:03:58.141149: 80% (2205.07ms)
2019-03-27 05:04:00.349740: 85% (2208.59ms)
2019-03-27 05:04:02.553894: 90% (2204.15ms)
2019-03-27 05:04:04.762675: 95% (2208.78ms)
2019-03-27 05:04:41.470692: 100% (36708ms) .  <---

这次我只能在接近内存限制的情况下解决问题,但即使在 20Gb(可用 186Gb 中)也能解决问题。

如果有人可以对正在发生的事情以及如何摆脱这种影响进行遮掩,我将不胜感激。

更新:

我已经更多地解决了这个问题,目前指责透明大页面支持 (THP) 恰好被启用 ( always) onm5.12xlarge和禁用 ( madvise) on m5.metal。在切换机器上的设置后,我能够解决问题m5.metal并且问题消失了m5.12xlarge

4

1 回答 1

3

正如更新部分中所建议的,该问题似乎是由透明大页面 ( THP ) 支持引起的。MongoDB和其他一些链接链接和建议禁用它已经发现了问题。

关于如何在 stackoverflow 和 stackexchange 上禁用 THP 有很多问题。例如:

于 2019-03-27T17:45:34.123 回答