|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Имеется таблица с 3 млн. записей. В таблице есть поле GUID CHAR(32), все значения - NULL. Запрос select count(*) для этой таблицы выполняется за 5 секунд. После того, как для каждой записи проставили значение поля GUID, запрос select count(*) стал отрабатывать более часа. Индекс на это поле есть. После выполнения backup-restore базы, производительность восстанавливается до исходной. В чем может быть причина такого падения производительности и как ее избежать? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 10:46 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
InterloperВ чем может быть причина такого падения производительности и как ее избежать?Мусор. Не избежать никак, апдейт гарантирует появление мусора. надо один раз убрать. бэкап-рестор для этого как из пушки по воробью, но таки да, мусор он уберет гарантированно. Если нет заинтересованных транзакций, то можно просто прогнать неиндескное чтение по таблице, ну или свип запустить. InterloperGUID CHAR(32),странный гуид, 16 октетс чаров понимаю, 36 чаров для хуман ридебл понимаю, 32 не понимаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 10:57 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
InterloperПосле выполнения backup-restore базы, производительность восстанавливается до исходной. Она и без b/r восстановится достаточно собрать мусор. это ведь одноразовая операция? Тогда можно просто собрать мусор и не парится. В индексах сборка мусора сейчас не самая быстрая операция. Если такое выполняется постоянно, то это повод пересмотреть подход к проектированию. Кстати какая версия сервера? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 11:21 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Симонов ДенисInterloperПосле выполнения backup-restore базы, производительность восстанавливается до исходной. Она и без b/r восстановится достаточно собрать мусор. это ведь одноразовая операция? Тогда можно просто собрать мусор и не парится. В индексах сборка мусора сейчас не самая быстрая операция. Если такое выполняется постоянно, то это повод пересмотреть подход к проектированию. Кстати какая версия сервера? Операция одноразовая, но новые записи в данную таблицу будут добавляться уже с заполненным GUID. Версия сервера - 1.5. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 11:51 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Каким образом можно инициировать сборку мусора непосредственно из скрипта? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 11:53 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Hello, Interloper! You wrote on 1 июля 2015 г. 11:58:09: Interloper> Каким образом можно инициировать сборку мусора непосредственно из скрипта?так же как ты её стартовал каунтом. только перед этим не забудь закоммитить обновления. чтобы каунт бежал в новой транзакции, собирая мусор. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 11:59 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Interloper, замечание о том, что произошло. скорее всего ты сначала создал индекс по столбцу, где все 3млн значений были null. Потом сделал update с guid. В результате в индексе остался ключ null, указывающий на все 3 млн записей. Из-за чего при сборке мусора на каждую запись сервер искал номер этой записи в ключе из 3млн номеров записей. Поэтому такие массовые операции надо делать без индексов, особенно по таким неуникальным столбцам. Гораздо быстрее будет - сделать апдейт - убрать мусор - создать индекс. до сборки мусора создавать индекс не стоит, потому что индекс проиндексирует все версии, в т.ч. "мусорные", и будет опять та же фигня. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 12:07 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Interloper, ну там дело совсем дрянь. У тебя индекс первоначально построен на поле с единственным значением NULL. В 1.5 сборка мусора в индексе с большим числом дубликатов ключей конкретный тормоз. Можно было сначала грохнуть или отрубить индекс (если конечно есть возможность), потом обновить записи и сделать сборку мусора, а потом врубить его обратно. Так быстрее будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 12:09 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Симонов Денис, Попробовали такую последовательность действий: 1. Отключить индекс 2. Сделать update 3. Включить индекс Работает нормально. Получается, сборку мусора можно явно не делать, она сама собой произойдет в процессе работы с таблицей? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 12:24 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
InterloperПолучается, сборку мусора можно явно не делать, она сама собой произойдет в процессе работы с таблицей?Странное понимание, говорят одно, а человек понимает совершенно другое. Да, мусор в процессе уберется в любом случае, только этот "случай" может возникнуть в самый неподходящий момент. Еще почитай про термин "версия" и "мусор" в какой момент что рождается и когда меняет свой статус. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 12:27 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Interloper, http://www.ibase.ru/devinfo/garbage.htm ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 12:32 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Interloper Попробовали такую последовательность действий: 1. Отключить индекс 2. Сделать update 3. Сделать сборку мусора (это ты забыл) 4. Включить индекс Ты бы хоть читал что тебе пишут. А вообще надо было как то так Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Как и говорил kdv ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 12:43 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
InterloperСимонов Денис, Попробовали такую последовательность действий: 1. Отключить индекс 2. Сделать update 3. Включить индекс Работает нормально. Получается, сборку мусора можно явно не делать, она сама собой произойдет в процессе работы с таблицей?В данном сценарии мусор соберётся на 3-м шаге (есс-но, если OST не застряла) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 12:44 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Симонов Денис, При включении индекса разве мусор не уберется? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 13:09 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Interloper, Влад говорит что уберется. Но это если у тебя не застряло никаких транзакций, которые будут препятствовать сборке мусора. Прочитай уже статьи про мусор, сборку мусора и версионность. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 13:10 |
|
Ухудшение производительности при заполнении значений столбца
|
|||
---|---|---|---|
#18+
Interloper, уберётся. Как и сказал Влад. Главное что ты должен понять так это то, что не надо создавать индекс раньше времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.07.2015, 13:12 |
|
|
start [/forum/topic.php?fid=40&msg=38996757&tid=1562746]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
49ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 174ms |
0 / 0 |