Я выполняю поиск BFS через сайт Википедии (испанское издание). Я преобразовал дамп (https://dumps.wikimedia.org/eswiki/20160601) в файл, который может быть прочитан с помощью Giraph.
BFS ищет пути, и все в порядке, пока не застрянет в какой-то точке четвертого супершага.
Я использую кластер из 5 узлов (4 подчиненных ядра, 1 главный) на AWS. Каждый узел представляет собой экземпляр r3.8xlarge ec2. Команда для выполнения BFS такова:
/home/hadoop/bin/yarn jar /home/hadoop/giraph/giraph.jar ar.edu.info.unlp.tesina.lectura.grafo.BusquedaDeCaminosNavegacionalesWikiquote -vif ar.edu.info.unlp.tesina.vertice.estructuras.IdTextWithComplexValueInputFormat -vip /user/hduser/input/grafo-wikipedia.txt -vof ar.edu.info.unlp.tesina.vertice.estructuras.IdTextWithComplexValueOutputFormat -op /user/hduser/output/caminosNavegacionales -w 4 -yh 120000 -ca giraph.useOutOfCoreMessages=true,giraph.metrics.enable=true,giraph.maxMessagesInMemory=1000000000,giraph.isStaticGraph=true,giraph.logLevel=Debug
Каждый контейнер имеет 120 ГБ (почти). Я использую ограничение в 1000 миллионов сообщений в outOfCore, потому что я думал, что это проблема, но, видимо, это не так.
Это основные журналы (кажется, что они ждут завершения работы, но они просто не ... и хранятся так вечно...):
6/08/26 00:43:08 INFO yarn.GiraphYarnTask: [STATUS: task-3] MASTER_ZOOKEEPER_ONLY - 0 finished out of 4 on superstep 4
16/08/26 00:43:08 DEBUG master.BspServiceMaster: barrierOnWorkerList: Got finished worker list = [], size = 0, worker list = [Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=0, port=30000), Worker(hostname=ip-172-31-29-16.ec2.internal, MRtaskID=1, port=30001), Worker(hostname=ip-172-31-29-15.ec2.internal, MRtaskID=2, port=30002), Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=4, port=30004)], size = 4 from /_hadoopBsp/giraph_yarn_application_1472168758138_0002/_applicationAttemptsDir/0/_superstepDir/4/_workerFinishedDir
16/08/26 00:43:08 INFO yarn.GiraphYarnTask: [STATUS: task-3] MASTER_ZOOKEEPER_ONLY - 0 finished out of 4 on superstep 4
16/08/26 00:43:08 DEBUG zk.PredicateLock: waitMsecs: Wait for 10000
16/08/26 00:43:18 DEBUG zk.PredicateLock: waitMsecs: Got timed signaled of false
...thirty times same last two lines...
...
6/08/26 00:43:08 INFO yarn.GiraphYarnTask: [STATUS: task-3] MASTER_ZOOKEEPER_ONLY - 0 finished out of 4 on superstep 4
16/08/26 00:43:08 DEBUG master.BspServiceMaster: barrierOnWorkerList: Got finished worker list = [], size = 0, worker list = [Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=0, port=30000), Worker(hostname=ip-172-31-29-16.ec2.internal, MRtaskID=1, port=30001), Worker(hostname=ip-172-31-29-15.ec2.internal, MRtaskID=2, port=30002), Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=4, port=30004)], size = 4 from /_hadoopBsp/giraph_yarn_application_1472168758138_0002/_applicationAttemptsDir/0/_superstepDir/4/_workerFinishedDir
16/08/26 00:43:08 INFO yarn.GiraphYarnTask: [STATUS: task-3] MASTER_ZOOKEEPER_ONLY - 0 finished out of 4 on superstep 4
И во всех воркерах нет информации о том, что происходит (тестирую это с giraph.logLevel=Debug, т.к. с дефолтным уровнем лога giraph я пропал), а воркеры говорят это снова и снова:
16/08/26 01:05:08 INFO utils.ProgressableUtils: waitFor: Future result not ready yet java.util.concurrent.FutureTask@7392f34d
16/08/26 01:05:08 INFO utils.ProgressableUtils: waitFor: Waiting for org.apache.giraph.utils.ProgressableUtils$FutureWaitable@34a37f82
Перед началом супершага 4 информация о каждом воркере была следующей:
16/08/26 00:43:08 INFO yarn.GiraphYarnTask: [STATUS: task-2] startSuperstep: WORKER_ONLY - Attempt=0, Superstep=4
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: startSuperstep: addressesAndPartitions[Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=0, port=30000), Worker(hostname=ip-172-31-29-16.ec2.internal, MRtaskID
=1, port=30001), Worker(hostname=ip-172-31-29-15.ec2.internal, MRtaskID=2, port=30002), Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=4, port=30004)]
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 0 Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=0, port=30000)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 1 Worker(hostname=ip-172-31-29-16.ec2.internal, MRtaskID=1, port=30001)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 2 Worker(hostname=ip-172-31-29-15.ec2.internal, MRtaskID=2, port=30002)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 3 Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=4, port=30004)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 4 Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=0, port=30000)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 5 Worker(hostname=ip-172-31-29-16.ec2.internal, MRtaskID=1, port=30001)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 6 Worker(hostname=ip-172-31-29-15.ec2.internal, MRtaskID=2, port=30002)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 7 Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=4, port=30004)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 8 Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=0, port=30000)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 9 Worker(hostname=ip-172-31-29-16.ec2.internal, MRtaskID=1, port=30001)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 10 Worker(hostname=ip-172-31-29-15.ec2.internal, MRtaskID=2, port=30002)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 11 Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=4, port=30004)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 12 Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=0, port=30000)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 13 Worker(hostname=ip-172-31-29-16.ec2.internal, MRtaskID=1, port=30001)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 14 Worker(hostname=ip-172-31-29-15.ec2.internal, MRtaskID=2, port=30002)
16/08/26 00:43:08 DEBUG worker.BspServiceWorker: 15 Worker(hostname=ip-172-31-29-14.ec2.internal, MRtaskID=4, port=30004)
16/08/26 00:43:08 DEBUG graph.GraphTaskManager: execute: Memory (free/total/max) = 92421.41M / 115000.00M / 115000.00M
Я не знаю, что именно не работает:
- я знаю, что у всех контейнеров есть доступная память, на узлах данных я проверяю, что у каждого из них было доступно около 50 ГБ.
- Я не уверен, достиг ли я какого-то предела в использовании outOfCore. Я знаю, что писать сообщения слишком быстро опасно с версией Giraph 1.1, но если я достигну этого предела, я полагаю, что контейнер выйдет из строя, верно?
- Может быть, соединений для клиента zookeeper недостаточно? Я читал, что, возможно, значение по умолчанию 60 в zookeeper для maxClientCnxns слишком мало для контекста, такого как AWS, но я не полностью осведомлен о взаимосвязи между Giraph и Zookeeper для начала изменения значений конфигурации по умолчанию.
- Может быть, мне нужно настроить конфигурацию outOfCore? Используя giraph.maxNumberOfOpenRequests и giraph.waitForRequestsConfirmation=true, как кто-то рекомендует здесь (http://mail-archives.apache.org/mod_mbox/giraph-user/201209.mbox/%3CCC775449.2C4B%[email protected]%3E) ?
- Должен ли я настроить конфигурацию netty? У меня конфигурация по умолчанию, но я считаю, что, возможно, будет достаточно использовать только 8 клиентских потоков netty и 8 потоков сервера, поскольку у меня всего несколько рабочих процессов, и, возможно, слишком много потоков netty создают накладные расходы, которые делает все это приложение. застрявший
- Использование giraph.useBigDataIOForMessages=true мне тоже не помогло, я знаю, что каждая вершина получает 100 M или более сообщений, и это свойство должно быть полезным, но в любом случае не имеет никакого значения
Как вы, возможно, подозреваете, у меня слишком много гипотез, поэтому я ищу помощи, чтобы двигаться в правильном направлении.
РЕДАКТИРОВАТЬ 1: Использование giraph.maxNumberOfOpenRequests и giraph.waitForRequestsConfirmation=true не решило проблему
РЕДАКТИРОВАТЬ 2: я продублировал потоки netty и назначил двойное значение исходного размера буферам netty, и никаких изменений.
РЕДАКТИРОВАТЬ 3: я сжал сообщения, 1000 в 1, и получил намного меньше сообщений, но тем не менее, те же конечные результаты.
