|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
Добрый день. Есть процедура, которая выполняется в тестовой БД, она делает следующее: 1) берет список ip из таблички в тестовой БД. 2) подключается через db_link к каждому серверу из списка, делает там простой SELECT 3) результаты SELECT вставляет в свою табличку в тестовой БД. При этом, после 3-5 минут выполнения процедуры дико начинают тормозить промышленные БД на том же кластере. В промышленные БД процедура никак не лезет. Нагрузки не создает (вставка 10 строк в минуту). Тем не менее, прослеживается явная зависимость от запуска этой процедуры и торможением. Как будто эта процедура запускаетсяв промышленной БД и там индексы пухнуть начинают. Подскажите, как сделать чтобы выполнение процедуры в тестовой БД не мешало работе промышшленным БД в том же кластере? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 13:19 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
lr2Подскажите, как сделать чтобы выполнение процедуры в тестовой БД не мешало работе промышшленным БД в том же кластере? драйвера поставить, как минимум ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 13:22 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
mefmanlr2Подскажите, как сделать чтобы выполнение процедуры в тестовой БД не мешало работе промышшленным БД в том же кластере? драйвера поставить, как минимум Драйвера чего? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 13:27 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
lr2mefmanпропущено... драйвера поставить, как минимум Драйвера чего? для рук и мозгов. Поскольку вы никаких данных больше не дали... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 13:30 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
Вот такая функция: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42.
Она запускается в тестовой БД, а тормозить начинает промышленная. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 13:34 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
lr2, А у вас случайно не на винде база стоит? Да еще и на НЕ СЕРВЕРНОЙ винде? Очень похоже на окончание лимитов открытых коннектов в несерверной винде. PS: тестовую и production нагрузку на одном физическом сервере не держат (даже на двух разных виртуалках не говоря о одном кластере базы). PPS: вы бы посмотрели что именно тормозит то и как... тормозит - не это симптом... симптом - рост cpu или io или еще что то что можно как то трактовать а не гадать на кофейной гуще. PPPS: еще возможно окончание лимита коннектов к кластеру базы (если баз у вас много а max_connections мало). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 13:44 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
Maxim Boguklr2, А у вас случайно не на винде база стоит? Да еще и на НЕ СЕРВЕРНОЙ винде? Очень похоже на окончание лимитов открытых коннектов в несерверной винде. PS: тестовую и production нагрузку на одном физическом сервере не держат (даже на двух разных виртуалках не говоря о одном кластере базы). PPS: вы бы посмотрели что именно тормозит то и как... тормозит - не это симптом... симптом - рост cpu или io или еще что то что можно как то трактовать а не гадать на кофейной гуще. PPPS: еще возможно окончание лимита коннектов к кластеру базы (если баз у вас много а max_connections мало). Да, вы правы, это винда. Серверная. Торможение проявляется так: Симптомы: Запросы начинают выполняться медленнее и висят как активные по несколько сек. CPU нагрузка с 10% подскакивает до 100%. max_connections достаточно, не более 30% занято, да и коннекты ведь к клиентам, у них свои БД. >Очень похоже на окончание лимитов открытых коннектов в несерверной винде. разве тогда бы не падал весь кластер с ntstatus.h исключением? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 14:01 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
Maxim Boguk, вообще очень похоже что как-то связано с количеством клиентов. Если LIMIT 100 ставлю - отрабатывает нормально. Если LIMIT 200 - примерно на 150-м начинаются жуткие тормоза!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 14:13 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
Maxim Boguk, еще одна интересная особенность: Если тот же самый текст оформить как анонимный блок DO - то ТОРМОЗОВ НЕТ!!!! Все прекрасно выполняется. А когда то же самое внутри функции появляются тормоза. Может быть на функцию какие-то ограничения по рессурсам имеются? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 14:31 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
и ещё момент: [quot lr2] Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
похоже на многократное (пере)открытие (неименованного) соединения в лупе. они ж (неименованные), как я помню (можете ,впрочем, перепроверить сами, могло что-то измениться), не враз закроются. и все висят до конца сеанса, недоступные к закрытию. переоткрывайте (и явно закрывайте) "одно" "именованное" соединение и делайте все "в нем". ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 14:35 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
lr2Maxim Boguk, еще одна интересная особенность: Если тот же самый текст оформить как анонимный блок DO - то ТОРМОЗОВ НЕТ!!!! Все прекрасно выполняется. А когда то же самое внутри функции появляются тормоза. Может быть на функцию какие-то ограничения по рессурсам имеются? тут я поторопился с выводом, через функцию тоже стал выполняться. Единственное что поменял - в цикле вместо двух дблинков сделал один. Очень странно... как будто какое-то ограничение срабатывает по количеству дблинков внутри процедуры. При этом SELECT COUNT(*) FROM pg_stat_activity покажывает 30% от максимального количества. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 14:48 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
[quot qwwq]и ещё момент: lr2 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
похоже на многократное (пере)открытие (неименованного) соединения в лупе. они ж (неименованные), как я помню (можете ,впрочем, перепроверить сами, могло что-то измениться), не враз закроются. и все висят до конца сеанса, недоступные к закрытию. переоткрывайте (и явно закрывайте) "одно" "именованное" соединение и делайте все "в нем". так сложно отлавливать эксэпшны, когда неудачная попытка соединения. Попробую как вы сказали сделать. По идее коннект должен оставться висеть на клиентской БД, но его там нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 14:49 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
Итак, получилось смоделировать зависание. Вернул обратно в цикл два дблинк и добавил счетчик, который увеличивается на 1 перед каждым дблинк Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
В итоге получилось что после 413 dblink начинаются тормоза, с чем связанные, непонятно: NOTICE: 2019-05-15 15:05:13.107+03 408 NOTICE: 2019-05-15 15:05:13.247+03 409 NOTICE: 2019-05-15 15:05:13.513+03 410 NOTICE: 2019-05-15 15:05:13.793+03 411 NOTICE: 2019-05-15 15:05:13.887+03 412 NOTICE: 2019-05-15 15:05:13.987+03 413 <<---ЗАВИСАНИЕ NOTICE: 2019-05-15 15:05:16.811+03 414 NOTICE: 2019-05-15 15:05:18.567+03 415 NOTICE: 2019-05-15 15:05:31.378+03 416 Выполнение отменено! При этом SELECT COUNT(*) FROM pg_stat_activity 30% то максимального. Скажите, с чем связаны тормоза всего кластера, появляющиеся после 400+ дб линков? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 15:15 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
При использовании анонимного блока зависание случилось на 493 дблинке: NOTICE: 2019-05-15 15:19:07.528+03 485 NOTICE: 2019-05-15 15:19:07.59+03 486 NOTICE: 2019-05-15 15:19:07.762+03 487 NOTICE: 2019-05-15 15:19:07.824+03 488 NOTICE: 2019-05-15 15:19:07.918+03 489 NOTICE: 2019-05-15 15:19:08.09+03 490 NOTICE: 2019-05-15 15:19:08.242+03 491 NOTICE: 2019-05-15 15:19:08.362+03 492 NOTICE: 2019-05-15 15:19:08.492+03 493 <<--ЗАВИСАНИЕ NOTICE: 2019-05-15 15:19:11.169+03 494 NOTICE: 2019-05-15 15:19:11.987+03 495 NOTICE: 2019-05-15 15:19:59.74+03 496 NOTICE: 2019-05-15 15:19:59.873+03 497 Выполнение отменено! Но тоже случилось. Т.е. не только внутри функции но и внутри анонимного блока происходят эти странности. Может быть какой-то баг встречался на эту тему? Или есть какой-то ограничение на количество дблинков в запросе? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 15:25 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
lr2так сложно отлавливать эксэпшны, когда неудачная попытка соединения. сложно трусы через голову одевать. а написать правильно блок с ( перепроверкой наличия незакрытого именованного соединения в {конце лупа|перед открытием}) -- вопрос гигиены. и ещё: столько сейвпойнтов (блоков обработки ошибок) в цикле -- это тоже не лучшая идея. иногда лучше задействовать fail_on_error = False, и обрабатывать значение FOUND . но в вашем случае жаль, что ошибку соединения нельзя так обойти. по крайней мере навскидку способа поднять соединение dblink без выбрасывания ошибки соединения наверх не видно. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 15:43 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
lr2Итак, получилось смоделировать зависание. Вернул обратно в цикл два дблинк и добавил счетчик, который увеличивается на 1 перед каждым дблинк При этом SELECT COUNT(*) FROM pg_stat_activity 30% то максимального. Скажите, с чем связаны тормоза всего кластера, появляющиеся после 400+ дб линков? А максимальное это сколько у вас? И что при этом интересного в логе базы пишется? (если пишется конечно). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 16:49 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
lr2Но тоже случилось. Т.е. не только внутри функции но и внутри анонимного блока происходят эти странности. Может быть какой-то баг встречался на эту тему? Или есть какой-то ограничение на количество дблинков в запросе? А сколько времени ваша процедура работает? Если просто сделать begin; insert (что то там в my_table ); и не коммитя запрос просто оставить на сравнимое или несколько большее время относительно вашей функции то не будет ли похожий эффект наблюдаться? Т.е. может у вас там просто слишком долгая транзакция получается а dblink вообще не причем. ps: это просто гипотеза... то что вы описываете - я раньше не слышал и не видел в живую так что придется скорее вам разбираться. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2019, 17:41 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
Maxim Boguklr2Итак, получилось смоделировать зависание. Вернул обратно в цикл два дблинк и добавил счетчик, который увеличивается на 1 перед каждым дблинк При этом SELECT COUNT(*) FROM pg_stat_activity 30% то максимального. Скажите, с чем связаны тормоза всего кластера, появляющиеся после 400+ дб линков? А максимальное это сколько у вас? И что при этом интересного в логе базы пишется? (если пишется конечно). Да не долго, минуты три. В логе ничего не пишется, кроме того что запросы дольше секунды начинают и в лог падают. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2019, 10:53 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
Maxim Boguklr2Но тоже случилось. Т.е. не только внутри функции но и внутри анонимного блока происходят эти странности. Может быть какой-то баг встречался на эту тему? Или есть какой-то ограничение на количество дблинков в запросе? А сколько времени ваша процедура работает? Если просто сделать begin; insert (что то там в my_table ); и не коммитя запрос просто оставить на сравнимое или несколько большее время относительно вашей функции то не будет ли похожий эффект наблюдаться? Т.е. может у вас там просто слишком долгая транзакция получается а dblink вообще не причем. ps: это просто гипотеза... то что вы описываете - я раньше не слышал и не видел в живую так что придется скорее вам разбираться. Я по наячалу тоже думал что дело в этом, но если просто запустить большой SELECT он может выполняться и пол часа и час и подобного не возникает. Это началось три дня назад, при этом раньше абсолютно та же процедура выполнялась без проблем, всего там было около 800 дблинков. Потом внезапно начались тормоза при ее выполнении. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2019, 10:56 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
Проблема актуальна. Решения не нашел. Пока думаю что это какая-нибудь память в винде забивается. Есть ли какие-нибудь другие объяснения такому поведению постгресса? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2019, 14:23 |
|
запускаю процедуру и вешается сервак.
|
|||
---|---|---|---|
#18+
qwwqlr2так сложно отлавливать эксэпшны, когда неудачная попытка соединения. сложно трусы через голову одевать. а написать правильно блок с ( перепроверкой наличия незакрытого именованного соединения в {конце лупа|перед открытием} ) -- вопрос гигиены. и ещё: столько сейвпойнтов (блоков обработки ошибок) в цикле -- это тоже не лучшая идея. иногда лучше задействовать fail_on_error = False, и обрабатывать значение FOUND . но в вашем случае жаль, что ошибку соединения нельзя так обойти. по крайней мере навскидку способа поднять соединение dblink без выбрасывания ошибки соединения наверх не видно. здесь важно не за лупом, а в конце, но в лупе ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2019, 17:28 |
|
|
start [/forum/topic.php?fid=53&gotonew=1&tid=1995175]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
53ms |
get topic data: |
12ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 187ms |
0 / 0 |