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

Посоветуйте как оптимизировать производительность. Симптомы следующие: База данных размером 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 базы данных. Какие данные можно еще собрать, чтобы решить эту проблему?

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)

приложение сами писали? что-то у вас дофига транзакций - 2.2 миллиона в сутки.
Потом, сервер Classic? кто зашил в базу page buffers 1000 ?
http://www.ibase.ru/techsupp.htm

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

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

Posted via ActualForum NNTP Server 1.5

Дисковой активности не показано, база хоть и меньше размера ОЗУ, но таки нормального объема, а дисков судя по вводным всего 2. Дисковый контроллер с собственным кэшем и райтбэк политикой кэширования, я надеюсь, имеется?

Сервер суперклассик(сейчас), до того был классик. Суперсервер не справлялся с нагрузкой (не умеет расползаться по ядрам).

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



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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

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

Posted via ActualForum NNTP Server 1.5