Задание Apache Beam остановлено в Google Cloud - загружен ЦП

мы пытаемся отладить, казалось бы, частично остановившееся задание Apache Beam, выполняющееся в Google Cloud. Наша задача читает сообщения из PubSub, преобразует их различными способами и передает результаты в несколько таблиц BigQuery. Части работы все еще активны - пара наших таблиц обновляется. Но другие части кажутся застопоренными из-за последнего обновления таблицы базы данных много часов назад (2:35 утра). К сожалению, мы не видим полезных исключений в логах. У нас есть только небольшое количество пользовательских сообщений журнала, отправляемых раз в минуту, и они прекратились, последнее в 2:35 утра. Примерно через час Beam увеличил количество рабочих на конвейер автомасштабирования, предположительно устраняя отставание в некоторых частях нашего конвейера.

Без полезных журналов единственные зацепки, которые у меня есть, - это то, что

  • у некоторых рабочих кажется, что Java-процесс застрял на 100% CPU

  • при просмотре / var / log / dataflow / windmill / этих рабочих отображается журнал WARNING и ERROR, обновленный в 2:36 утра, с такими сообщениями, как

    W0811 02:35:43.005868    19 work_service_client.cc:958] flowingestion-gcla-081020-08101355-256d-harness-jmb
5 Unable to update setup work item 5076700766800503996 error: DEADLINE_EXCEEDED: Http(504) Gateway Timeout
E0811 02:36:12.814573   208 work_service_client.cc:689] flowingestion-gcla-081020-08101355-256d-harness-jmb
5 Lost lease for work with id 1911643509568450683

а также

    E0811 02:36:12.821274   208 work_service_client.cc:689] flowingestion-gcla-081020-08101355-256d-harness-jmb
    5 Lost lease for work with id 8994368075509118540
    E0811 02:36:12.821322   208 work_service_client.cc:689] flowingestion-gcla-081020-08101355-256d-harness-jmb
    5 Lost lease for work with id 8994368075509118575

Есть ли у кого-нибудь совет, куда идти дальше?

Если кто-то из команды Google Cloud может взглянуть, наш идентификатор вакансии - 2017-08-10_13_55_26-6781083469468673800.


apache-beam google-cloud-platform google-cloud-dataflow
person gcla    schedule 11.08.2017    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Мы выяснили, что проблема связана с нашим собственным кодом ...

На одном из этапов нашего конвейера была предпринята попытка распаковать входные данные из PubSub. Что-то пошло не так, и распаковка застряла в цикле, связанном с процессором.

Чтобы определить это, мы сделали следующее:

  • Используя веб-интерфейс Google Compute Engine, мы просмотрели историю ЦП каждого рабочего за последние несколько часов. Из тех, что работали с момента запуска конвейера Apache Beam, несколько показали резкое увеличение загрузки ЦП примерно в 2:35 ночи (!)
  • мы подключились к одному из этих экземпляров с помощью ssh, запустили top и обнаружили процесс Java на 100% CPU.
  • мы не могли получить трассировку стека с помощью jstack - он сообщил, что процесс «не похоже на виртуальную машину Hotspot». Мы могли выдать SIGQUIT для pid для дампа потока, но дескриптор 1 был подключен к каналу. Итак, мы подключились к pid с помощью strace -f -s 256 -o strace.out, выдали SIGQUIT, а затем реконструировали дампы потоков из strace.out.

Результат показал, что один интересный поток (из более чем 300) работает в нашем собственном коде. Это выявило проблему.

Я хотел бы услышать, есть ли у кого-нибудь более совершенный способ сделать это :-)

person gcla    schedule 12.08.2017