AL
в таком случае уменьшите количество воркеров
Size: a a a
2021 February 22
AL
или возьмите инстанс под БД подороже
VY
Lina M
Всё сводилось к тому, что чем больше инстансов, тем быстрее всё будет обработано. Но как это видно, база такое не выдерживает
возьмите одну машину, а не 50. поделите ваши 100М строк на части по кол-ву ядер в этой машине и запустите соответсвующее кол-во процессов.
желательно, чтобы в базе было не меньше ядер, чем на этой машине.
достаточно.
желательно, чтобы в базе было не меньше ядер, чем на этой машине.
достаточно.
LM
в таком случае уменьшите количество воркеров
В таком случае обработка исторических данных займёт несколько недель. И именно поэтому я тут очутился, чтобы узнать, возможно ли эту единичную операцию сделать намного быстрее
YS
Lina M
Всё сводилось к тому, что чем больше инстансов, тем быстрее всё будет обработано. Но как это видно, база такое не выдерживает
Это здравый смысл такого не выдерживает, извините. ;)
Как, ну как от роста количества одновременно "выполняющихся" задач выше числа исполнителей можно рассчитывать получить ускорение?!
Как, ну как от роста количества одновременно "выполняющихся" задач выше числа исполнителей можно рассчитывать получить ускорение?!
LM
или возьмите инстанс под БД подороже
Базы были разные. От 1 ЦП 0.6 RAM, до 16 ЦП и 84 RAM
YS
Lina M
В таком случае обработка исторических данных займёт несколько недель. И именно поэтому я тут очутился, чтобы узнать, возможно ли эту единичную операцию сделать намного быстрее
Ну так этим и нужно заниматься, в таком случае, казалось бы.
Т.е. "покопаться" в том, почему эта операция такая медленная (100 млн. записей, при "среднем" их размере — это же совсем немного, нет?).
Т.е. "покопаться" в том, почему эта операция такая медленная (100 млн. записей, при "среднем" их размере — это же совсем немного, нет?).
D
Lina M
Один машина [воркер] создаёт 8*8 тредов, 1 тред = 1 активное соединение
40-50 машин одного типа, 5-10 другого
40-50 машин одного типа, 5-10 другого
Я думаю, тут есть смысл подумать над архитектурой приложения. Возможно, количество соединений в пуле можно уменьшить без ущерба производительности. Тредам ведь коннект не нужен постоянно. Я так понимаю, что подключение к бд нужно лишь тогда, когда тред выполняет запрос к бд, а в остальное время этот коннект просто не нужен.
D
Я к тому, что коннект, по идее, на каждый тред не нужно брать. Его надо из пула доставать именно тогда, когда делается запрос, после чего возвращать обратно.
LM
Я к тому, что коннект, по идее, на каждый тред не нужно брать. Его надо из пула доставать именно тогда, когда делается запрос, после чего возвращать обратно.
Сейчас так и происходит. Сессия может быть открыта до 60 секунд (таймаут requests)
В общем плане всё происходит так:
> приходит запрос
> создаётся сессия
> проверка в бд
> маппинг данных
> requests (timeout=60 sec)
> проверка в бд
> маппинг данных
> добавление данных в бд
> сессия закрывается
В общем плане всё происходит так:
> приходит запрос
> создаётся сессия
> проверка в бд
> маппинг данных
> requests (timeout=60 sec)
> проверка в бд
> маппинг данных
> добавление данных в бд
> сессия закрывается
LM
возьмите одну машину, а не 50. поделите ваши 100М строк на части по кол-ву ядер в этой машине и запустите соответсвующее кол-во процессов.
желательно, чтобы в базе было не меньше ядер, чем на этой машине.
достаточно.
желательно, чтобы в базе было не меньше ядер, чем на этой машине.
достаточно.
Спасибо, подумаю, как это сделать
D
requests (timeout=60 sec) - а это что имеется в виду?
LM
requests (timeout=60 sec) - а это что имеется в виду?
В общем плане это операция не связанная с бд, которая может длиться до 60 секунд
D
Lina M
В общем плане это операция не связанная с бд, которая может длиться до 60 секунд
Так на это время возвращайте коннект обратно в пул
D
Ну и точно ли шаги "проверка в бд" и "добавление данных в бд" нельзя объединить в один sql-запрос с on conflict?
LM
Да, уже были мысли по изменению этого
LM
Yaroslav Schekin
Это здравый смысл такого не выдерживает, извините. ;)
Как, ну как от роста количества одновременно "выполняющихся" задач выше числа исполнителей можно рассчитывать получить ускорение?!
Как, ну как от роста количества одновременно "выполняющихся" задач выше числа исполнителей можно рассчитывать получить ускорение?!
Да, сейчас понимаю, что это звучит не логично
YS
Lina M
В общем плане это операция не связанная с бд, которая может длиться до 60 секунд
Тогда можно на время requests на 60 секунд (пока они происходят) отключиться и повторить "проверка в бд", если настолько важно количество подключений (да и вообще это хорошая практика).
LM
Ну и точно ли шаги "проверка в бд" и "добавление данных в бд" нельзя объединить в один sql-запрос с on conflict?
На данный момент могу ответить что да, но не буду в этом уверен на 100%
LM
Yaroslav Schekin
Тогда можно на время requests на 60 секунд (пока они происходят) отключиться и повторить "проверка в бд", если настолько важно количество подключений (да и вообще это хорошая практика).
Это, скорее всего, не совсем относится к изначальной теме. Но, возможно, внесёте ясность в одном моменте.
Как сделать лучше/правильнее/оптимальнее:
1. Проверить одним запросом существование записи в таблице (exists scalar) → добавить запись в таблицу, если её нет, если словили
2. Сразу сделать добавление записи в таблицу, и если словили
Как сделать лучше/правильнее/оптимальнее:
1. Проверить одним запросом существование записи в таблице (exists scalar) → добавить запись в таблицу, если её нет, если словили
integrity error обработать2. Сразу сделать добавление записи в таблицу, и если словили
integrity error обработать