Тормозит первое чтение
Тормозит первое чтение
В базу прилетают данные пачками примерно по 100 записей, раз примерно в 15 минут. Чтение из таблицы как правило редкое, может произойти намного позже (неделю и более спустя).
Проблема в том, что такое первое чтение может стопорнуться в определенном месте и оооочень надолго, вплоть до часов. Причем это происходит в достаточно случайных местах, я не смог обнаружить какой либо закономерности касательно скажем перезагрузки сервера. Несколько раз в этих таблицах даже обнаруживались ошибки (shecksum error и вроде бы wrong metadata или как то так, уже забыл).
Прикладу, которая складирует данные, я проверял мельком, вроде бы не должно быть ситуаций когда она оставляет незакоммиченные транзакции с записями, делали и закидывание по 1000 записей-коммит и по одной, все равно проблема остается. Хотя поскольку писал не я, на 100% исключить такую ситуацию не могу.
Свип отключен, бэкап-откат делается в среднем раз в месяц. Структура таблицы приведена ниже. У кого какие мнение, что это такое и как с этим бороться?
Проблема в том, что такое первое чтение может стопорнуться в определенном месте и оооочень надолго, вплоть до часов. Причем это происходит в достаточно случайных местах, я не смог обнаружить какой либо закономерности касательно скажем перезагрузки сервера. Несколько раз в этих таблицах даже обнаруживались ошибки (shecksum error и вроде бы wrong metadata или как то так, уже забыл).
Прикладу, которая складирует данные, я проверял мельком, вроде бы не должно быть ситуаций когда она оставляет незакоммиченные транзакции с записями, делали и закидывание по 1000 записей-коммит и по одной, все равно проблема остается. Хотя поскольку писал не я, на 100% исключить такую ситуацию не могу.
Свип отключен, бэкап-откат делается в среднем раз в месяц. Структура таблицы приведена ниже. У кого какие мнение, что это такое и как с этим бороться?
Re: Тормозит первое чтение
gstat -h, gstat -r кто-нибудь когда-нибудь делал ?
Re: Тормозит первое чтение
Я правильно понимаю, что вопрос был задан просто так, лишь бы задать, и ответ не интересует автора ?
Re: Тормозит первое чтение
Аааа, кажется я понял. Ты наверное имел ввиду "для более точного понимания ситуации хотелось бы иметь результаты выполнения следующих команд..."hvlad писал(а):Я правильно понимаю, что вопрос был задан просто так, лишь бы задать, и ответ не интересует автора ?
- Database header page information:
Flags 0
Checksum 12345
Generation 24430768
Page size 8192
ODS version 11.2
Oldest transaction 10619
Oldest active 17730476
Oldest snapshot 17729632
Next transaction 24267226
Bumped transaction 1
Sequence number 0
Next attachment ID 163536
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jun 2, 2015 22:05:19
Attributes force write
Variable header data:
Sweep interval: 0
*END*
TTS3_DATA (150)
Primary pointer page: 209, Index root page: 210
Average record length: 91.30, total records: 6558192
Average version length: 9.11, total versions: 672804, max versions: 111
Data pages: 109295, data page slots: 136707, average fill: 82%
Fill distribution:
0 - 19% = 471
20 - 39% = 1054
40 - 59% = 674
60 - 79% = 51
80 - 99% = 107045
Index RDB$PRIMARY67 (0)
Depth: 3, leaf buckets: 7624, nodes: 6558192
Average data length: 3.20, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 55
20 - 39% = 0
40 - 59% = 409
60 - 79% = 15
80 - 99% = 7145
TTS4_DATA (143)
Primary pointer page: 195, Index root page: 196
Average record length: 91.47, total records: 10812202
Average version length: 9.29, total versions: 1050166, max versions: 108
Data pages: 181617, data page slots: 225555, average fill: 81%
Fill distribution:
0 - 19% = 2304
20 - 39% = 900
40 - 59% = 985
60 - 79% = 650
80 - 99% = 176778
Index RDB$PRIMARY96 (0)
Depth: 3, leaf buckets: 11730, nodes: 10812202
Average data length: 2.60, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 54
20 - 39% = 1
40 - 59% = 643
60 - 79% = 8
80 - 99% = 11024
P.S. Может ли помочь создание дополнительного индекса только по полю LOCALTIME? Полезно ли будет добавить в программу, записывающую данные, еще и чтение после записи?
Re: Тормозит первое чтение
Oldest active 17730476
Next transaction 24267226
ну чего вы фигней маетесь? У вас активная транзакция блокирует сборку мусора уже 10 ДНЕЙ. 10 дней торчит приложение, подключенное к БД с активной транзакцией.
Next transaction 24267226
ну чего вы фигней маетесь? У вас активная транзакция блокирует сборку мусора уже 10 ДНЕЙ. 10 дней торчит приложение, подключенное к БД с активной транзакцией.
Re: Тормозит первое чтение
про версионость что-нибудь вообще читали? про сборку мусора? Про транзакции?
По-моему, вообще нет. На сайте масса информации. можете начать отсюда
http://www.ibase.ru/devinfo/mga.htm
http://www.ibase.ru/devinfo/garbage.htm
http://www.ibase.ru/devinfo/summary.htm
если у вас firebird 2.1 и выше, найти проблемное приложение с долгим коннектом и транзакцией можете найти выполнив
select * from mon$attachments
select * from mon$transactions
По-моему, вообще нет. На сайте масса информации. можете начать отсюда
http://www.ibase.ru/devinfo/mga.htm
http://www.ibase.ru/devinfo/garbage.htm
http://www.ibase.ru/devinfo/summary.htm
если у вас firebird 2.1 и выше, найти проблемное приложение с долгим коннектом и транзакцией можете найти выполнив
select * from mon$attachments
select * from mon$transactions
Re: Тормозит первое чтение
Я же написал, что свип отключен. Я читал и про версионность и про сборку мусора и про транзакции. Вопрос в том, почему проблема не возникает ни с одной другой таблицей?kdv писал(а):про версионость что-нибудь вообще читали? про сборку мусора? Про транзакции?
По-моему, вообще нет. На сайте масса информации. можете начать отсюда
http://www.ibase.ru/devinfo/mga.htm
http://www.ibase.ru/devinfo/garbage.htm
http://www.ibase.ru/devinfo/summary.htm
если у вас firebird 2.1 и выше, найти проблемное приложение с долгим коннектом и транзакцией можете найти выполнив
select * from mon$attachments
select * from mon$transactions
Re: Тормозит первое чтение
просто поразительно.
"- вы ничего не понимаете в версионности
- я же написал, что свип отключен"
ну отключен свип, и что? Вы не знаете, что такое свип
http://www.ibase.ru/devinfo/sweep.htm
А проблема у вас вот в чем
- длинная транзакция приводит к накоплению версий, что само по себе со временем ухудшает производительность.
- как только эта транзакция завершается, внезапно, версии из "нужных" превращаются в "мусорные, ненужные". И первый же запрос к данным с накопленными версиями начинает собирать мусор. А мусора у вас накапливается просто дофига. Потому и
"Проблема в том, что такое первое чтение может стопорнуться в определенном месте и оооочень надолго, вплоть до часов."
Если бы вы действительно понимали про версионность и сборку мусора и про транзакции, вы бы
- проверили свое приложение на предмет длинных транзакций
- посмотрели бы IBAnalyst-ом, где и сколько версий накапливается (хотя это и так видно в поцитированной вами статистике).
- сделали бы выводы, исправили приложение
"- вы ничего не понимаете в версионности
- я же написал, что свип отключен"
ну отключен свип, и что? Вы не знаете, что такое свип
http://www.ibase.ru/devinfo/sweep.htm
А проблема у вас вот в чем
- длинная транзакция приводит к накоплению версий, что само по себе со временем ухудшает производительность.
- как только эта транзакция завершается, внезапно, версии из "нужных" превращаются в "мусорные, ненужные". И первый же запрос к данным с накопленными версиями начинает собирать мусор. А мусора у вас накапливается просто дофига. Потому и
"Проблема в том, что такое первое чтение может стопорнуться в определенном месте и оооочень надолго, вплоть до часов."
Если бы вы действительно понимали про версионность и сборку мусора и про транзакции, вы бы
- проверили свое приложение на предмет длинных транзакций
- посмотрели бы IBAnalyst-ом, где и сколько версий накапливается (хотя это и так видно в поцитированной вами статистике).
- сделали бы выводы, исправили приложение