Rsync запустил убийцу OOM Linux для одного файла размером 50 ГБ

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

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

[ядро] [1772321.850644] clamd вызвал oom-killer: gfp_mask = 0x84d0, порядок = 0

order=0 сообщает нам, сколько памяти запрошено. Управление памятью ядра может управлять номерами страниц только в степени 2, поэтому clamd запросил 2⁰ страниц памяти или 4KB.

Два младших бита 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

В вашем случае маска зоны равна 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, поэтому в вашем запросе есть флаги для GFP_ZERO, GFP_REPEAT, GFP_FS, GFP_IO и GFP_WAIT, поэтому не особо разборчивый.

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

[ядро] [1772321.850770] Нормальное бесплатно: 8056 КБ мин: 8048 КБ низкое: 10060 КБ высокий: 12072 КБ active_anon: 0 КБ неактивный_анон: 0 КБ active_file: 248 КБ неактивный_файл: 388 КБ непредсказуемо: 0 КБ изолированно (анон): 0 КБ изолированно (файл): 0 КБ присутствует: 890008 КБ

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

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

[ядро] [1772321.850795] Нормальный: 830 * 4 КБ 80 * 8 КБ 0 * 16 КБ 0 * 32 КБ 0 * 64 КБ 0 * 128 КБ 0 * 256 КБ 0 * 512 КБ 0 * 1024 КБ 0 * 2048 КБ 1 * 4096 КБ = 8056 КБ

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

Итак, давайте резюмируем:

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

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

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

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

(курсив мой)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pos: <file_position>
flags: blah_blah
mnt_id: blah_blah

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

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

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

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

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

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

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

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

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

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