2016-11-26 5 views
1

Наша пряжа убивает все выполняемые работы через ровно 1 час. Не имеет значения, если это искра или работа Sqoop (mapreduce).Пряжа Автоматически убивает все вакансии ровно через 1 час без ошибок

Ищет предложения по потенциальной причине.

Мы используем распределение хаоса HDP 2.5.x на кластере из 4 узлов.

Это, как я бегу sqoop работу

nohup sqoop-import -D mapred.task.timeout=0 --direct --connect jdbc:oracle:thin:@HOST:Port:DB --username USERNAME --password PASS --target-dir /prod/directory --table TABLE_NAME --verbose -m 25 --split-by TABLE_NAME.COLUMN --as-parquetfile --fields-terminated-by "\t" > temp.log 2>&1 & 

Все это говорит как ниже

16/11/26 01:40:49 INFO mapreduce.Job: map 42% reduce 0% 
16/11/26 01:41:44 INFO mapreduce.Job: map 0% reduce 0% 
16/11/26 01:41:44 INFO mapreduce.Job: Job job_1480141487938_0001 failed with state KILLED due to: Application killed by user. 
16/11/26 01:41:44 INFO mapreduce.Job: Counters: 0 
16/11/26 01:41:44 WARN mapreduce.Counters: Group FileSystemCounters is deprecated. Use org.apache.hadoop.mapreduce.FileSystemCounter instead 
16/11/26 01:41:44 INFO mapreduce.ImportJobBase: Transferred 0 bytes in 3,628.6498 seconds (0 bytes/sec) 
16/11/26 01:41:44 WARN mapreduce.Counters: Group org.apache.hadoop.mapred.Task$Counter is deprecated. Use org.apache.hadoop.mapreduce.TaskCounter instead 
16/11/26 01:41:44 INFO mapreduce.ImportJobBase: Retrieved 0 records. 
16/11/26 01:41:44 DEBUG util.ClassLoaderStack: Restoring classloader: [email protected] 
16/11/26 01:41:44 ERROR tool.ImportTool: Error during import: Import job failed! 

журнал приложений Пряжа

