Я изо всех сил пытаюсь понять, как ошибки OOM могут происходить в Apache Spark executors при использовании Unified Memory Management.
Из того, что я прочитал, я заключаю следующее:
- Память исполнителя делится на: память выполнения, память хранения и память пользователя
- Память пользователя статически распределенный = TOTAL_MEMORY * (1 - spark.memory.fraction).
Память пользователя. Это пул памяти, который остается после выделения Spark Memory, и вы можете использовать его по своему усмотрению. Там вы можете хранить свои собственные структуры данных, которые будут использоваться в преобразованиях RDD. Например, вы можете переписать агрегацию Spark, используя преобразование mapPartitions с таблицей ha sh для выполнения этой агрегации, которая потребляет так называемую пользовательскую память. [...] И опять же, это пользовательская память и полностью зависит от вас, что будет храниться в этом ОЗУ и как, Spark совершенно не учитывает, что вы там делаете и соблюдаете ли вы эту границу или нет. Несоблюдение этой границы в вашем коде может привести к ошибке OOM.
- Оставшаяся память исполнителя динамически распределяется между выполнением и хранением при получении запроса. Когда вся память используется и требуется дополнительная память для выполнения, память для хранения будет освобождена путем разлива ее на диск и переназначения для памяти для выполнения. Можно настроить часть памяти, которая не будет переназначена как память выполнения, если она используется в качестве памяти хранения (по умолчанию 50%). В случае, если больше нет памяти, может быть выделено либо для хранилища, либо страницы выполнения будут пролиты на диск.
Поэтому мой вопрос, когда я выполняю чистые запросы Spark SQL, если память выполнения и память может быть пролита на диск, как могут возникать ошибки OOM, если пользовательская память вообще не используется? Разве это не должно заботиться о проблемах с памятью, проливая данные на диск? Все ли ошибки OOM связаны с долей пользовательской памяти?
ПРИМЕЧАНИЕ. Я не включаю память OffHeap в вопрос, чтобы не допустить этой сложности в проблему