Предотвращение утечек памяти с помощью Scalaz 7 zipWithIndex / group enumeratees

Question

Предотвращение утечек памяти с помощью Scalaz 7 zipWithIndex / group enumeratees

102

Фон

Как отмечено в этом вопросе, я использую Scalaz 7 для обработки большого (т.е. неограниченного) потока данных в постоянном пространстве кучи.

Мой код выглядит следующим образом:

type ErrorOrT[M[+_], A] = EitherT[M, Throwable, A]
type ErrorOr[A] = ErrorOrT[IO, A]

def processChunk(c: Chunk, idx: Long): Result

def process(data: EnumeratorT[Chunk, ErrorOr]): IterateeT[Vector[(Chunk, Long)], ErrorOr, Vector[Result]] =
  Iteratee.fold[Vector[(Chunk, Long)], ErrorOr, Vector[Result]](Nil) { (rs, vs) =>
    rs ++ vs map { 
      case (c, i) => processChunk(c, i) 
    }
  } &= (data.zipWithIndex mapE Iteratee.group(P))

Проблема

Кажется, что я столкнулся с утечкой памяти, но я недостаточно осведомлен о Scalaz/FP, чтобы узнать, есть ли ошибка в Scalaz или в моем коде. Интуитивно я ожидаю, что этот код потребует только (по порядку) P раз пространства Chunk -размер.

Примечание. Я нашел аналогичный вопрос, в котором встречался OutOfMemoryError, но мой код не использует consume.

Тестирование

Я провел несколько тестов, чтобы попытаться изолировать проблему. Подводя итог, утечка появляется только при использовании как zipWithIndex, так и group.

// no zipping/grouping
scala> (i1 &= enumArrs(1 << 25, 128)).run.unsafePerformIO
res47: Long = 4294967296

// grouping only
scala> (i2 &= (enumArrs(1 << 25, 128) mapE Iteratee.group(4))).run.unsafePerformIO
res49: Long = 4294967296

// zipping and grouping
scala> (i3 &= (enumArrs(1 << 25, 128).zipWithIndex mapE Iteratee.group(4))).run.unsafePerformIO
java.lang.OutOfMemoryError: Java heap space

// zipping only
scala> (i4 &= (enumArrs(1 << 25, 128).zipWithIndex)).run.unsafePerformIO
res51: Long = 4294967296

// no zipping/grouping, larger arrays
scala> (i1 &= enumArrs(1 << 27, 128)).run.unsafePerformIO
res53: Long = 17179869184

// zipping only, larger arrays
scala> (i4 &= (enumArrs(1 << 27, 128).zipWithIndex)).run.unsafePerformIO
res54: Long = 17179869184

Код для тестов:

import scalaz.iteratee._, scalaz.effect.IO, scalaz.std.vector._

// define an enumerator that produces a stream of new, zero-filled arrays
def enumArrs(sz: Int, n: Int) = 
  Iteratee.enumIterator[Array[Int], IO](
    Iterator.continually(Array.fill(sz)(0)).take(n))

// define an iteratee that consumes a stream of arrays 
// and computes its length
val i1 = Iteratee.fold[Array[Int], IO, Long](0) { 
  (c, a) => c + a.length 
}

// define an iteratee that consumes a grouped stream of arrays 
// and computes its length
val i2 = Iteratee.fold[Vector[Array[Int]], IO, Long](0) { 
  (c, as) => c + as.map(_.length).sum 
}

// define an iteratee that consumes a grouped/zipped stream of arrays
// and computes its length
val i3 = Iteratee.fold[Vector[(Array[Int], Long)], IO, Long](0) {
  (c, vs) => c + vs.map(_._1.length).sum
}

// define an iteratee that consumes a zipped stream of arrays
// and computes its length
val i4 = Iteratee.fold[(Array[Int], Long), IO, Long](0) {
  (c, v) => c + v._1.length
}

Вопросы

Является ли ошибка в моем коде?
Как я могу сделать эту работу в постоянном пространстве кучи?

Aaron Novstrup 02 окт. 2013, в 02:23

Источник

6

В итоге я сообщил об этом как о проблеме в Скалазе .
Aaron Novstrup 03 окт. 2013, в 21:35
1

Это будет неинтересно, но вы можете попробовать -XX:+HeapDumpOnOutOfMemoryError и проанализировать дамп с помощью eclipse MAT eclipse.org/mat, чтобы увидеть, какая строка кода удерживается в массивах.
huynhjl 09 окт. 2013, в 06:56
10

@huynhjl FWIW, я попытался проанализировать кучу с помощью JProfiler и MAT, но не смог полностью просмотреть все ссылки на анонимные классы функций и т. д. Scala действительно нужны специальные инструменты для такого рода вещей.
Aaron Novstrup 10 окт. 2013, в 19:29
0

