ME
Да, вроде оно, спасибо. Удобно, что 1 строчкой можно добавить.
/home/airflow/.local/lib/python3.8/site-packages/Size: a a a
2020 December 03
ME
Для официального образа будет каталог только другой,
2020 December 04
АС
Всем привет! Тестируем перформанс Airflow - пытаемся выжать максимум по количеству task instance, способных одновременно быть в статусе running.
Столкнулись со странной ошибкой:
0 task instances в статусе running, но в базе (Postgres) висит 1000 connections, которые ещё что-то пишут туда.
Сначала думали, что проблема в CeleryWorkers и конфиге worker_autoscale=800,200. У нас 5 воркеров, при таком конфиге они держат запущенными по 200 сабпроцессов каждый. Как раз 1000 получается.
Но при запуске дагов максимум достигается 600 тасок в running (600 слотов), дальше упираемся в limit коннекшенов базе. То есть открываются новые 600 коннекшенов в дополнение к этим левым 1000.
Есть идеи?
Столкнулись со странной ошибкой:
0 task instances в статусе running, но в базе (Postgres) висит 1000 connections, которые ещё что-то пишут туда.
Сначала думали, что проблема в CeleryWorkers и конфиге worker_autoscale=800,200. У нас 5 воркеров, при таком конфиге они держат запущенными по 200 сабпроцессов каждый. Как раз 1000 получается.
Но при запуске дагов максимум достигается 600 тасок в running (600 слотов), дальше упираемся в limit коннекшенов базе. То есть открываются новые 600 коннекшенов в дополнение к этим левым 1000.
Есть идеи?
ДН
Всем привет! Тестируем перформанс Airflow - пытаемся выжать максимум по количеству task instance, способных одновременно быть в статусе running.
Столкнулись со странной ошибкой:
0 task instances в статусе running, но в базе (Postgres) висит 1000 connections, которые ещё что-то пишут туда.
Сначала думали, что проблема в CeleryWorkers и конфиге worker_autoscale=800,200. У нас 5 воркеров, при таком конфиге они держат запущенными по 200 сабпроцессов каждый. Как раз 1000 получается.
Но при запуске дагов максимум достигается 600 тасок в running (600 слотов), дальше упираемся в limit коннекшенов базе. То есть открываются новые 600 коннекшенов в дополнение к этим левым 1000.
Есть идеи?
Столкнулись со странной ошибкой:
0 task instances в статусе running, но в базе (Postgres) висит 1000 connections, которые ещё что-то пишут туда.
Сначала думали, что проблема в CeleryWorkers и конфиге worker_autoscale=800,200. У нас 5 воркеров, при таком конфиге они держат запущенными по 200 сабпроцессов каждый. Как раз 1000 получается.
Но при запуске дагов максимум достигается 600 тасок в running (600 слотов), дальше упираемся в limit коннекшенов базе. То есть открываются новые 600 коннекшенов в дополнение к этим левым 1000.
Есть идеи?
Увеличить пул соединений в БД?
АС
Увеличить пул соединений в БД?
Это понятно. Непонятно, почему если я хочу 600 тасок запустить, мне нужно иметь 1600 коннекшенов к базе.
A
Всем привет! Тестируем перформанс Airflow - пытаемся выжать максимум по количеству task instance, способных одновременно быть в статусе running.
Столкнулись со странной ошибкой:
0 task instances в статусе running, но в базе (Postgres) висит 1000 connections, которые ещё что-то пишут туда.
Сначала думали, что проблема в CeleryWorkers и конфиге worker_autoscale=800,200. У нас 5 воркеров, при таком конфиге они держат запущенными по 200 сабпроцессов каждый. Как раз 1000 получается.
Но при запуске дагов максимум достигается 600 тасок в running (600 слотов), дальше упираемся в limit коннекшенов базе. То есть открываются новые 600 коннекшенов в дополнение к этим левым 1000.
Есть идеи?
Столкнулись со странной ошибкой:
0 task instances в статусе running, но в базе (Postgres) висит 1000 connections, которые ещё что-то пишут туда.
Сначала думали, что проблема в CeleryWorkers и конфиге worker_autoscale=800,200. У нас 5 воркеров, при таком конфиге они держат запущенными по 200 сабпроцессов каждый. Как раз 1000 получается.
Но при запуске дагов максимум достигается 600 тасок в running (600 слотов), дальше упираемся в limit коннекшенов базе. То есть открываются новые 600 коннекшенов в дополнение к этим левым 1000.
Есть идеи?
точно пишут? может они находятся в статусе ожидания(не помню как он называется)
В конфиге кстати можно пулл ограничить и эти соединения переиспользуются
В конфиге кстати можно пулл ограничить и эти соединения переиспользуются
ДН
Это понятно. Непонятно, почему если я хочу 600 тасок запустить, мне нужно иметь 1600 коннекшенов к базе.
Ну а почему вы думаете что 1 таск - это 1 параллельный запрос в БД?
A
Это понятно. Непонятно, почему если я хочу 600 тасок запустить, мне нужно иметь 1600 коннекшенов к базе.
АС
Andrey
точно пишут? может они находятся в статусе ожидания(не помню как он называется)
В конфиге кстати можно пулл ограничить и эти соединения переиспользуются
В конфиге кстати можно пулл ограничить и эти соединения переиспользуются
Ну вроде - если бы они были idle, они бы сдохли в какой-то момент, т.к. в базе стоит таймаут на idle соединения.
АС
Ну а почему вы думаете что 1 таск - это 1 параллельный запрос в БД?
Из наблюдений. 0 тасок - 1000 коннекшенов. Начинаем запускать таски, слоты накапливаются - одновременно накапливаются коннекшены к базе, доходим до 600 тасок, становится 1600 коннекшенов.
A
стандартный конфиг sql_alchemy_pool_recycle = 1800, соединения будут держаться 1800 секунд в idle, а в базе какой timeout на эту тему?
АС
144 минуты = 2,4 часа. Но они живые уже несколько дней.
A
144 минуты = 2,4 часа. Но они живые уже несколько дней.
какая версия airflow? такая проблема была в... 🤔, 1.8 или 1.9
но потом починили
но потом починили
АС
Andrey
какая версия airflow? такая проблема была в... 🤔, 1.8 или 1.9
но потом починили
но потом починили
1.10.12
A
1.10.12
Коллеги, у кого такая версия стоит, как себя БД ведет?
P
1.10.12
12 версия жесть с какими багами
ME
12 версия жесть с какими багами
13 не лучше)
ME
А у вас патч работает?
ME
что-то мне не помогло, даги не запускаются...