Телеграмм чат группы moscowspark страница 689

13:22пожаловаться #1

2021 June 05

ДД

Господа, добрый день! Много раз натыкался на информацию о том, что выделение слишком большого объема памяти на экзекьютор чревато в итоге долгой сборкой мусора.
Везде это приводится просто как факт, но, к моему стыду, для меня неочевидна связь между первым и вторым.
Может быть, кто-то может объяснить как первое приводит ко второму?

15:45пожаловаться #2

ДД

num-executors and executor-memory in Spark

Единственное объяснение нашел вот тут, но не знаю насколько оно адекватное:
https://community.cloudera.com/t5/Support-Questions/num-executors-and-executor-memory-in-Spark/td-p/232919

Cloudera

Can someone explain following lines about num-executors and executor-memory Below written statement on hortonworks site (https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.4/bk_spark-guide/content/ch_tuning-spark.html#spark-job-status): There are tradeoffs between num-executors and executor-memo...

15:46пожаловаться #3

ПФ

Вообще неочевидная фигня. Может там память аллоцируется и работа заканчивается

19:35пожаловаться #4

ПФ

А там ещё часть памяти а дайрект байт буфферах, которые с большой вероятностью вообще не собираются GC

19:36пожаловаться #5

Dmitry Zuev in Moscow Spark

Что с значит с вероятностью? В оффхипе точно не будет работать гц

20:12пожаловаться #6

Andrey Smirnov in Moscow Spark

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

20:22пожаловаться #7

ДС

хм
https://docs.oracle.com/cd/E19159-01/819-3681/6n5srlhqf/index.html

20:53пожаловаться #8

ДС

этого не достаточно для обоснования зависимости GC от выделяемой памяти?

20:54пожаловаться #9

ДС

вам надо обосновать для кого-то почему так делать неправильно или вы для себя понять хотите?

20:57пожаловаться #10

ПФ

ну она же параллельная!

20:59пожаловаться #11

ПФ

Особенно когда там G1 какой-нить

20:59пожаловаться #12

Nikita Blagodarnyy in Moscow Spark

Ну может пару-тройку то хоть соберёт?

21:00пожаловаться #13

ПФ

Может быть случайно ничего нет в оффхипе, а всё в хипе

21:00пожаловаться #14

ДД

Второе.
Условно говоря, почему нельзя на 10гб данных выделить 1000Гб памяти и не думать ни о чем

21:01пожаловаться #15

ДС

тогда второе уточнение, мы говорим про какой класс задач? у вас контйнер висит сутками на потоке или батчевые задачи?

21:02пожаловаться #16

ДД

батчевые задачи

21:03пожаловаться #17

ДС

тогда это вопрос алгоритмов, и перед вами должна стоять задача оптимизации алгоритма обработки данных

21:03пожаловаться #18

ДС

вы должны озаботиться тем чтобы у вас задача более эффективно развалилась по экзам а не эффективностью GC на экзах

21:04пожаловаться #19

Nikita Blagodarnyy in Moscow Spark

Нагуглите, есть отличный цикл статей на хабре из 3 частей про гарбадж коллекшон. На русском. Если вкратце, то всё логично. Чем больше свободной памяти, тем больше туда можно напихать объектов. Чем больше объектов - тем больше нужно сделать работы, чтобы понять живые они или нет, пробежать по каждому до корней.