Куча редуктора с памятью

Question

Итак, у меня есть несколько сценариев Pig, которые продолжают умирать, уменьшая фазу работы с ошибками, которые куча Java продолжает выходить из космоса. К этой дате мое единственное решение заключалось в увеличении количества редукторов, но это, похоже, не делает меня надежным. Теперь частью этого может быть только огромный рост данных, которые мы получаем, но не может быть уверен.

Я думал об изменении порогового значения разлива, не могу вспомнить настройку, но не уверен, что они помогут или просто замедляют ее. Что еще я могу посмотреть на решение этой проблемы?

На стороне примечания, когда это начинает происходить, я также получаю ошибки в том, что bash не может получить память, поскольку я предполагаю, что это операция разлива. Будет ли это у Hadoop-узла нехваткой памяти? Если бы это было просто уменьшение размера кучи на этих коробках, это решение?

Редактировать 1
1) Свиньи 0.8.1
2) Только UDF является Eval UDF, который смотрит на отдельных строк без каких-либо пакетов или карт.
3) Я не заметил, что есть горячие точки с плохим ключом. Я также использую шкалу простых чисел, чтобы уменьшить эту проблему.

Edit 2
Здесь ошибка в вопросе:
2012-01-04 09:58:11,179 FATAL org.apache.hadoop.mapred.TaskRunner: attempt_201112070707_75699_r_000054_1 : Map output copy failure : java.lang.OutOfMemoryError: Java heap space at org.apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.shuffleInMemory(ReduceTask.java:1508) at org.apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.getMapOutput(ReduceTask.java:1408) at org.apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.copyOutput(ReduceTask.java:1261) at org.apache.hadoop.mapred.ReduceTask$ReduceCopier$MapOutputCopier.run(ReduceTask.java:1195)

Здесь ошибка Баш я получаю:
java.io.IOException: Task: attempt_201112070707_75699_r_000054_0 - The reduce copier failed at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:380) at org.apache.hadoop.mapred.Child.main(Child.java:170) Caused by: java.io.IOException: Cannot run program "bash": java.io.IOException: error=12, Cannot allocate memory at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) at org.apache.hadoop.util.Shell.runCommand(Shell.java:149) at org.apache.hadoop.util.Shell.run(Shell.java:134) at org.apache.hadoop.fs.DF.getAvailable(DF.java:73) at org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext.getLocalPathForWrite(LocalDirAllocator.java:329) at org.apache.hadoop.fs.LocalDirAllocator.getLocalPathForWrite(LocalDirAllocator.java:124) at org.apache.hadoop.mapred.MapOutputFile.getInputFileForWrite(MapOutputFile.java:160) at org.apache.hadoop.mapred.ReduceTask$ReduceCopier$InMemFSMergeThread.doInMemMerge(ReduceTask.java:2537) at org.apache.hadoop.mapred.ReduceTask$ReduceCopier$InMemFSMergeThread.run(ReduceTask.java:2501)

Answer 1

Очевидно, что вы работаете из памяти где-то. Увеличение количества редукторов на самом деле вполне разумно. Посмотрите статистику на графическом интерфейсе JobTracker и посмотрите, сколько байтов выходит из устройства отображения. Разделите это на количество задач сокращения, и это довольно грубая оценка того, что получает каждый редуктор. К сожалению, это работает только в долгосрочной перспективе, если ваши ключи распределены равномерно.

В некоторых случаях JOIN (особенно реплицированный вид) вызовет такой тип проблемы. Это происходит, когда у вас есть «горячая точка» определенного ключа. Например, скажем, что вы делаете какое-то соединение, и один из этих ключей появляется в 50% случаев. Независимо от того, какой редуктор повезет справиться с этим ключом, он будет схвачен. Возможно, вам захочется выяснить, какие клавиши вызывают горячие точки и обрабатывают их соответственно. По моим данным, обычно эти горячие точки бесполезны. Чтобы узнать, что жарко, просто сделайте GROUP BY и COUNT и выясните, что появляется много. Тогда, если это не полезно, просто FILTER.

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

Я обнаружил, что более новые версии Pig (.8 и .9 особенно) имеют гораздо меньше проблем с памятью. У меня было довольно много случаев выбега из кучи в .7. Эти версии имеют гораздо лучшее распространение на обнаружение диска, так что, если он собирается взорвать кучу, он достаточно умен, чтобы разлиться на диск.

---

Для меня, чтобы быть более полезным, вы можете разместить свой Pig сценарий, а также отметить, что версия Свиньи вы используете.

Answer 2

Я не опытный пользователь или что-то еще, но я столкнулся с подобной проблемой при запуске заданий на виртуальную машину.

Моя особая проблема заключалась в том, что виртуальная машина не имела никакого пространства подкачки, она в конечном итоге исчерпала бы память. Я предполагаю, что вы пытаетесь сделать это в правильной конфигурации Linux, но было бы больно делать: free -m и посмотреть, что получилось в результате, может быть, проблема связана с тем, что у вас слишком мало настроенной памяти памяти.

Просто подумайте, дайте мне знать, если это поможет. Удачи вам в вашей проблеме!