Вопрос: Rsync инициировал убийцу Linux OOM в одном файле объемом 50 ГБ


У меня есть файл размером 50 ГБ на server_A, и я копирую его на server_B. я бегу

server_A$ rsync --partial --progress --inplace --append-verify 50GB_file root@server_B:50GB_file

Server_B имеет 32 ГБ оперативной памяти с заменой 2 ГБ. Он в основном простаивает и должен иметь много свободной оперативной памяти. В нем много дискового пространства. При 32 ГБ передача прерывается, так как удаленная сторона закрыла соединение.

Сервер_B теперь отключен от сети. Мы просим ЦОД перезагрузить его. Когда я смотрю на журнал ядра до того, как он разбился, я вижу, что он использует 0 байтов swap, а в списке процессов используется очень мало памяти (процесс rsync был указан как использующий 600 КБ ОЗУ), но oom_killer был и последнее, что происходит в журнале, - это то, где он убивает процесс чтения ядра metalog.

Это ядро ​​3.2.59, 32-битное (так что ни один процесс не может отображать более 4 ГБ).

Это почти так, как если бы Linux уделял больше внимания кешированию, чем работающим демонам. Что дает?? И как я могу остановить его снова?

Вот вывод oom_killer:

Sep 23 02:04:16 [kernel] [1772321.850644] clamd invoked oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0, oom_score_adj=0
Sep 23 02:04:16 [kernel] [1772321.850649] Pid: 21832, comm: clamd Tainted: G         C   3.2.59 #21
Sep 23 02:04:16 [kernel] [1772321.850651] Call Trace:
Sep 23 02:04:16 [kernel] [1772321.850659]  [<c01739ac>] ? dump_header+0x4d/0x160
Sep 23 02:04:16 [kernel] [1772321.850662]  [<c0173bf3>] ? oom_kill_process+0x2e/0x20e
Sep 23 02:04:16 [kernel] [1772321.850665]  [<c0173ff8>] ? out_of_memory+0x225/0x283
Sep 23 02:04:16 [kernel] [1772321.850668]  [<c0176438>] ? __alloc_pages_nodemask+0x446/0x4f4
Sep 23 02:04:16 [kernel] [1772321.850672]  [<c0126525>] ? pte_alloc_one+0x14/0x2f
Sep 23 02:04:16 [kernel] [1772321.850675]  [<c0185578>] ? __pte_alloc+0x16/0xc0
Sep 23 02:04:16 [kernel] [1772321.850678]  [<c0189e74>] ? vma_merge+0x18d/0x1cc
Sep 23 02:04:16 [kernel] [1772321.850681]  [<c01856fa>] ? handle_mm_fault+0xd8/0x15d
Sep 23 02:04:16 [kernel] [1772321.850685]  [<c012305a>] ? do_page_fault+0x20e/0x361
Sep 23 02:04:16 [kernel] [1772321.850688]  [<c018a9c4>] ? sys_mmap_pgoff+0xa2/0xc9
Sep 23 02:04:16 [kernel] [1772321.850690]  [<c0122e4c>] ? vmalloc_fault+0x237/0x237
Sep 23 02:04:16 [kernel] [1772321.850694]  [<c08ba7e6>] ? error_code+0x5a/0x60
Sep 23 02:04:16 [kernel] [1772321.850697]  [<c08b0000>] ? cpuid4_cache_lookup_regs+0x372/0x3b2
Sep 23 02:04:16 [kernel] [1772321.850700]  [<c0122e4c>] ? vmalloc_fault+0x237/0x237
Sep 23 02:04:16 [kernel] [1772321.850701] Mem-Info:
Sep 23 02:04:16 [kernel] [1772321.850703] DMA per-cpu:
Sep 23 02:04:16 [kernel] [1772321.850704] CPU    0: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850706] CPU    1: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850707] CPU    2: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850709] CPU    3: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850711] CPU    4: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850713] CPU    5: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850714] CPU    6: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850716] CPU    7: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850718] Normal per-cpu:
Sep 23 02:04:16 [kernel] [1772321.850719] CPU    0: hi:  186, btch:  31 usd:  70
Sep 23 02:04:16 [kernel] [1772321.850721] CPU    1: hi:  186, btch:  31 usd: 116
Sep 23 02:04:16 [kernel] [1772321.850723] CPU    2: hi:  186, btch:  31 usd: 131
Sep 23 02:04:16 [kernel] [1772321.850724] CPU    3: hi:  186, btch:  31 usd:  76
Sep 23 02:04:16 [kernel] [1772321.850726] CPU    4: hi:  186, btch:  31 usd:  29
Sep 23 02:04:16 [kernel] [1772321.850728] CPU    5: hi:  186, btch:  31 usd:  61
Sep 23 02:04:16 [kernel] [1772321.850731] CPU    7: hi:  186, btch:  31 usd:  17
Sep 23 02:04:16 [kernel] [1772321.850733] HighMem per-cpu:
Sep 23 02:04:16 [kernel] [1772321.850734] CPU    0: hi:  186, btch:  31 usd:   2
Sep 23 02:04:16 [kernel] [1772321.850736] CPU    1: hi:  186, btch:  31 usd:  69
Sep 23 02:04:16 [kernel] [1772321.850738] CPU    2: hi:  186, btch:  31 usd:  25
Sep 23 02:04:16 [kernel] [1772321.850739] CPU    3: hi:  186, btch:  31 usd:  27
Sep 23 02:04:16 [kernel] [1772321.850741] CPU    4: hi:  186, btch:  31 usd:   7
Sep 23 02:04:16 [kernel] [1772321.850743] CPU    5: hi:  186, btch:  31 usd: 188
Sep 23 02:04:16 [kernel] [1772321.850744] CPU    6: hi:  186, btch:  31 usd:  25
Sep 23 02:04:16 [kernel] [1772321.850746] CPU    7: hi:  186, btch:  31 usd: 158
Sep 23 02:04:16 [kernel] [1772321.850750] active_anon:117913 inactive_anon:9942 isolated_anon:0
Sep 23 02:04:16 [kernel] [1772321.850751]  active_file:106466 inactive_file:7784521 isolated_file:0
Sep 23 02:04:16 [kernel] [1772321.850752]  unevictable:40 dirty:0 writeback:61 unstable:0
Sep 23 02:04:16 [kernel] [1772321.850753]  free:143494 slab_reclaimable:128312 slab_unreclaimable:4089
Sep 23 02:04:16 [kernel] [1772321.850754]  mapped:6706 shmem:308 pagetables:915 bounce:0
Sep 23 02:04:16 [kernel] [1772321.850759] DMA free:3624kB min:140kB low:172kB high:208kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolate
d(file):0kB present:15808kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:240kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tm
p:0kB pages_scanned:0 all_unreclaimable? yes
Sep 23 02:04:16 [kernel] [1772321.850763] lowmem_reserve[]: 0 869 32487 32487
Sep 23 02:04:16 [kernel] [1772321.850770] Normal free:8056kB min:8048kB low:10060kB high:12072kB active_anon:0kB inactive_anon:0kB active_file:248kB inactive_file:388kB unevictable:0kB isolated(anon)
:0kB isolated(file):0kB present:890008kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:513008kB slab_unreclaimable:16356kB kernel_stack:1888kB pagetables:3660kB unstable:0
kB bounce:0kB writeback_tmp:0kB pages_scanned:1015 all_unreclaimable? yes
Sep 23 02:04:16 [kernel] [1772321.850774] lowmem_reserve[]: 0 0 252949 252949
Sep 23 02:04:16 [kernel] [1772321.850785] lowmem_reserve[]: 0 0 0 0
Sep 23 02:04:16 [kernel] [1772321.850788] DMA: 0*4kB 7*8kB 3*16kB 6*32kB 4*64kB 6*128kB 5*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB = 3624kB
Sep 23 02:04:16 [kernel] [1772321.850795] Normal: 830*4kB 80*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 8056kB
Sep 23 02:04:16 [kernel] [1772321.850802] HighMem: 13*4kB 14*8kB 2*16kB 2*32kB 0*64kB 0*128kB 2*256kB 2*512kB 3*1024kB 0*2048kB 136*4096kB = 561924kB
Sep 23 02:04:16 [kernel] [1772321.850809] 7891360 total pagecache pages
Sep 23 02:04:16 [kernel] [1772321.850811] 0 pages in swap cache
Sep 23 02:04:16 [kernel] [1772321.850812] Swap cache stats: add 0, delete 0, find 0/0
Sep 23 02:04:16 [kernel] [1772321.850814] Free swap  = 1959892kB
Sep 23 02:04:16 [kernel] [1772321.850815] Total swap = 1959892kB
Sep 23 02:04:16 [kernel] [1772321.949081] 8650736 pages RAM
Sep 23 02:04:16 [kernel] [1772321.949084] 8422402 pages HighMem
Sep 23 02:04:16 [kernel] [1772321.949085] 349626 pages reserved
Sep 23 02:04:16 [kernel] [1772321.949086] 7885006 pages shared
Sep 23 02:04:16 [kernel] [1772321.949087] 316864 pages non-shared
Sep 23 02:04:16 [kernel] [1772321.949089] [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
            (rest of process list omitted)
Sep 23 02:04:16 [kernel] [1772321.949656] [14579]     0 14579      579      171   5       0             0 rsync
Sep 23 02:04:16 [kernel] [1772321.949662] [14580]     0 14580      677      215   5       0             0 rsync
Sep 23 02:04:16 [kernel] [1772321.949669] [21832]   113 21832    42469    37403   0       0             0 clamd
Sep 23 02:04:16 [kernel] [1772321.949674] Out of memory: Kill process 21832 (clamd) score 4 or sacrifice child
Sep 23 02:04:16 [kernel] [1772321.949679] Killed process 21832 (clamd) total-vm:169876kB, anon-rss:146900kB, file-rss:2712kB

Вот «верхний» вывод после повторения моей команды rsync как пользователя без полномочий root:

top - 03:05:55 up  8:43,  2 users,  load average: 0.04, 0.08, 0.09
Tasks: 224 total,   1 running, 223 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0% us,  0.0% sy,  0.0% ni, 99.9% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:  33204440k total, 32688600k used,   515840k free,   108124k buffers
Swap:  1959892k total,        0k used,  1959892k free, 31648080k cached

Вот параметры sysctl vm:

# sysctl -a | grep '^vm'
vm.overcommit_memory = 0
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.oom_dump_tasks = 1
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 1
vm.dirty_background_bytes = 0
vm.dirty_ratio = 0
vm.dirty_bytes = 15728640
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.nr_pdflush_threads = 0
vm.swappiness = 60
vm.lowmem_reserve_ratio = 256   32      32
vm.drop_caches = 0
vm.min_free_kbytes = 8192
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65530
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.stat_interval = 1
vm.mmap_min_addr = 4096
vm.vdso_enabled = 2
vm.highmem_is_dirtyable = 0
vm.scan_unevictable_pages = 0

65
2017-09-24 06:36


Источник


Я не эксперт в чтении сообщений о сбоях ядра, но я не вижу никаких признаков того, что B использует 32 ГБ ядра. Прежде чем мы приступим к предположению, что это так, можете ли вы подтвердить, что это в настоящее время? Потому что существует большая разница между памятью, изнуряющей коробку с 32 ГБ ядра, и одну с 4 ГБ. - MadHatter
Обновлено с выходом Top. Это происходит после запуска этой же команды rsync в качестве пользователя без полномочий root. Практически все, кроме 1 ГБ, используются для кеша прямо сейчас. - dataless
Благодарю. Как я уже сказал, я не эксперт, но, похоже, стоит проверить. - MadHatter
вы также должны убедиться, что ваше ядро ​​разрешает замену (т. е. замена не отключена) (и вы должны выделить большую часть дискового пространства, скажем, 16 ГБ или даже 32 ГБ). Некоторые странные люди в сети рекомендуют поменять местами, что очень неправильно. - Olivier Dulac
@OlivierDulac, на какой настройке вы ссылаетесь? поддержка swap скомпилирована или мы не сможем смонтировать swap, а «swappiness» - 60. Что касается размера свопинга, разве это не просто ухудшит проблему, на 32-битном ядре? Ответ показывает, что структура данных ядра была тем, что нас убило. Мы не запускаем 32-гигабайтные пользовательские процессы, мы просто хотим, чтобы много бара для кеша диска для производительности. - dataless


Ответы:


Итак, давайте прочитаем вывод oom-killer и посмотрим, что можно узнать оттуда.

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

[kernel] [1772321.850644] clamd invoked oom-killer: gfp_mask = 0x84d0, order = 0

order=0 говорит нам, сколько памяти запрашивается. Управление памятью ядра позволяет управлять номерами страниц в пределах 2, поэтому clamd запросил 20 страниц памяти или 4 КБ.

Самые низкие два бита GFP_MASK (получить свободную маску страницы) составляют так называемые зональная маска  сообщение распределителю, какая зона для получения памяти из:

Flag            value      Description
                0x00u      0 implicitly means allocate from ZONE_NORMAL
__GFP_DMA       0x01u      Allocate from ZONE_DMA if possible
__GFP_HIGHMEM   0x02u      Allocate from ZONE_HIGHMEM if possible

Зоны памяти это концепция, созданная в основном по причинам совместимости. В упрощенном виде существует три зоны для ядра x86:

Memory range   Zone       Purpose 

0-16 MB        DMA        Hardware compatibility (devices)
16 - 896 MB    NORMAL     space directly addressable by the Kernel, userland 
> 896 MB       HIGHMEM    userland, space addressable by the Kernel via kmap() calls

В вашем случае zonemask равен 0, то есть clamd запрашивает память из ZONE_NORMAL,

Остальные флаги разрешают

/*
 * Action modifiers - doesn't change the zoning
 *
 * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
 * _might_ fail.  This depends upon the particular VM implementation.
 *
 * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
 * cannot handle allocation failures.
 *
 * __GFP_NORETRY: The VM implementation must not retry indefinitely.
 */
#define __GFP_WAIT      0x10u   /* Can wait and reschedule? */
#define __GFP_HIGH      0x20u   /* Should access emergency pools? */
#define __GFP_IO        0x40u   /* Can start physical IO? */
#define __GFP_FS        0x80u   /* Can call down to low-level FS? */
#define __GFP_COLD      0x100u  /* Cache-cold page required */
#define __GFP_NOWARN    0x200u  /* Suppress page allocation failure warning */
#define __GFP_REPEAT    0x400u  /* Retry the allocation.  Might fail */
#define __GFP_NOFAIL    0x800u  /* Retry for ever.  Cannot fail */
#define __GFP_NORETRY   0x1000u /* Do not retry.  Might fail */
#define __GFP_NO_GROW   0x2000u /* Slab internal usage */
#define __GFP_COMP      0x4000u /* Add compound page metadata */
#define __GFP_ZERO      0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x10000u /* Don't use emergency reserves */
#define __GFP_NORECLAIM  0x20000u /* No realy zone reclaim during allocation */

в соответствии с Документация по Linux MM, поэтому у вашего requst есть флаги для GFP_ZERO, GFP_REPEAT, GFP_FS, GFP_IO а также GFP_WAIT, таким образом, не особенно придирчивым.

Так что с ZONE_NORMAL? Некоторые общие характеристики можно найти далее на выходе OOM:

[kernel] [1772321.850770] Normal бесплатно: 8056kB мин: 8048kB низкий: 10060kB high: 12072kB active_anon: 0kB inactive_anon: 0kB active_file: 248kB inactive_file: 388kB unevictable: 0kB изолированный (anon)   : 0kB изолированный (файл): 0kB настоящее время: 890008kB

Примечательно, что free всего 8K от min и под low, Это означает, что диспетчер памяти вашего хозяина находится в бедственном положении, а kswapd должен заменять страницы уже так, как есть в желтый фазу графика ниже: Linux memory manager graph

Здесь приведена дополнительная информация о фрагментации памяти в зоне:

[kernel] [1772321.850795] Normal: 830 * 4kB 80 * 8kB 0 * 16kB 0 * 32kB 0 * 64kB 0 * 128kB 0 * 256kB 0 * 512kB 0 * 1024kB 0 * 2048kB 1 * 4096kB = 8056kB

в основном заявив, что у вас есть одна непрерывная страница 4 МБ, а остальные сильно фрагментированы в основном на 4 КБ страницы.

Итак, давайте повторим:

  • у вас есть пользовательский процесс (clamd) получение памяти от ZONE_NORMAL тогда как распределение непривилегированной памяти обычно выполняется из ZONE_HIMEM
  • диспетчер памяти должен на этом этапе обслуживать запрошенную страницу 4K, хотя у вас, похоже, значительное давление памяти в ZONE_NORMAL
  • системы, kswapdправила, должен уже видели какую-то пейджинговую активность, но ничего не выгружается, даже под давлением памяти в ZONE_NORMAL, без видимой причины
  • Ни одно из приведенных выше не дает определенной причины, почему oom-killer вызывается

Все это кажется довольно странным, но, по крайней мере, связано с тем, что описано в раздел 2.5 превосходной книги «Понимание Linux Virtual Memory Manager» Джона О'Гормана:

Поскольку пространство адресов, используемое ядром (ZONE_NORMAL), ограничено по размеру, ядро ​​поддерживает концепцию High Memory. [...] Чтобы получить доступ к памяти между диапазонами 1GiB и 4GiB, ядро ​​временно отображает страницы из большой памяти в ZONE_NORMAL с помощью kmap (). [...]

Это означает, что для описания 1GiB памяти требуется примерно 11 мегабайт памяти ядра. Таким образом, с 16GiB потребляется 176MiB памяти, что оказывает значительное давление на ZONE_NORMAL. Это не звучит слишком плохо, пока не будут учтены другие структуры, которые используют ZONE_NORMAL. Даже очень мелкие структуры, такие как записи таблиц страниц (PTE), требуют в 16 раз меньше 16 Мбайт. Это делает 16GiB о практическом пределе доступной физической памяти Linux на x86,

(акцент мой)

Поскольку у 3.2 есть много улучшений в управлении памятью выше 2.6, это не определенный ответ, но очень сильный намек, который я бы преследовал первым. Уменьшите полезную память хоста до 16 ГБ либо с помощью mem= параметр ядра или вырезать половину модулей DIMM из сервера.

В конечном счете, использовать 64-битное ядро,

Чувак, это 2015 год.


179
2017-09-24 10:46



Когда я сказал выше,Я не эксперт», это это то, что я надеялся прочитать. +1000, если бы я мог; +1 конечно. Какой отличный ответ! - MadHatter
Это было прекрасно. На SF все еще есть надежда. - Roman
@dataless Да. Я подозреваю, что вся ваша ZONE_NORMAL заполнена метаданными о верхних областях памяти. Когда пользовательский процесс запрашивает страницы памяти, он, скорее всего, будет запрашивать ZONE_HIGHMEM (который может быть обновлен MM до ZONE_NORMAL, если HIGHMEM не имеет больше бесплатных страниц для обслуживания запроса, кроме NORMAL), поэтому, если ZONE_HIGHMEM не находится под давлением памяти (у вас нет), ZONE_NORMAL не будет иметь страниц процессов пользовательского пространства. - the-wabbit
[хлопает кулаками по клавиатуре]. Дайте этот кусок щедрости - underscore_d
@ the-wabbit Горячие сетевые вопросы. - CodesInChaos


Несколько вещей ...

Мое правило для области подкачки состояло в том, чтобы иметь как минимум 2x количество физического барана. Это позволяет демону страницы / swap эффективно восстанавливать память.

Сервер_B имеет 32 ГБ оперативной памяти, поэтому попробуйте настроить его на 64 ГБ обмена. IMO, 2 Гбайт пространства подкачки, которое имеет ваш сервер, путь слишком низко, особенно для сервера.

Если у вас нет дополнительного раздела, который вы можете внести в раздел подкачки, вы можете проверить это, создав файл и установив его как раздел подкачки [он будет медленным]. Видеть https://www.maketecheasier.com/swap-partitions-on-linux/

Поскольку server_B имеет большое количество дискового пространства, --inplace не требуется, и может быть нежелательным, поскольку это может быть причиной того, что rsync использует 32 ГБ. --inplace действительно полезно, только если вы отстаете от пространства файловой системы [которого вы не являетесь] или имеете некоторые особые требования к производительности.

Я предполагаю, что rsync захочет использовать 50GB RAM [размер файла] с вашими текущими параметрами. Обычно rsync не нуждается в такой большой памяти для выполнения своей работы, поэтому может возникнуть проблема с одним или несколькими вашими параметрами. Я регулярно переписываю файлы объемом 200 ГБ без проблем.

Проделайте несколько тестовых прогонов без использования опций. Сделайте это с меньшими файлами, скажем, 10 ГБ - это должно помешать панике ядра, но все же позволит вам отслеживать поведение, вызывающее проблему. Мониторинг использования памяти rsync.

Постепенно добавьте опции назад, по одному, чтобы увидеть, какая опция [или комбинация опций] заставляет rsync запускать оцифровку в ОЗУ (например, во время передачи, использование ram-сервера rsync растет пропорционально количеству переданных файлов, и т.д.).

Если вам действительно нужны параметры, которые заставляют rsync сохранять некоторый образ файла в рамке, вам потребуется дополнительное пространство подкачки, и ваш максимальный размер файла будет ограничен соответствующим образом.

Еще несколько вещей [ОБНОВЛЕНО]:

(1) Трассировка стека ядра показывает, что rsync был ошибкой страницы в области mmap. Это, вероятно, mmaping файл. mmap не гарантирует, что он будет сбрасываться на диск до файл закрыт [в отличие от чтения / записи], который сразу же отправляется в кеш блока FS [где он будет очищен]

(2) Сбой / паника ядра происходит, когда размер передачи достигает размера ОЗУ. Очевидно, что rsync захватывает эту память, отличную от fscache, через malloc или mmap. Еще раз, с параметрами, которые вы указали, rsync выделит 50 ГБ памяти для переноса 50-гигабайтного файла.

(3) Передайте файл 24 ГБ. Это, вероятно, сработает. Затем загрузите ядро ​​с mem = 16G и повторите проверку файла 24GB. Он выдувается на 16 ГБ, а не на 32 ГБ. Это подтвердит, что rsync действительно нуждается в памяти.

(4) Прежде чем говорить, что добавление свопа смешно, попробуйте добавить некоторые [через метод swap-to-file]. Это гораздо легче сделать и проверить, чем все академические аргументы о том, как своп не требуется. Даже если это не решение, вы можете чему-то научиться. Я буду держать пари, что тест mem = 16G будет успешным без паники / сбоя.

(5) Скорее всего, rsync является но это происходит слишком быстро, чтобы видеть сверху до того, как OOM начинает атаковать и убивает rsync. К тому моменту, когда rsync дойдет до 32 ГБ, другие процессы уже были вынуждены сменяться, особенно если они простаивают. Возможно, сочетание «свободного» и «верхнего» даст вам лучшую картину.

(6) После того, как rsync будет убит, требуется время, чтобы сбросить mmap в FS. Не достаточно быстро для OOM, и он начинает убивать другие вещи [некоторые из них, очевидно, критически важны]. То есть, mmap flush и OOM участвуют в гонке. Или у OOM есть ошибка. В противном случае не было бы крушения.

(7) По моему опыту, когда система «попадает на стену памяти», Linux требует много времени для полного восстановления. И иногда он никогда не восстанавливается должным образом, и единственный способ его очистки - перезагрузка. Например, у меня 12 ГБ ОЗУ. Когда я запускаю задание, в котором используется 40 ГБ памяти [у меня есть 120 ГБ свопа для размещения больших заданий], а затем убей его, потребуется около 10 минут, чтобы система вернулась к нормальной реакции [при непрерывном освещении диска на жестком диске] ,

(8) Запустить rsync без опции. Это сработает. Получить базовый пример для работы. Затем добавьте обратно - на место и повторите проверку. Затем сделайте --append-verify вместо этого. Затем попробуйте оба. Узнайте, какой вариант получает rsync, делая огромный mmap. Тогда решите, можете ли вы жить без него. Если -inplace является виновником, это не проблема, так как у вас много дискового пространства. Если у вас должна быть опция, вам нужно будет получить пространство подкачки для размещения malloc / mmap, которое сделает rsync.

ВТОРОЕ ОБНОВЛЕНИЕ:

Пожалуйста, сделайте mem = и более мелкие проверки файлов из приведенного выше.

Основные вопросы: почему rsync убит OOM? Кто / Что такое жевательная память?

Я читал [но забыл] о том, что система 32 бит. Итак, я согласен, что rsync не может быть напрямую ответственным (через malloc / mmap - glibc реализует большие mallocs через анонимные / частные mmaps), а ошибка страницы mmap rsync просто запускает OOM по совпадению. Затем OOM вычисляет полную память, потребляемую rsync, прямо и косвенно [FS cache, буферы сокетов и т. Д.] И решает, что это главный кандидат. Таким образом, мониторинг использования общей памяти может оказаться полезным. Я подозреваю, что он ползет с той же скоростью, что и передача файла. Очевидно, этого не должно быть.

Некоторые вещи, которые вы можете отслеживать в / proc или / proc / rsync_pid через скрипт perl или python в быстром цикле [сценарий bash, вероятно, не будет достаточно быстрым для события конца света), который может контролировать все следующие несколько сотен раз / сек. Вы можете запустить это с более высоким приоритетом, чем rsync, чтобы он оставался в ОЗУ и работал, чтобы вы могли следить за вещами непосредственно перед сбоем и, надеюсь, во время OOM, чтобы вы могли понять, почему OOM сходит с ума:

/ proc / meminfo - чтобы получить более мелкое зерно при использовании swap в точке «удара». Фактически, получение конечного числа на том, сколько оперативной памяти используется, может быть более полезным. В то время как top обеспечивает это, он может быть недостаточно быстрым, чтобы показать состояние Вселенной непосредственно перед «большим ударом» (например, последние 10 миллисекунд)

/ proc / rsync_pid / fd. Чтение символических ссылок позволит вам определить, какой fd открывается в целевом файле (например, readlink / proc / rsync_pid / fd / 5-> target_file). Это, вероятно, нужно сделать только один раз, чтобы получить номер fd [он должен оставаться фиксированным]

Зная номер fd, посмотрите / proc / rsync_pid / fdinfo / fd. Это текстовый файл, который выглядит так:

pos: <file_position>
флаги: blah_blah
mnt_id: blah_blah

Мониторинг значения «pos» может быть полезным, поскольку «последнее положение файла» может оказаться полезным. Если вы выполняете несколько тестов с различными размерами и mem = options, сохраняет ли последнее положение файла любое из этих [и как]? Обычный подозреваемый: позиция файла == доступная оперативная память

Но самый простой способ - начать с «rsync local_file server: remote_file» и убедиться, что это работает. Вы можете получить аналогичные [но более быстрые] результаты, выполнив «ssh server rsync file_a file_b» [вам нужно создать файл размером 50 ГБ вначале]. Простым способом создания file_a является scp local_system: original_file server: file_a, и это может быть интересно для себя (например, работает ли это при сбое rsync? Если scp работает, но rsync терпит неудачу, это указывает на rsync. Если scp не удался, это указывает к чему-то еще, например, драйверу NIC). Выполнение ssh rsync также выводит NIC из уравнения, что может быть полезно. Если это шланги системы, то что-то действительно неправильно. Если это удастся, [как я уже упоминал], начните добавлять параметры поочередно.

Мне очень не нравится, но добавление некоторых свопов через swap-to-file может изменить / задержать поведение сбоя и может быть полезным в качестве диагностического инструмента. Если вы добавляете, скажем, 16 Гбайт, своп задерживает сбой (как измеряется с использованием памяти или положение целевого файла) с 32 ГБ до 46 ГБ, тогда это что-то скажет.

Это может быть не какой-то конкретный процесс, а ошибочный драйвер ядра, который является жевательной памятью. Внутренний vmalloc ядра выделяет материал, и его можно поменять. IIRC, это не связано с адресацией при любых обстоятельствах.

Ясно, что ООМ запутывается / запаникован. То есть, он убивает rsync, но не видит, что память освобождается своевременно и идет искать других жертв. Некоторые из них, вероятно, важны для работы системы.

malloc / mmap в стороне, это может быть вызвано неиспользуемым кешем FS, который занимает много времени (например, с 30 ГБ нераскрытых данных, если скорость диска составляет 300 МБ / с, для его очистки может потребоваться 100 секунд). Даже в этом случае OOM может быть слишком нетерпеливым. Или, OOM killing rsync не запускает FS flush достаточно быстро [или вообще]. Или FS flush происходит достаточно быстро, но у него есть «ленивый» выпуск страниц обратно в бесплатный пул. Есть некоторые опции / proc, которые вы можете настроить для управления поведением кэша FS [я не помню, что это такое].

Попробуйте загрузиться с mem = 4G или другим небольшим числом. Это может привести к сокращению кеша FS и сократить время его очистки, чтобы OOM не искал другие вещи, которые нужно убить (например, время стирания уменьшается с 100 секунд до <1 с). Он также может разоблачить ошибку OOM, которая не может обрабатывать физический RAM> 4 ГБ в 32-битной системе или некоторых таких.

Кроме того, важный момент: Запуск от имени не root. Корневые пользователи никогда не собираются пережевывать ресурсы, поэтому им предоставляются более прогибные ограничения (например, 99% памяти и 95% для пользователей без полномочий root). Это может объяснить, почему OOM находится в таком состоянии. Кроме того, это дает OOM et. и др. больше места для выполнения своей работы по восстановлению памяти.


4
2017-09-27 20:30



Видеть Сколько SWAP-пространства на высокой памяти? - и вы не хотите, чтобы ваша система использовала 63GB подкачки. Он не будет использоваться. - Martin Schröder
swap> RAM действительно очень полезно, если вы запускаете без перенаправления VM, поэтому ядро ​​необходимо зарезервировать пространство подкачки для выделенных страниц, пока они не загрязнены и не потребуют реальных физических страниц, поддерживающих их. Текущая практика заключается в том, чтобы разрешить перекомпилировать и запустить с небольшим количеством пространства подкачки, чтобы выводить страницы, которые были затронуты только при запуске, и не нужны при нормальной работе. overcommit = 0 с небольшим свопированием, если у вас много оперативной памяти, для большинства систем. - Peter Cordes
Похоже, что rsync действительно является пытаясь использовать> 32 ГБ, поэтому для этого нужен своп. То есть, rsync будет использовать 50 ГБ для этого файла. 2x был проверенным и достоверным показателем в течение 30 лет. Поскольку диск с 6 ТБ составляет ~ 300 долларов, нет причин не делать этого. Что еще может быть запущено на этом сервере, который коллективно будет нажимать на ограничение RAM? - Craig Estey
@CraigEstey 64 ГБ свопа совершенно смешно, поскольку, как я уже говорил ранее, у нас нет больших пользовательских процессов, нам нужен только кэш диска, и, как показал мой журнал, мы использовали обмен ZERO во время сбоя. НУЛЬ. Кроме того, rsync использует 600 Кбайт памяти даже в файле размером 50 ГБ. Моя первоначальная путаница заключалась в том, что, возможно, linux агрессивно держался за кеш диска. И, наконец, я хочу увидеть некоторые цифры или документацию о том, сколько памяти ядро ​​использует для отслеживания своего пространства подкачки, прежде чем я добавлю в это поле больше. - dataless
@dataless Я добавил дополнительную информацию, которая полностью объясняет, что происходит и почему. Rsync является захватив память через malloc / mmap, и она пойдет на 50 ГБ, прежде чем это будет сделано. См. Обновленный раздел. В нем есть тесты, которые могут доказать / опровергнуть то, что я говорю, и вы можете сначала пропустить добавленную замену для тестирования. BTW, я программировал ядра / драйверы на 40 лет - я мог бы просто знать то, чего у вас нет, поэтому, пожалуйста, смягчите тон - я я пытаясь помочь. - Craig Estey


clamd? Похоже, вы используете ClamAV и включаете сканирование по доступу, где антивирусный движок пытается сканировать открытые файлы для вирусов, путем загрузки в память, все содержимое каждого файла, открытого любым другим процессом,

В зависимости от вашей позиции безопасности и необходимости этой передачи вы должны оценить, как отключить ClamAV при доступе к сканированию во время выполнения переноса.


2
2017-09-28 10:34



Я не знал, что это даже вещь, которую мог бы сделать clamav ... но нет, мы сканируем только определенные файлы, переданные по ней из clamc. Кроме того, 32-битный, поэтому никакой опасности clamav не забивает всю системную память. (вы понимаете, почему мы думали, что 32-битная идея по-прежнему хорошая?) - dataless
Ядро Linux сообщает, что clamd - это процесс, в котором запросы выделения памяти вызывают убийцу OOM. ClamAV почти наверняка является вторичной причиной (основной причиной является нехватка памяти). Независимо от того, выполняется ли это сканирование при доступе или какая-либо другая конфигурация, все признаки указывают на ClamAV. - oo.
В следующий раз, когда вы запустите rsync, запустите верхнюю часть и проверите резидентный размер процесса clamd. - oo.
clamd был первым процессом для вызова убийцы oom, но и первым, кто умел умирать, поскольку он весит почти 42 МБ (один из больших процессов на сервере). После этого oom_killer запускается несколько раз, пока даже металлог не убит. - dataless