yarn logs -applicationId application_1480141487938_0001|grep -B2 -A10 "ERROR " 
16/11/26 03:05:39 INFO impl.TimelineClientImpl: Timeline service address: http://HostName:8188/ws/v1/timeline/ 
16/11/26 03:05:39 INFO client.RMProxy: Connecting to ResourceManager at HostName/HostIp:8050 
16/11/26 03:05:39 INFO client.AHSProxy: Connecting to Application History server at HostName/HostIp:10200 
16/11/26 03:05:40 INFO zlib.ZlibFactory: Successfully loaded & initialized native-zlib library 
16/11/26 03:05:40 INFO compress.CodecPool: Got brand-new decompressor [.deflate] 
2016-11-26 00:41:33,284 INFO [RMCommunicator Allocator] org.apache.hadoop.mapreduce.v2.app.rm.RMContainerRequestor: getResources() for application_1480141487938_0001: ask=1 release= 2 newContainers=0 finishedContainers=2 resourcelimit=<memory:20480, vCores:1> knownNMs=4 
2016-11-26 00:41:33,285 INFO [RMCommunicator Allocator] org.apache.hadoop.mapreduce.v2.app.rm.RMContainerAllocator: Received completed container container_e09_1480141487938_0001_01_000028 
2016-11-26 00:41:33,285 ERROR [RMCommunicator Allocator] org.apache.hadoop.mapreduce.v2.app.rm.RMContainerAllocator: Container complete event for unknown container id container_e09_1480141487938_0001_01_000028 
2016-11-26 00:41:33,285 INFO [RMCommunicator Allocator] org.apache.hadoop.mapreduce.v2.app.rm.RMContainerAllocator: Received completed container container_e09_1480141487938_0001_01_000029 
2016-11-26 00:41:33,285 ERROR [RMCommunicator Allocator] org.apache.hadoop.mapreduce.v2.app.rm.RMContainerAllocator: Container complete event for unknown container id container_e09_1480141487938_0001_01_000029 
2016-11-26 00:41:33,686 INFO [Socket Reader #1 for port 41553] SecurityLogger.org.apache.hadoop.ipc.Server: Auth successful for job_1480141487938_0001 (auth:SIMPLE) 
2016-11-26 00:41:33,697 INFO [IPC Server handler 6 on 41553] org.apache.hadoop.mapred.TaskAttemptListenerImpl: JVM with ID : jvm_1480141487938_0001_m_9895604650011 asked for a task 
2016-11-26 00:41:33,698 INFO [IPC Server handler 6 on 41553] org.apache.hadoop.mapred.TaskAttemptListenerImpl: JVM with ID: jvm_1480141487938_0001_m_9895604650011 given task: attempt_1480141487938_0001_m_000024_0 
2016-11-26 00:41:37,542 INFO [IPC Server handler 19 on 41553] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Progress of TaskAttempt attempt_1480141487938_0001_m_000000_0 is : 0.0 
2016-11-26 00:41:38,793 INFO [IPC Server handler 22 on 41553] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Progress of TaskAttempt attempt_1480141487938_0001_m_000001_0 is : 0.0 
2016-11-26 00:41:38,811 INFO [IPC Server handler 23 on 41553] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Progress of TaskAttempt attempt_1480141487938_0001_m_000006_0 is : 0.0 
2016-11-26 00:41:38,939 INFO [IPC Server handler 28 on 41553] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Progress of TaskAttempt attempt_1480141487938_0001_m_000007_0 is : 0.0 
2016-11-26 00:41:40,568 INFO [IPC Server handler 22 on 41553] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Progress of TaskAttempt attempt_1480141487938_0001_m_000000_0 is : 0.0 
2016-11-26 00:41:41,812 INFO [IPC Server handler 24 on 41553] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Progress of TaskAttempt attempt_1480141487938_0001_m_000001_0 is : 0.0 
2016-11-26 00:41:41,832 INFO [IPC Server handler 25 on 41553] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Progress of TaskAttempt attempt_1480141487938_0001_m_000006_0 is : 0.0 

Rm Audit Log

2016-11-26 01:41:43,359 INFO resourcemanager.RMAuditLogger: USER=yarn IP=HostIp OPERATION=Kill Application Request TARGET=ClientRMService RESULT=SUCCESS APPID=application_1480141487938_0001 CALLERCONTEXT=CLI 

Я уже изменил каждое значение, которое я могу найти в Ambari от 3600 до некоторого большего значения, перезапустил кластер и перезапустил скрипт. Тем не менее, точно работа убивается через 1 час как для работы в sqoop, так и для искры.

Edit:

yarn logs -show_application_log_info -applicationId application_1480141487938_0001 

показывает только контейнер идентификаторов от 1 до 27. Так, где я могу найти журнал/ошибка для контейнера 28 и 29?

+0

Вы узнали причину этого? Происходит у нас на кластере CDH 5.5. – morfious902002

+0

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

+1

Для нас это был тайм-аут сеанса сервера Livy, который убивал работу Spark Batch. Это ошибка, которая будет исправлена ​​в следующем выпуске. – morfious902002

ответ

0

Мы не смогли полностью изолировать проблему, только потому, что она была связана с сетью. Оказывается, даже когда я увеличил все возможные параметры с 3600 до более, на стороне клиента/узла какое-то сердцебиение было установлено на 3600 секунд и не обновлялось.

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

Поскольку в документах hadoop, Hortonworks и Cloudera действительно отсутствует каждый конкретный порт и спецификация протокола, которая должна/должна быть включена в каждой версии, нам, наконец, пришлось отключить iptables, чтобы решить эту проблему.