Экономичный драйвер OutOfMemory при одновременном выполнении нескольких запросов Hive

мы используем Spark2 Thrift для выполнения запросов Hive.

Thrift входит в состав HDP 2.6, а наша искровая версия — 2.1.0.2.6.0.3-8.

Чем больше запросов мы выполняем одновременно, тем быстрее мы сталкиваемся с OOM в драйвере. Эти запросы также содержат JOIN и UNION.

из jstat кажется, что утечки памяти нет, однако независимо от того, сколько памяти выделено драйверу, кажется, что ее никогда не бывает достаточно. Чем больше запросов выполняется одновременно, тем быстрее драйвер Thrift начинает выполнять полную сборку мусора до тех пор, пока не выйдет из строя, поскольку полная сборка мусора не может очистить старую память (поскольку она используется).

OOM никогда не возникает в исполнителях, только в драйвере.

Кто-нибудь работает с Thrift через искру и сталкивается с этой проблемой? и если да, то как можно настроить драйвер Thrift, чтобы он не вылетал на OOM при одновременном выполнении нескольких запросов?

Вот конфигурации, которые мы используем:

Драйвер бережливости:

  • spark.driver.memory=15g

Бережливые исполнители:

  • spark.executor.memory=10g

  • количество ядер = 7

параметры конфигурации из /usr/hdp/current/spark2-thriftserver/conf/spark-thrift-sparkconf.conf:

  • spark.broadcast.blockРазмер 32 м

  • spark.driver.extraLibraryPath /usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64

  • spark.driver.maxResultSize 0

  • spark.dynamicAllocation.enabled true

  • spark.dynamicAllocation.executorIdleTimeout 45 с

  • spark.dynamicAllocation.initialExecutors 2

  • spark.dynamicAllocation.maxExecutors 15

  • spark.dynamicAllocation.minExecutors 0

  • spark.dynamicAllocation.schedulerBacklogTimeout 1 с

  • spark.eventLog.dir hdfs:///spark2-history/

  • spark.eventLog.enabled true

  • spark.executor.extraLibraryPath /usr/hdp/current/hadoop-client/lib/native:/usr/hdp/current/hadoop-client/lib/native/Linux-amd64-64

  • spark.executor.memory 10g

  • spark.files.maxPartitionBytes 268435456

  • spark.files.openCostInBytes 33554432

  • spark.hadoop.cacheConf false

  • spark.history.fs.logDirectory hdfs:///spark2-history/

  • spark.history.provider org.apache.spark.deploy.history.FsHistoryProvider

  • spark.kryoserializer.buffer.max 2000m

  • клиент пряжи spark.master

  • spark.memory.offHeap.enabled true

  • spark.memory.offHeap.size 104857600

  • spark.scheduler.allocation.file /usr/hdp/current/spark2-thriftserver/conf/spark-thrift-fairscheduler.xml

  • spark.scheduler.mode ЧЕСТНЫЙ

  • spark.shuffle.service.enabled true

  • spark.sql.autoBroadcastJoinThreshold 1073741824

  • spark.sql.shuffle.partitions 100

  • spark.storage.memoryMapThreshold 8 м


out-of-memory thrift apache-spark-2.0
person Elad Eldor    schedule 12.10.2017    source источник
comment
Я предполагаю, что более подходящим термином будет «Искра вместо бережливости».   -  person JensG    schedule 12.10.2017
comment
@elad-eldor Вы когда-нибудь находили решение этой проблемы?   -  person ronhash    schedule 08.10.2018

Ответы (1)


arrow_upward
0
arrow_downward

Попробуйте изменить режим планировщика на FIFO.

Также не забывайте, что в памяти есть 2 разные зоны: - хранение - выполнение

Хранилище по умолчанию будет использовать 60% памяти драйвера, поэтому, если вы никогда не кешируете данные, уменьшите его, чтобы выделить больше памяти там, где это необходимо (говорят, что это делается автоматически, но ...).

Попробуйте уменьшить раздел Spark Shuffle до 100, а затем до 10, если это возможно.

Попробуйте offheap (никогда не проверял, но может помочь).

person Thomas Decaux    schedule 18.10.2017
comment
почему FIFO лучше, чем FAIR? Кроме того, вы имеете в виду использование 10 разделов в случайном порядке вместо 100? - person Elad Eldor; 22.10.2017
comment
FIFO лучше подходит для ресурсов (поскольку один запрос выполняется одновременно). Я обнаружил, что уменьшение раздела Spark для небольшой рабочей нагрузки может быть лучше, попробуйте, проверьте размер раздела в веб-интерфейсе, максимальное значение составляет 2 ГБ, меньшее количество разделов означает меньше операций в случайном порядке (поэтому меньше использование ресурсов). - person Thomas Decaux; 22.10.2017
comment
у нас есть многопользовательская среда с несколькими запросами, которые должны выполняться одновременно. Вы рекомендуете в такой среде перейти с FAIR на FIFO? и уменьшить количество перетасовываемых разделов со 100 до 10? - person Elad Eldor; 23.10.2017