--- metadata: - name: generator content: Diplodoc Platform v5.63.3 alternate: - https://ytsaurus.tech/docs/en/flow/devops/troubleshooting.md - https://ytsaurus.tech/docs/ru/flow/devops/troubleshooting.md - href: https://ytsaurus.tech/docs/ru/flow/devops/troubleshooting.md type: text/markdown title: Markdown version - href: https://ytsaurus.tech/docs/ru/llms.txt?revision=181542d8c2d9f36be925894a517db8203cafae65 rel: describedby --- > **Documentation Index:** Fetch the complete configuration index at https://ytsaurus.tech/docs/ru/llms.txt?revision=181542d8c2d9f36be925894a517db8203cafae65 # Типовые проблемы YTsaurus Flow Начните с [состояния, flow view и логов](https://ytsaurus.tech/docs/ru/flow/devops/diagnostics.md). Запишите кластер, путь пайплайна, ID операции и джобы, время первой ошибки. Изменяйте спеку или перезапускайте операцию только после того, как причина локализована: повторный запуск может уничтожить логи живой джобы. ## Падающие джобы {#failed-jobs} **Симптом:** контроллер повторно планирует джобу, а она завершается ошибкой. Прочитайте первую ошибку в [логе контроллера](https://ytsaurus.tech/docs/ru/flow/devops/vanilla/diagnostics/logs.md) и получите `stderr` завершившейся джобы по её ID. Если это ошибка пользовательского кода или спеки, воспроизведите её на тестовом пайплайне и исправьте; при OOM сравните лимит памяти с фактическим потреблением и снимите [профиль памяти](https://ytsaurus.tech/docs/ru/flow/devops/profiling.md#orchid). Не повышайте лимиты без проверки причины. ## Повторяемые ошибки {#retryable-errors} **Симптом:** джобы остаются живыми, но в логах постоянно повторяется ошибка обращения к YTsaurus или внешнему приёмнику. Найдите первое повторяющееся сообщение и проверьте доступность цели, права и квоту. Если ошибка временная, наблюдайте, сокращается ли лаг после восстановления сервиса. Если нет, исправьте адрес или учётные данные в конфигурации и повторите развёртывание по [правилам релиза](https://ytsaurus.tech/docs/ru/flow/devops/vanilla/releases.md). ## Зависшая обработка или дрейн {#hung-processing} **Симптом:** `stop-pipeline` долго оставляет пайплайн в `draining` либо выход перестаёт изменяться в `working`. По `get-flow-view` найдите компьютейшен с заполненным входным или выходным буфером, затем проверьте его воркер-лог. Снимите [бектрейсы тредов и файберов](https://ytsaurus.tech/docs/ru/flow/devops/profiling.md#backtraces) до перезапуска. Если зависает пользовательский C++ код, проверьте ожидания и перехват `catch (...)`: исключения управления файберами могут не наследоваться от `std::exception`. Исправьте код и сначала проверьте его в тестовом окружении. Для обновления, которое не может задренироваться из-за падающих джоб, следуйте [процедуре восстановления после неудачной спеки](https://ytsaurus.tech/docs/ru/flow/devops/vanilla/releases.md#recovery-from-bad-spec). ## Медленная обработка {#slow-processing} **Симптом:** лаг растёт при работающих джобах. Сравните время частей эпох и размеры буферов, если эти метрики доступны; без панели используйте `get-flow-view` и логи проблемной партиции. Начните с компьютейшена ближе к выходу, у которого очередь или обработка растут. Поскольку все сообщения между `computation`-ами пайплайна хранятся в памяти, их не может храниться слишком много, поэтому более поздние в пайплайне `computation`-ы могут тормозить более ранние. Поэтому стоит расследовать в первую очередь тормоза более поздних `computation`-ов. Если время уходит на пользовательский `Process`, снимите [CPU-профиль](https://ytsaurus.tech/docs/ru/flow/devops/profiling.md#cpu) и проверьте внешние вызовы. Один горячий ключ нельзя разгрузить простым увеличением числа партиций: сначала уменьшите работу для этого ключа. При переполнении выходного буфера проверьте следующий компьютейшен, прежде чем увеличивать буфер. Если ожидание вызвано `Input.ReadWindow`, проверьте тормозящую партицию ниже по графу и настройки окна чтения; увеличивайте окно только при намеренно редких коммитах. ## Медленная работа с YTsaurus {#slow-yt} **Симптом:** в логах и времени эпох преобладают ожидания чтения или записи таблиц. Проверьте нагрузку, состояние таблетов и ошибки конкретных таблиц через доступные инструменты кластера; сопоставьте их с [FAQ по динамическим таблицам](https://ytsaurus.tech/docs/ru/user-guide/dynamic-tables/faq.md). При перекосе нагрузки проверьте шарды и распределение ключей. Перешардирование и смену режима обработки планируйте отдельно: они меняют нагрузку и, возможно, гарантии обработки. ## Ошибки троттлера {#throttler-errors} **Симптом:** джоба получает исключения от `Throttle()` либо часто ждёт `Input.Throttle`. Сравните запрошенную скорость с квотой [Distributed Throttler](https://ytsaurus.tech/docs/ru/flow/concepts/distributed_throttler.md) и проверьте доступность контроллера. Если спрос существенно выше квоты, уменьшите нагрузку или запросите подходящий лимит; если недоступен контроллер, сначала восстановите связь. Не отключайте троттлер как обход ошибки. ## Зомби-процессы и несовпадение версий {#zombie-processes} **Симптом:** после релиза новые джобы не назначаются или пайплайн переходит в `paused`, а в блоке **Messages** появляется сообщение `binary mismatch`. Попытка обновить спеку может завершиться ошибкой `FlowCoreTargetMismatch`. Сравните версии раннера, контроллера и воркеров и проверьте, остались ли процессы старой операции. Дождитесь завершения переключения или заново запустите релиз единым набором бинарей. [Сброс проверки версий](https://ytsaurus.tech/docs/ru/flow/devops/vanilla/releases.md#flow-core-target-workarounds) допустим только как контролируемое восстановление после проверки всех процессов: он снимает защиту от зомби-процессов.