Отношение OOM к vm.swappiness = 0 в новом ядре

Отношение OOM к vm.swappiness = 0 в новом ядре

Отношение OOM к vm.swappiness = 0 в новом ядре

По Ovais Тарика  Понимание для администраторов баз данных , MySQL  ядро , память , oom , swap , swappiness  8 комментариев

Недавно я участвовал в диагностике причин вызова OOM, который мог бы убить процесс сервера MySQL. Конечно, эти серверы в основном работали с MySQL. Таким образом, серверный процесс MySQL был с наибольшим объемом выделенной памяти.

Но странная вещь заключалась в том, что во всех случаях не было обнаружено ни одной операции свопинга, и в кеше страниц было достаточно страниц. По иронии судьбы все эти серверы были CentOS 6.4 с ядром версии 2.6.32-358. Другая распространенность заключалась в том, что для vm.swappiness было установлено значение 0. Это довольно стандартная практика, которая применяется практически на каждом сервере, на котором работает MySQL.

Заглядывая дальше, я понял, что в ядре 3.5-rc1 было внесено изменение, которое изменило поведение подкачки, когда «vm.swappiness = 0».

Ниже приведено описание коммита, который изменил поведение «vm.swappiness = 0» вместе с diff:

Shell

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

$ git show fe35004fbf9eaf67482b074a2e032abb9c89b1dd commit fe35004fbf9eaf67482b074a2e032abb9c89b1dd Author: Satoru Moriya <satoru.moriya@hds.com> Date: Tue May 29 15:06:47 2012 -0700   mm: avoid swapping out with swappiness==0   Sometimes we'd like to avoid swapping out anonymous memory. In particular, avoid swapping out pages of important process or process groups while there is a reasonable amount of pagecache on RAM so that we can satisfy our customers' requirements.   OTOH, we can control how aggressive the kernel will swap memory pages with /proc/sys/vm/swappiness for global and /sys/fs/cgroup/memory/memory.swappiness for each memcg.   But with current reclaim implementation, the kernel may swap out even if we set swappiness=0 and there is pagecache in RAM.   This patch changes the behavior with swappiness==0. If we set swappiness==0, the kernel does not swap out completely (for global reclaim until the amount of free pages and filebacked pages in a zone has been reduced to something very very small (nr_free + nr_filebacked < high watermark)).   Signed-off-by: Satoru Moriya <satoru.moriya@hds.com> Acked-by: Minchan Kim <minchan@kernel.org> Reviewed-by: Rik van Riel <riel@redhat.com> Acked-by: Jerome Marchand <jmarchan@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>   diff --git a/mm/vmscan.c b/mm/vmscan.c index 67a4fd4..ee97530 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1761,10 +1761,10 @@ static void get_scan_count(struct mem_cgroup_zone *mz, struct scan_control *sc, * proportional to the fraction of recently scanned pages on * each list that were recently referenced and in active use. */ - ap = (anon_prio + 1) * (reclaim_stat->recent_scanned[0] + 1); + ap = anon_prio * (reclaim_stat->recent_scanned[0] + 1); ap /= reclaim_stat->recent_rotated[0] + 1;   - fp = (file_prio + 1) * (reclaim_stat->recent_scanned[1] + 1); + fp = file_prio * (reclaim_stat->recent_scanned[1] + 1); fp /= reclaim_stat->recent_rotated[1] + 1; spin_unlock_irq(&mz->zone->lru_lock);   @@ -1777,7 +1777,7 @@ out: unsigned long scan; scan = zone_nr_lru_pages(mz, lru); - if (priority || noswap) { + if (priority || noswap || !vmscan_swappiness(mz, sc)) { scan >>= priority; if (!scan && force_scan) scan = SWAP_CLUSTER_MAX;

Это изменение было объединено с ядром RHEL 2.6.32-303:

Shell

1 2 3

* Mon Aug 27 2012 Jarod Wilson <jarod@redhat.com> [2.6.32-303.el6] ... - [mm] avoid swapping out with swappiness==0 (Satoru Moriya) [787885]

Это, очевидно, изменило наш взгляд на «vm.swappiness = 0». Ранее считалось, что установка этого параметра в 0 уменьшает тенденцию к обмену пользовательскими процессами, но не отключает ее полностью. Как таковой, он ожидал увидеть небольшой обмен вместо ООМ.

Это относится ко всем ядрам RHEL / CentOS> 2.6.32-303 и к другим дистрибутивам, которые предоставляют более новые ядра, такие как Debian и Ubuntu. Или любой другой дистрибутив, в котором это изменение было перенесено, как в RHEL.

Позвольте мне поделиться с вами статистикой, связанной с зонами памяти, которые были зарегистрированы в системном журнале одного из событий OOM.

Shell

1 2 3 4 5 6 7 8 9 10 11 12

Mar 11 11:01:45 db01 kernel: Node 0 DMA: 4*4kB 2*8kB 2*16kB 0*32kB 2*64kB 1*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15680kB Mar 11 11:01:45 db01 kernel: Node 0 DMA32: 6*4kB 22*8kB 444*16kB 374*32kB 129*64kB 26*128kB 15*256kB 17*512kB 2*1024kB 0*2048kB 0*4096kB = 45448kB Mar 11 11:01:45 db01 kernel: Node 0 Normal: 825*4kB 1012*8kB 382*16kB 169*32kB 69*64kB 74*128kB 14*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 42436kB Mar 11 11:01:45 db01 kernel: 452844 total pagecache pages Mar 11 11:01:45 db01 kernel: 0 pages in swap cache Mar 11 11:01:45 db01 kernel: Swap cache stats: add 0, delete 0, find 0/0 Mar 11 11:01:45 db01 kernel: Free swap  = 4128760kB Mar 11 11:01:45 db01 kernel: Total swap = 4128760kB ... Mar 11 11:01:45 db01 kernel: Node 0 DMA free:15680kB min:124kB low:152kB high:184kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15284kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes Mar 11 11:01:45 db01 kernel: Node 0 DMA32 free:45448kB min:25140kB low:31424kB high:37708kB active_anon:1741812kB inactive_anon:520348kB active_file:4792kB inactive_file:462576kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3072160kB mlocked:0kB dirty:386328kB writeback:76268kB mapped:936kB shmem:0kB slab_reclaimable:20420kB slab_unreclaimable:6964kB kernel_stack:0kB pagetables:572kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:142592 all_unreclaimable? no Mar 11 11:01:45 db01 kernel: Node 0 Normal free:42436kB min:42316kB low:52892kB high:63472kB active_anon:3041852kB inactive_anon:643624kB active_file:340156kB inactive_file:1003512kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:5171200kB mlocked:0kB dirty:979444kB writeback:22040kB mapped:15616kB shmem:180kB slab_reclaimable:41052kB slab_unreclaimable:35996kB kernel_stack:2720kB pagetables:19912kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:31552 all_unreclaimable? no

Как можно видеть, объем свободной памяти и объем памяти в кеше страниц был больше, чем верхний водяной знак, что предотвращало любую операцию подкачки. И все же из-за ненужного давления памяти вызывался OOM, который убивал процесс сервера MySQL.

MySQL, получающий OOM'ed, является плохим по многим причинам и может иметь нежелательное влияние, например, привести к потере незафиксированных транзакций или транзакций, еще не сброшенных в журнал из-за innodb_flush_log_at_trx_commit = 0, или гораздо более сильному воздействию из-за холодных кэшей при перезапуске.

Я предпочитаю старое поведение vm.swappiness, и теперь я установил для него значение «1». Установка vm.swappiness = 0 будет означать, что теперь вам нужно будет гораздо точнее настраивать размер различных глобальных и сессионных буферов.