Скандалы, интриги, расследования: память и erl_crash.dump
В рассылке был задан следующий вопрос:
Одна из наших нод упала из-за нехватки памяти (out of memory), что было вызвано неожиданным всплеском сетевого трафика. Несмотря на то, что существуют механизмы для перезапуска ноды, само падение ноды заняло очень длительное время, потому что в то время писался большой erl_crash.dump, окторый в итоге вырос до 7GB.
Есть ли какие-то способы более быстрого падения? Я вообще думаю о том, чтобы отключить логгинг падений. Что еще остается сделать? Хотелось бы иметь возможность конфигурировать erl_crash для каждой ноды отдельно.
После этого развернулась интересная дискуссия вокруг возможности и невозможности отключения и конфигурирования core dump'ов для Erlang'овских нод.
Один из возможных способов, безусловно, — это coreadm, позволяющий указывать что, как и куда писать в случае ненормального завершения процессов.
Второй вариант, описанный на StackOverflow, — это пропатчить функцию erl_crash_dump_v в файле break.c так, чтобы она ничего не делала, перекомпилировать Erlang и работать со своей версией.
Richard Carlsson обратил внимание, что для управления dump-файлами есть неплохие переменные окружения ERL_CRASH_DUMP*, описанные тут: http://www.erlang.org/doc/man/erl.html. Они позволяют, в частности ограничить время, которое эмулятор может потратить на запись файла.
И вот ту началась интрига.
Главной проблемой в описанной ситуации назвали то, что BEAM-эмулятор в случае, если ему не хватает памяти, просто убивает узел, без возмоности этот процесс каким-либо образом проконтролировать. Вспомнили так же проблему неограниченных очередей сообщений, которые могут привести к снижению производительности системы или просто уронить узел из-за нехватки памяти.
Некто Tony Rogvall в качестве демонстрации возможностей такого контроля внес некоторые изменения в OTP, которые позволяют передавать следующие опции при запуске новых процессов: max_memory, max_time, max_cpu, max_reductions, max_processes, max_ports, max_tables, max_message_queue_len. Ветка, безусловно, экспериментальная, но служит доказательством того, что такое сделать возможно. Tony предложил создать EEP по этому поводу, как появился Kenneth Lundin.
Оказалось, что описанную проблему команда Erlang/OTP обсуждает уже несколько лет. И по стечению обстоятельств в планах сделать что-либо по этому поводу в предстоящем году. К сожалению Kenneth не смогу предоставить никаких деталей.
Но что можно сказать. Если у вас возникают проблемы с ошибками Out Of Memory, пока что единственный путь — это варианты, описанные выше. Но в предстоящем году, можно надеяться, мы увидим официальный подход к решению от команды Erlang/OTP.