|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
Добрый день Бьюсь над такой задачей - есть утилита импорта документов в базу FB 2.5.3, при импорте идет update таблицы заголовка документов. По логам вижу, что при апдейте данных первого документа время выполнения запросов 2-10 минут, все остальные апдейты проходят на секунды. Таблица большая с кучей триггеров. Как можно это исправить? От автора утилиты получил объяснение, что время уходит на первый prepare, остальные в рамках того же коннекта время на подготовку не тратят. Архитектура Classic. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 06:49 |
|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
Gallemarвремя уходит на первый prepare небось, еще ФИБы туда данные льют... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 10:53 |
|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
Gallemar, зачем гадать. Возьми trace и посмотри куда действительно время уходит ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 11:03 |
|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
ДокGallemarвремя уходит на первый prepare небось, еще ФИБы туда данные льют... Догадливый :) Скажу больше - зачем-то вместо одного update с изменением всех полей сделали на каждое поле отдельный запрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 11:33 |
|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
Симонов ДенисGallemar, зачем гадать. Возьми trace и посмотри куда действительно время уходит уже всё давно посмотрел. Можно ли ускорить prepare? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 11:33 |
|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
Gallemar, какой размер таблицы для update? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 11:44 |
|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
Симонов Денис, 22 млн строк Код: 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. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 11:54 |
|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
Пальцем в небо. При 22млн время при первом запросе может уходить на зачитывание индекса или таблицы в кэш. Можно попробовать перед запуском утилиты импорта предварительно самому "разогреть" эту таблицу и индексы. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 11:58 |
|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
Ну и раз на таблице куча триггеров - посмотреть чего они там трогают. Может быть там тоже нужно кэш разогревать. Если есть возможность протестить не на боевой базе - поотключать все триггеры, посмотреть будет ли тормозить препаре. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 12:01 |
|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
GallemarДогадливый :) Скажу больше - зачем-то вместо одного update с изменением всех полей сделали на каждое поле отдельный запрос. у ФИБов из-за их "неестественного интеллекта" (©, МП) большая куча времени может уходить на чтение различных метаданных. Для импорта данных в базу, имхо, лучше использовать TFIBBatch. И, наверное, про индексы кто-нибудь сведущий должен упомянуть :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 12:23 |
|
Долгий первый UPDATE
|
|||
---|---|---|---|
#18+
fraksНу и раз на таблице куча триггеров - посмотреть чего они там трогают. Может быть там тоже нужно кэш разогревать. Если есть возможность протестить не на боевой базе - поотключать все триггеры, посмотреть будет ли тормозить препаре. Помнится, на таблицах с ветвистыми триггерными деревьями на препаре вся сила уходила на проверку прав на всю кучу затронутых объектов. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 14:18 |
|
|
start [/forum/topic.php?fid=40&msg=39509820&tid=1561454]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
136ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 298ms |
total: | 536ms |
0 / 0 |