Влияет ли задержка системы на автоматическое масштабирование?
Google на самом деле не раскрывает специфику своего алгоритма автоматического масштабирования. Однако, как правило, он основан на загрузке ЦП , пропускной способности и отставании . Поскольку вы используете Pub / Sub, резервирование само по себе должно основываться на количестве неподтвержденных сообщений. Тем не менее, скорость, с которой они потребляются (то есть пропускная способность на этапе чтения Pub / Sub ), также принимается во внимание. Теперь пропускная способность в целом относится к скорости, с которой каждая ступень обрабатывает входные байты. Что касается использования ЦП, если вышеупомянутое не «работает гладко», 60% -ное использование уже слишком высоко. Таким образом, системная задержка на некотором этапе может интерпретироваться как пропускная способность этого этапа и, следовательно, должна влиять на автоматическое масштабирование. Опять же, эти два не всегда должны быть объединены. Например, если работник застревает из-за горячей клавиши , системная задержка высока, но автоматического масштабирования нет, поскольку работа не распараллеливается. В общем, все зависит.
Если так, есть ли какие-либо решения или способы отладки этой проблемы?
Наиболее важными инструментами, которые у вас под рукой, являются график выполнения, ведение журнала стека-драйвера и мониторинг стека-драйвера. Из мониторинга следует учитывать метрики jvm , , вычисление и потока данных . gcloud dataflow jobs describe также может быть полезно, главным образом, чтобы увидеть, как объединяются шаги, и, соответственно, посмотреть, какие шаги выполняются на одном и том же рабочем месте, например:
gcloud dataflow jobs describe --full $JOB_ID --format json | jq '.pipelineDescription.executionPipelineStage[] | {"stage_id": .id, "stage_name": .name, "fused_steps": .componentTransform }'
Мониторинг Stackdriver раскрывает все три основных компонента автоматического масштабирования.
Теперь то, как вы собираетесь воспользоваться вышеизложенным, очевидно, зависит от проблемы. В вашем случае, на первый взгляд, я бы сказал, что если вы можете работать без автомасштабирования и 40 рабочих, вы обычно ожидаете, что вы можете сделать то же самое с автоматическим масштабированием, когда вы установили maxNumWorkers на 40. Опять же, количество сообщений само по себе не говорит полной истории, их размер / содержание также имеет значение. Я думаю, вам следует начать с анализа вашего графика, проверить, какой шаг имеет наибольшую задержку, посмотреть, каково соотношение ввода / вывода, и проверить сообщения с серьезностью> = ПРЕДУПРЕЖДЕНИЕ в ваших журналах. Если вы поделились чем-нибудь из этого, возможно, мы могли бы найти что-то более конкретное.