Падение производительности базы Firebird, восстанавливается после backup/restore

farafonoff
Дата: 03.06.2012 12:11:59
Посоветуйте как оптимизировать производительность. Симптомы следующие: База данных размером 5,5 Гб, Firebird LI-V2.5.1.26351 Linux x86_64, 8 ядер Xeon, 16GB RAM, Raid 1.

Database "/var/taxi/taxi.gdb"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              263321
        Page size               4096
        ODS version             11.2
        Oldest transaction      258979
        Oldest active           258980
        Oldest snapshot         258980
        Next transaction        259386
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      3928
        Implementation ID       24
        Shadow count            0
        Page buffers            1000
        Next header page        0
        Database dialect        3
        Creation date           Jun 3, 2012 7:59:41
        Attributes              force write

    Variable header data:
        Sweep interval:         20000
        *END*


Несколько месяцев работает нормально, через 2-3 месяца без видимых причин начинает работать медленнее(похоже открытие/commit транзакции).
Картинка с другого сайта. - время прохождения простейшего набора тестов. Почему-то совершенно не показательный.
Картинка с другого сайта. - загрузка цп на хосте. тоже не меняется со временем.
Картинка с другого сайта. - единственный показательный график. Четко видны моменты (резкий спад sysload), когда проводился backup/restore базы данных. Какие данные можно еще собрать, чтобы решить эту проблему?
farafonoff
Дата: 03.06.2012 12:15:45
Database "/var/taxi/taxi_0.gdb"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              69559689
        Page size               4096
        ODS version             11.2
        Oldest transaction      68108010
        Oldest active           68108011
        Oldest snapshot         68108011
        Next transaction        68110011
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      1449530
        Implementation ID       24
        Shadow count            0
        Page buffers            1000
        Next header page        0
        Database dialect        3
        Creation date           May 4, 2012 2:09:20
        Attributes              force write, multi-user maintenance

    Variable header data:
        Sweep interval:         20000
        *END*
Старая база данных (перед сегодняшним циклом backup/restore)
kdv
Дата: 03.06.2012 12:37:40
приложение сами писали? что-то у вас дофига транзакций - 2.2 миллиона в сутки.
Потом, сервер Classic? кто зашил в базу page buffers 1000 ?
http://www.ibase.ru/techsupp.htm
Dimitry Sibiryakov
Дата: 03.06.2012 14:29:38

kdv
что-то у вас дофига транзакций - 2.2 миллиона в сутки.

И две тысячи, активных одновременно. Сколько у вас там пользователей?

Posted via ActualForum NNTP Server 1.5

Ivan_Pisarevsky
Дата: 03.06.2012 20:36:55
Дисковой активности не показано, база хоть и меньше размера ОЗУ, но таки нормального объема, а дисков судя по вводным всего 2. Дисковый контроллер с собственным кэшем и райтбэк политикой кэширования, я надеюсь, имеется?
farafonoff
Дата: 04.06.2012 00:04:14
Сервер суперклассик(сейчас), до того был классик. Суперсервер не справлялся с нагрузкой (не умеет расползаться по ядрам).

Raid Intel (R) RAID Controller RS2BL080, 512 рамы, writeback включен, батарейка на месте

Картинка с другого сайта.
Картинка с другого сайта.
Картинка с другого сайта.. Агрегация идет по максимуму, а каждую ночь гоняются бэкапы, по этому цифры огромные. На самом деле IO не превышает того что на первом графике. с tmpfs для /tmp игрался, не помогает абсолютно.
Page buffers выбрано опытным путем, потому что иногда разрастается число соединений, и память заканчивается. Правда это было еще на прошлом серваке, на этом можно и поднять (разницы все равно никакой небыло).

Система такси, активно до 10 диспов одновременно (у них очень тяжелые клиенты на дельфи, FIB+, транзакции закрываются периодически, потому и 2к активных, для справочников используются read-only транзакции), 1к водил (там самописный java сервер, использует пул соединений на 10 соединений.) Жалуются именно диспетчера.
Dimitry Sibiryakov
Дата: 04.06.2012 00:22:13

farafonoff
Жалуются именно диспетчера.

Выясняй на какие конкретно запросы жалуются, выясняй почему именно они замедляются. Может,
они мусор вынуждены собирать - это покажет статистика, gstat тебе в руки.

Posted via ActualForum NNTP Server 1.5

farafonoff
Дата: 04.06.2012 00:32:51
Медленно у них начинают работать любые запросы. У них в интерфейсе несколько окошек, в каждом DataGrid, и периодически тормозит какой-то из них (любой, тормозят все). В gstat уже проковырял все что можно. Меня интересует вопрос что меняется при backup/restore, и гонял ли кто-нибудь в круглосуточном режиме firebird много месяцев без этой процедуры?
Dimitry Sibiryakov
Дата: 04.06.2012 00:45:37

farafonoff
В gstat уже проковырял все что можно. Меня интересует вопрос что меняется при backup/restore

Эти два предложения противоречат друг другу, поскольку gstat выводит (почти) всю
информацию о БД. Ты уж определись...

Posted via ActualForum NNTP Server 1.5

Dimitry Sibiryakov
Дата: 04.06.2012 00:54:17

farafonoff
В gstat уже проковырял все что можно.

Чтобы не было обвинений в троллинге, не буду мучить: берёшь результат gstat -a -r в начале
цикла, при тормозах и несколько промежуточных. Вытаскиваешь из них цифры в офис, строишь
графики. Потом долго на них медитируешь.

farafonoff
гонял ли кто-нибудь в круглосуточном режиме firebird много месяцев без
этой процедуры?

А как, ты думаешь, люди натыкаются на предел числа транзакций в 2^31-1 на инкарнацию БД?..

Posted via ActualForum NNTP Server 1.5