У меня есть искровое задание на производстве, которое планируется запускать в режиме клиента каждый день (я признаю, что режим клиента не является надежным способом выполнения заданий на производстве, но именно так настроена работа в настоящий момент).
Работа застряла, когда она начала выполняться 24 ноября, и с тех пор работала до сегодняшнего дня (29 ноября), когда мы заметили проблему и убили работу.В среднем на выполнение задания уходит 2 минуты, и я подтвердил, что для выполнения задания от 24 ноября объем работы невелик, поэтому он должен был быть выполнен примерно за 2-3 минуты.
При просмотре журналов этого долго выполняемого задания я вижу ниже одну последнюю ошибку в файле журнала, а затем журнал показывает, что задание застряло на этапе 1
[Stage 1:> (0 + 1) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 1) / 3]18/11/22 10:22:36 ERROR client.TransportClient: Failed to send RPC 8301663055171047224 to /15.90.21.22:33226: java.nio.channels.ClosedChannelException
java.nio.channels.ClosedChannelException
at io.netty.channel.AbstractChannel$AbstractUnsafe.write(...)(Unknown Source)
18/11/22 10:22:36 ERROR cluster.YarnScheduler: Lost executor 1 on prodsr000001000.netsmart.com: Slave lost
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
[Stage 1:===================> (1 + 0) / 3]
..
..
..
..
..
..thousand of more same lines
[Stage 1:===================> (1 + 0) / 3]
Исходя из вышеприведенной ошибки, журналы показывают, что исполнитель на ведомом устройстве был потерян, который должен был определить мастер приложения (эта установка запускается на YARN) и запустил потерянного исполнителя на каком-то другом узле.Тогда почему работа застряла на одной сцене и одной и той же задаче более пяти дней.Цените помощь здесь.
Кроме того, если мастер приложения не смог выполнить задание или имел какие-либо ограничения ресурсов, разве он не должен был просто убить задание вместо того, чтобы позволить ему находиться в зависшем и когда-либо выполняющемся состоянии?
Имеет ли это какое-то отношение к клиентскому режиму, в котором задание было отправлено?
У меня нет доступа к производственному веб-интерфейсу Spark для дальнейшего изучения проблемы, если это было возможно.