Что, если утечки нет, и просто для того, что вы делаете, требуется дико увеличивающийся объем памяти? Вы можете легко скопировать zipWithIndex без этой конкретной конструкции FP, просто поддерживая счетчик var на ходу.
Ezekiel Victor 14 окт. 2014, в 09:40
0

@EzekielVictor Я не уверен, что понимаю комментарий. Вы предлагаете, чтобы добавление одного Long индекса на чанк изменило бы алгоритм с пространства кучи на постоянную и непостоянную? Версия без архивации явно использует пространство постоянной кучи, потому что она может «обрабатывать» столько кусков, сколько вы готовы ждать.
Aaron Novstrup 14 окт. 2014, в 20:50
0

Извините, да, «дико увеличивающееся» подразумевает изменение сложности кучи пространства WRT. Я должен был просто сказать «соединение». Определенно не будет менять пространство кучи с постоянного на непостоянное, но это, конечно, приведет к большему потреблению всех необходимых дополнительных структур. Вы уже используете такое огромное количество данных / итераций, что, возможно, было бы лучше отказаться от подхода FP и просто поддерживать работающую длинную переменную. Вы уже доказали себе, что группа без почтового индекса удерживает вас в пределах памяти. :)
Ezekiel Victor 16 окт. 2014, в 06:25
0

Я понимаю, что это своего рода обходной путь (хотя и не совсем ненадежный; я имею в виду, что ключевое слово «var» существует по причине), но я предполагаю, что я говорю, что не вижу ничего, что подразумевает утечку памяти. Необходимо выполнить профилирование, чтобы доказать, что объем используемой памяти превышает ожидаемый объем для дополнительных структур, необходимых для использования zipWithIndex.
Ezekiel Victor 16 окт. 2014, в 06:28

Показать ещё 5 комментариев

Теги:

scala

scalaz

iteratee

1 ответ

Ещё вопросы

В итоге я сообщил об этом как о проблеме в Скалазе .
Это будет неинтересно, но вы можете попробовать -XX:+HeapDumpOnOutOfMemoryError и проанализировать дамп с помощью eclipse MAT eclipse.org/mat, чтобы увидеть, какая строка кода удерживается в массивах.
@huynhjl FWIW, я попытался проанализировать кучу с помощью JProfiler и MAT, но не смог полностью просмотреть все ссылки на анонимные классы функций и т. д. Scala действительно нужны специальные инструменты для такого рода вещей.
Что, если утечки нет, и просто для того, что вы делаете, требуется дико увеличивающийся объем памяти? Вы можете легко скопировать zipWithIndex без этой конкретной конструкции FP, просто поддерживая счетчик var на ходу.
@EzekielVictor Я не уверен, что понимаю комментарий. Вы предлагаете, чтобы добавление одного Long индекса на чанк изменило бы алгоритм с пространства кучи на постоянную и непостоянную? Версия без архивации явно использует пространство постоянной кучи, потому что она может «обрабатывать» столько кусков, сколько вы готовы ждать.
Извините, да, «дико увеличивающееся» подразумевает изменение сложности кучи пространства WRT. Я должен был просто сказать «соединение». Определенно не будет менять пространство кучи с постоянного на непостоянное, но это, конечно, приведет к большему потреблению всех необходимых дополнительных структур. Вы уже используете такое огромное количество данных / итераций, что, возможно, было бы лучше отказаться от подхода FP и просто поддерживать работающую длинную переменную. Вы уже доказали себе, что группа без почтового индекса удерживает вас в пределах памяти. :)
Я понимаю, что это своего рода обходной путь (хотя и не совсем ненадежный; я имею в виду, что ключевое слово «var» существует по причине), но я предполагаю, что я говорю, что не вижу ничего, что подразумевает утечку памяти. Необходимо выполнить профилирование, чтобы доказать, что объем используемой памяти превышает ожидаемый объем для дополнительных структур, необходимых для использования zipWithIndex.

Aaron Novstrup · Answer 1 · 2013-10-10T19-17-00.000Z

Это станет небольшим утешением для всех, кто придерживается более старого API iteratee, но недавно я проверил, что эквивалентный тест проходит против потока scalaz API. Это новый API обработки потоков, который предназначен для замены iteratee.

Для полноты, здесь тестовый код:

// create a stream containing `n` arrays with `sz` Ints in each one
def streamArrs(sz: Int, n: Int): Process[Task, Array[Int]] =
  (Process emit Array.fill(sz)(0)).repeat take n

(streamArrs(1 << 25, 1 << 14).zipWithIndex 
      pipe process1.chunk(4) 
      pipe process1.fold(0L) {
    (c, vs) => c + vs.map(_._1.length.toLong).sum
  }).runLast.run

Это должно работать с любым значением параметра n (при условии, что вы готовы подождать достаточно долго). Я тестировал с помощью массивов 2 ^ 14 32MiB (т.е. в общей сложности половину TiB памяти, выделенной с течением времени).