Сбой контейнера пряжи администратора пряжи spring-xd

Версия: весна-xd-1.0.1

Распределенный режим: пряжа

Версия Hadoop: cdh5

Я изменил config/servers.yml так, чтобы он указывал на нужный applicationDir, zookeeper, hdfs, resourcemanager, redis, mysqldb.

Однако после нажатия, когда я запускаю администратора, через некоторое время его убивает пряжа. Я не понимаю, почему контейнер будет потреблять 31G памяти. Пожалуйста, направьте меня в правильном направлении, чтобы отладить эту проблему. Кроме того, как мне увеличить уровень журнала

В логах наблюдается следующая ошибка:

Got ContainerStatus=[container_id { app_attempt_id { application_id { id: 432 cluster_timestamp: 1415816376410 } tryId: 1 } id: 2 } состояние: диагностика C_COMPLETE: «Контейнер [pid=19374,containerID=container_1415816376410_0432_01_0000» : 1,2 ГБ из 1 ГБ физической памяти; использовано 31,7 ГБ из 2,1 ГБ виртуальной памяти. Уничтожение контейнера.\nДамп дерева процессов для container_1415816376410_0432_01_000002 :\n\t|- PID PPID PGRPID SESSID CMD_NAME USER_MODE_TIME(MILLIS) SYSTEM_TIME(MILLIS) VMEM_USAGE(BYTES) RSSMEM_USAGE(PAGES) FULL_CMD_LINE\n\t|- 19381 19374 19374 19374 (java) 3903 121 33911242752 303743 /usr/java/jdk1.7.0/45-cloud DxdHomeDir=./spring-xd-yarn-1.0.1.RELEASE.zip -Dxd.module.config.location=file:./modules-config.zip/ -Dspring.application.name=admin -Dspring.config.location =./servers.yml org.springframework.xd.dirt.server.AdminServerApplication \n\t|- 19374 24125 19374 19374 (bash) 0 0 11080499 2 331 /bin/bash -c /usr/java/jdk1.7.0_45-cloudera/bin/java -DxdHomeDir=./spring-xd-yarn-1.0.1.RELEASE.zip -Dxd.module.config.location= файл:./modules-config.zip/ -Dspring.application.name=admin -Dspring.config.location=./servers.yml org.springframework.xd.dirt.server.AdminServerApplication 1>/var/log/hadoop- пряжа / контейнер / Application_1415816376410_0432 / Container_1415816376410_0432_01_00410_0432_01_000002 / Container.Stout 2> /var/log/hadoop-yarn/container/Application_1415816376410_0432/container_1415816376410_0432_01_000002/container.stderr \ n \ ncontainer погибло по запросу. Код выхода: 143\nКонтейнер вышел с ненулевым кодом выхода 143\n" exit_status: 143


person sagar    schedule 21.11.2014    source источник
comment
Не могли бы вы предоставить больше информации об окружающей среде, такой как версия Java, ОС, версия cdh5 и т. д. Также, какие типы потоков / заданий у вас там выполнялись и сколько времени на самом деле потребовалось пряже, чтобы убить этот контейнер.   -  person Janne Valkealahti    schedule 21.11.2014
comment
cdh5.0.1, os: centos 6, никаких пользовательских заданий. это прямо распаковка zip-файла весенней пряжи, а затем с изменениями конфигурации. Контейнер администратора работает 34 секунды, а затем завершается сбоем.   -  person sagar    schedule 21.11.2014
comment
›INFO monitor.IntegrationMBeanExporter: регистрация bean-компонентов для представления JMX при запуске ›INFO tomcat.TomcatEmbeddedServletContainerFactory: сервер инициализирован портом: 9393 xxxxx INFO core.StandardService: запуск службы Tomcat xxxxx INFO core.StandardEngine: запуск Servlet Engine: Apache Tomcat/7.0.55 Аннотация NFO.AnnotationConfigApplicationContext: Закрытие org.springframework.context.annotation.AnnotationConfigApplicationContext@3e990b4: дата запуска [xxx]; корень контекстной иерархии   -  person sagar    schedule 21.11.2014
comment
Похоже, у вас заканчивается реальная физическая память. Каково ваше свойство yarn.scheduler.maximum-allocation-mb? Я знаю, что мы видели проблемы с запуском приложений YARN на виртуальной машине Cloudera Quickstart с конфигурацией по умолчанию. См. github.com/spring-projects/spring-hadoop-samples/issues. /13 и github .com/spring-projects/spring-hadoop-samples/tree/master/ для получения дополнительной информации.   -  person Thomas Risberg    schedule 22.11.2014
comment
Пробовал различные трюки, чтобы воспроизвести это без везения. Можно попытаться получить более подробный дамп памяти процесса, чтобы увидеть, куда идет vmem. В этих сообщениях есть хорошая дискуссия по этому поводу; stackoverflow.com/questions/561245/ и stackoverflow.com/questions/6240985/   -  person Janne Valkealahti    schedule 24.11.2014
comment
Кажется, есть и другие отчеты, в которых у людей обычно возникают проблемы с centos6 в пряже. Упоминается в blog.cloudera .com/blog/2014/04/, что ведет к ibm.com/developerworks/community/blogs/kevgrig/entry/. Установка для yarn.nodemanager.vmem-check-enabled значения false является обходным путем, если проблема действительно существует в версии Centos.   -  person Janne Valkealahti    schedule 24.11.2014
comment
yarn.scheduler.maximum-allocation-mb установлено на 96 ГБ на 100+ ГБ ОЗУ. все остальные мои работы с mapreduce работают нормально. Все остальные задания в улье работают нормально.   -  person sagar    schedule 24.11.2014
comment
Спасибо @JanneValkealahti. Я пробовал это. Похоже, что glibc виноват. У меня есть рабочий админ и контейнер. Однако виртуальная память, о которой сообщил контейнер администратора, составляет 31 ГБ.   -  person sagar    schedule 24.11.2014


Ответы (1)


Да, с текущей версией 1.1.0/1.1.1 вам не нужно явно запускать администратора. Контейнеры и администратор будут созданы пряжей при отправке приложения.

person kalyan chakri    schedule 16.04.2015