iBase.ru Forum

Добрый день!

Сразу скажу, что в Firebird и БД в целом я новичок, и, несмотря на это, прошу помочь разобраться (хотя бы указать, в каком направлении дальше копать) в следующей ситуации:

Имеется две реплицирующихся между собой удалённых БД на Firebird размером почти 70gb каждая. Одновременно с ними работают около 70 пользователей (20 с одной базой, 50 с другой). Периодически (раз в 2 недели/месяц) случалась 100% загруженность дисковой подсистемы сервера, исправить которую удавалось только остановкой сервера и дальнейшим backup/restore. После введения в строй третьей БД и добавления 10 пользователей, подобное стало происходить заметно чаще (раз в 2 дня-неделю).

Железо используется разнообразное, смысла его приводить не вижу. Что на старых серверах проблема, что на новых с SAS-овскими дисками. Софт-конфигурации на серверах практически идентичны друг другу - FreeBSD 7.2, Firebird 2.03, настройки аналогичны. Большую часть базы (по массе) занимают фотографии (200кб-1,5 мб). Непосредственно таблицы, около 4gb.

Попробовал проанализировать лог IBAnalyst'ом (вер.1.9.5, через Services API),
вот мои рассуждения:
1) Программная и аппаратная конфигурация железа в данном случае если и влияет на ситуацию то незначительно;
2) По какой-то причине некоторые транзакции (довольно много) не завершаются, остаются висеть... Но это тоже не должно оказывать влияния на сабж;
3) Индексы. Очень похоже на то, что собака как раз в них и зарылась. Очень мало уникальных ключей.
4) Сборка мусора. Первое, что я попробовал сделать - отключил автоматическую сборку мусора в одной БД (с которой, собственно, и выложил выше лог). На проблеме это никак не сказалось.
5) Размер страниц БД равен 4096байт, а блоков файловой системы - 1024. Стоит ли менять? Если да, то на что? 16384 и 16384?

Заранее спасибо.

IBAnalyst производит разовый анализ статистики, а тебе нужно следить в динамике. С этим - к FBDataGuard. За "отключение автоматической сборки мусора" без предварительного анализа ситуации - пожизненный эцик с гвоздями.

Приложение не умеет работать с тр-циями, есть долгоиграющие тр-ции

Oldest transaction 704107
Oldest active 704108
Oldest snapshot 704108
Next transaction 827634

что приводит к накоплению мусора, вот только два примера

AGREEMENTS (184)
Primary pointer page: 2186, Index root page: 2187
Average record length: 288.83, total records: 29853
Average version length: 38.69, total versions: 2142, max versions: 28

ANNOUNCEMENT (391)
Primary pointer page: 2606, Index root page: 2607
Average record length: 1200.69, total records: 102667
Average version length: 227.05, total versions: 64062, max versions: 48

Индексов не много, а очень много.
Если уж отключили авто-свип, то нужно делать его вручную, например каждую ночь.

Кластер файловой системы 1КБ - это уже повод для расстрела админа.
Я бы рекомендовал кластер ФС <= страница БД, например 4\4, 4\8, 8\8.

Freebsd не самая лучшая (протестированная, используемая) ОС для Firebird.

по пункту 2 - вывод очень смешной, типа "не влияет", Вы бы хоть раз прочитали
www.ibase.ru/devinfo/mga.htm и соответствующие статьи. В общем, про курсы и платные консультации я уже сказал.

Dimitry Sibiryakov писал(а):IBAnalyst производит разовый анализ статистики, а тебе нужно следить в динамике. С этим - к FBDataGuard. За "отключение автоматической сборки мусора" без предварительного анализа ситуации - пожизненный эцик с гвоздями.

По поводу разового анализа статистика - да, знаю. Я периодически снимаю логи. Этот лог снят при "нормальной" работе БД, после установки IBAnalyst вышеописанной проблемы ещё не наблюдалось,

Что качается динамики и FBDataGuard - спасибо, буду изучать!

hvlad писал(а):Приложение не умеет работать с тр-циями, есть долгоиграющие тр-ции, что приводит к накоплению мусора
...
Индексов не много, а очень много.

Приложение написано штатными прогерами. Будем разбираться с проблемой.

hvlad писал(а):Если уж отключили авто-свип, то нужно делать его вручную, например каждую ночь.

Видимо, включу обратно, т.к. ещё не готов к ручному сбору)

hvlad писал(а):Кластер файловой системы 1КБ - это уже повод для расстрела админа.
Я бы рекомендовал кластер ФС <= страница БД, например 4\4, 4\8, 8\8.

Скорее всего перейдём на 8/8

hvlad писал(а):Freebsd не самая лучшая (протестированная, используемая) ОС для Firebird.

В принципе, сама система работает уже несколько лет, довольно стабильно (до последнего времени). Думаю разобраться с косяками в самой базе и программах, работающих с ней, а уж потом можно и с ОС экспериментировать.

kdv писал(а):по пункту 2 - вывод очень смешной, типа "не влияет", Вы бы хоть раз прочитали
http://www.ibase.ru/devinfo/mga.htm и соответствующие статьи. В общем, про курсы и платные консультации я уже сказал.

Вывод я такой сделал, исходя из собственной неопытности, спасибо, что поправил) Почему-то подумал, что долгоиграющие транзакции могут висеть в памяти, подгружать проц, но к дисковой системе не причастны. Ушёл учить матчасть)

Всем спасибо за советы, будем разбираться. О результатах, проинформирую)