Страница 1 из 1

Тормозит первое чтение

Добавлено: 01 июл 2015, 06:58
Frattello
В базу прилетают данные пачками примерно по 100 записей, раз примерно в 15 минут. Чтение из таблицы как правило редкое, может произойти намного позже (неделю и более спустя).
Проблема в том, что такое первое чтение может стопорнуться в определенном месте и оооочень надолго, вплоть до часов. Причем это происходит в достаточно случайных местах, я не смог обнаружить какой либо закономерности касательно скажем перезагрузки сервера. Несколько раз в этих таблицах даже обнаруживались ошибки (shecksum error и вроде бы wrong metadata или как то так, уже забыл).
Прикладу, которая складирует данные, я проверял мельком, вроде бы не должно быть ситуаций когда она оставляет незакоммиченные транзакции с записями, делали и закидывание по 1000 записей-коммит и по одной, все равно проблема остается. Хотя поскольку писал не я, на 100% исключить такую ситуацию не могу.
Свип отключен, бэкап-откат делается в среднем раз в месяц. Структура таблицы приведена ниже. У кого какие мнение, что это такое и как с этим бороться?
Изображение

Re: Тормозит первое чтение

Добавлено: 01 июл 2015, 10:32
hvlad
gstat -h, gstat -r кто-нибудь когда-нибудь делал ?

Re: Тормозит первое чтение

Добавлено: 03 июл 2015, 09:19
hvlad
Я правильно понимаю, что вопрос был задан просто так, лишь бы задать, и ответ не интересует автора ?

Re: Тормозит первое чтение

Добавлено: 08 июл 2015, 17:08
Frattello
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: Тормозит первое чтение

Добавлено: 08 июл 2015, 19:10
kdv
Oldest active 17730476
Next transaction 24267226
ну чего вы фигней маетесь? У вас активная транзакция блокирует сборку мусора уже 10 ДНЕЙ. 10 дней торчит приложение, подключенное к БД с активной транзакцией.

Re: Тормозит первое чтение

Добавлено: 08 июл 2015, 19:16
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: Тормозит первое чтение

Добавлено: 09 июл 2015, 05:58
Frattello
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: Тормозит первое чтение

Добавлено: 09 июл 2015, 11:02
kdv
просто поразительно.
"- вы ничего не понимаете в версионности
- я же написал, что свип отключен"

ну отключен свип, и что? Вы не знаете, что такое свип
http://www.ibase.ru/devinfo/sweep.htm

А проблема у вас вот в чем
- длинная транзакция приводит к накоплению версий, что само по себе со временем ухудшает производительность.
- как только эта транзакция завершается, внезапно, версии из "нужных" превращаются в "мусорные, ненужные". И первый же запрос к данным с накопленными версиями начинает собирать мусор. А мусора у вас накапливается просто дофига. Потому и
"Проблема в том, что такое первое чтение может стопорнуться в определенном месте и оооочень надолго, вплоть до часов."

Если бы вы действительно понимали про версионность и сборку мусора и про транзакции, вы бы
- проверили свое приложение на предмет длинных транзакций
- посмотрели бы IBAnalyst-ом, где и сколько версий накапливается (хотя это и так видно в поцитированной вами статистике).
- сделали бы выводы, исправили приложение