Анализ аварийного завершения из-за OOM Killer

Если после аварийного завершения процесса BE в log/be.out нет сообщения об ошибке, выполните dmesg -T. Если вы видите приведённую ниже запись, это означает, что сработал OOM Killer. Из неё видно, что в 20240718 15:03:59 объём физической памяти (anon-rss), занятой процессом doris_be с pid 360303, составлял около 60 GB.

[Thu Jul 18 15:03:59 2024] Out of memory: Killed process 360303 (doris_be) total-vm:213416916kB, anon-rss:62273128kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:337048kB oom_score_adj:0

В идеале Doris должен регулярно проверять объём оставшейся доступной памяти операционной системы и при её нехватке выполнять ряд действий, включая блокировку последующих запросов на выделение памяти и запуск GC памяти, чтобы предотвратить срабатывание OOM Killer. Однако обновление сведений о состоянии памяти и GC памяти выполняются с некоторой задержкой, и перехватить все крупные запросы на выделение памяти сложно. При слишком высокой нагрузке на кластер по-прежнему существует вероятность срабатывания OOM Killer, приводящего к аварийному завершению процесса BE. Кроме того, при аномальном состоянии памяти процесса GC не может освободить память. Это уменьшает объём памяти, фактически доступной процессу, и увеличивает нагрузку на память кластера.

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

Поиск записей о памяти перед срабатыванием OOM Killer

Срабатывание OOM Killer означает, что процессу не хватает доступной памяти. Следуя рекомендациям в разделе Анализ журналов памяти, найдите последнюю запись с ключевым словом Memory Tracker Summary, двигаясь от момента срабатывания OOM Killer вверх по журналу be/log/be.INFO, и определите, на что в основном расходуется память процесса BE.

less be/log/be.INFO: после открытия файла сначала перейдите к записям, соответствующим времени срабатывания OOM Killer. Для приведённого выше результата dmesg -T введите /20240718 15:03:59 и нажмите Enter, чтобы найти соответствующее время. Если найти его не удалось, возможно, время срабатывания OOM Killer немного отличается. Можно выполнить поиск по /20240718 15:03:. После перехода к записям за соответствующее время введите /Memory Tracker Summary и нажмите Enter, чтобы найти ключевые слова. По умолчанию поиск выполняется вниз по журналу. Если запись не найдена или время не совпадает, сначала нажмите shift + n, чтобы искать вверх и найти последнюю запись Memory Tracker Summary и выведенную одновременно с ней запись о памяти Process Memory Summary.

Срабатывание OOM Killer из-за чрезмерной нагрузки на память кластера

Если наблюдаются перечисленные ниже признаки, можно считать, что нагрузка на память кластера слишком высока. Из-за этого в некоторый момент сведения о состоянии памяти процесса не успевают обновиться, а GC не успевает освободить память, и эффективно контролировать потребление памяти процессом BE не удаётся.

В версиях до Doris 2.1 механизм GC памяти был недостаточно совершенен, поэтому при постоянной нехватке памяти OOM Killer срабатывал чаще.

• Анализ Memory Tracker Summary показывает, что потребление памяти запросами и другими задачами, различными кешами, метаданными и т. д. не выглядит чрезмерным.

• Мониторинг памяти процесса BE за соответствующий период показывает, что уровень использования памяти длительное время остаётся высоким, при этом признаков утечки памяти нет

• Найдите записи о памяти перед моментом срабатывания OOM Killer в be/log/be.INFO и выполните поиск по ключевому слову GC снизу вверх. Из записей видно, что процесс BE часто выполняет GC памяти.

В этом случае обратитесь к разделу Параметры конфигурации BE, чтобы уменьшить mem_limit и увеличить max_sys_mem_available_low_water_mark_bytes в be/conf/be.conf. Подробнее об ограничениях памяти, методах расчёта пороговых уровней и GC памяти см. в разделе Стратегия управления памятью.

Кроме того, для управления обновлением сведений о состоянии памяти и GC можно настроить другие параметры, включая memory_gc_sleep_time_ms, soft_mem_limit_frac, memory_maintenance_sleep_time_ms, process_minor_gc_size, process_full_gc_size, thread_wait_gc_max_milliseconds и т. д.

Аномалии, вызывающие срабатывание OOM Killer

Если нагрузка на память кластера слишком высока, состояние памяти может стать аномальным, а GC может не успеть освободить память. Ниже описаны некоторые распространённые аномалии, которые приводят к срабатыванию OOM Killer.

Неполный учёт памяти в Memory Tracker

Если значения Memory Tracker Label=process resident memory и Memory Tracker Label=sum of all trackers в журнале Memory Tracker Summary сильно различаются или значение Orphan Memory Tracker слишком велико, это означает, что Memory Tracker учитывает не всю память. Для дальнейшего анализа обратитесь к разделу [Неполный учёт памяти в Memory Tracker] в документе Memory Tracker.

Зависание отмены запроса

Найдите момент срабатывания OOM Killer в журнале be/log/be.INFO, затем выполните поиск Memory Tracker Summary в соседних записях, чтобы найти статистику памяти процесса. Если в Memory Tracker Summary есть запрос, потребляющий много памяти, выполните grep {queryID} be/log/be.INFO, чтобы проверить, есть ли запись с ключевым словом Cancel. Время этой записи соответствует моменту отмены запроса. Если запрос был отменён задолго до срабатывания OOM Killer, обратитесь к разбору [Зависание процесса отмены запроса] в разделе Часто задаваемые вопросы о проблемах с памятью. Для анализа Memory Tracker Summary обратитесь к разделу Анализ журналов памяти.

Высокое потребление памяти Jemalloc Metadata

В настоящее время GC памяти не может освободить память, занятую Jemalloc Metadata. Чтобы снизить потребление памяти, обратитесь к разбору Memory Tracker Label=tc/jemalloc_metadata в разделе Memory Tracker.

Высокое потребление памяти Jemalloc Cache

Часто встречается в Doris 2.0

Значение по умолчанию для lg_tcache_max в JEMALLOC_CONF в файле be.conf Doris 2.0 равно 20. Из-за этого в некоторых сценариях Jemalloc Cache может занимать слишком много памяти и не освобождаться автоматически. Чтобы уменьшить объём памяти, занимаемый Jemalloc Cache, обратитесь к разделу Анализ использования памяти Jemalloc.