Настройка JVM в Spark

Это 20-й день моего участия в Gengwen Challenge, пожалуйста, проверьте подробности мероприятия:Обновить вызов

Для настройки JVM, прежде всего, должно быть понятно, что full gc/minor gc вызовет остановку работы рабочих потоков JVM, то есть остановит мир.

Настройка JVM 1: уменьшение объема памяти операций кэширования

• 1. Механизм управления статической памятью

   В соответствии с механизмом управления статической памятью Spark куча памяти делится на две части: хранилище и выполнение. Хранилище в основном используется для кэширования данных RDD и широковещательных данных, а выполнение в основном используется для кэширования промежуточных данных, сгенерированных в процессе тасования. два полностью независимы. Как правило, память для хранения предоставляется для операции кэширования, но в некоторых случаях оперативная память кэширования не очень мала, и в операторе задачи создается много объектов, а память выполнения относительно мала, что приводит к частым незначительный сбор мусора или даже частый полный сбор мусора приведет к тому, что Spark часто перестанет работать, что сильно повлияет на производительность.

В пользовательском интерфейсе Spark вы можете просмотреть статус выполнения каждого этапа, включая время выполнения каждой задачи, время сбора мусора и т. д. Если вы обнаружите, что сбор мусора выполняется слишком часто, а время слишком велико, вы можете рассмотреть возможность настройки соотношения памяти. Хранилища и позволить задаче выполнить расчет.Тип подфункции, можно использовать больше памяти.

Область памяти   Storage можно указать через параметр spark.storage.memoryFraction. Значение по умолчанию — 0,6, что составляет 60%. Его можно постепенно уменьшать, как показано в листинге кода:

val conf = new SparkConf()
  .set("spark.storage.memoryFraction", "0.4")

• 2. Единый механизм управления памятью

   Согласно унифицированному механизму управления памятью Spark, куча памяти делится на две части: хранилище и выполнение. Хранилище в основном используется для кэширования данных, а выполнение в основном используется для кэширования промежуточных данных, созданных в процессе перемешивания. Часть памяти, состоящая из двух, называется объединенной памятью.Каждое хранилище и выполнение составляют 50% объединенной памяти. к реализации механизма динамического занятия, когда память, необходимая для процесса тасования, слишком велика, он автоматически занимает область памяти Хранилища, поэтому нет необходимости настраивать ее вручную.

Настройка JVM 2: Настройка памяти вне кучи Executor

Вне кучи память   Executor в основном используется для разделяемой библиотеки программы, постоянного пространства, стека потоков и некоторого сопоставления памяти и т. д., или C-подобного объекта выделения.

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

Когда задача этапа выполняется, может потребоваться извлечь выходной файл карты перетасовки из некоторых исполнителей, но исполнитель мог умереть из-за переполнения памяти, а связанный с ним BlockManager также исчез, что может сообщить о выходном файле перетасовки. , Не удается найти, исполнитель потерян, задача потеряна, не хватает памяти и другие ошибки, в это время вы можете рассмотреть возможность настройки вне кучи памяти исполнителя, что может избежать ошибок.В то же время, когда настройка вне кучи памяти является относительно большим, поскольку с точки зрения производительности это также принесет определенное улучшение.

По умолчанию верхний предел памяти Executor вне кучи составляет более 300 МБ.В реальной производственной среде при обработке больших данных здесь будут проблемы, вызывающие неоднократные сбои задания Spark и его сбой при запуске. время, он будет скорректирован.Этот параметр не менее 1G, даже 2G и 4G.

Конфигурация памяти Executor вне кучи должна быть настроена в сценарии spark-submit, как показано в листинге кода:

--conf spark.yarn.executor.memoryOverhead=2048

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

Третья настройка JVM: настроить время ожидания соединения

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

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

В производственной среде иногда встречаются такие ошибки, как «файл не найден» и «файл потерян», в этом случае весьма вероятно, что BlockManager Исполнителя не может установить соединение при вытягивании данных, а затем превышает время ожидания соединения по умолчанию. 60 с, получение данных объявляется неудачным. Если данные не удается получить после повторных попыток, задание Spark может завершиться сбоем. Эта ситуация также может привести к тому, что DAGScheduler будет повторно отправлять несколько этапов, а TaskScheduler — отправлять несколько задач обратно, что значительно продлит время выполнения нашего задания Spark.

   На этом этапе вы можете рассмотреть возможность настройки периода ожидания соединения.Период ожидания соединения необходимо установить в сценарии spark-submit.Метод настройки показан в списке кодов:

--conf spark.core.connection.ack.wait.timeout=300

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