Растет размер БД Firebird (совсем не линейно)
Модераторы: kdv, Alexey Kovyazin
Растет размер БД Firebird (совсем не линейно)
Добрый день! Есть следующая проблема:
есть БД, работает уже 3-4 года активно, ежедневный объем данных растет не значительно (в теории).
База до начала этого года была в пределах 10-12 Гб (Бекап 5-7 Гб). В этом году наблюдаю резкое увеличение прожорливости - прирост по 4-5 Гб в месяц, в результате БД = 40 Гб (бекап - 36 Гб). Делаю бекап-ресторе - максимум худеет на пару гектар. Ресторил на разных машинах, результат одинаковый. Попробовал сравнить статистику с начала года и на сегодня - разница по месту, занимаемого таблицами - была 2,5 Гб, стала 3,5 Гб грубо. (Т.е. никак не в 3-4 раза). Вроде индексы в пределах 3-ки. Подскажите, хоть в какую сторону копать, сам кодер, не чистый системщик (но админить приходится все равно все это мне), но в этот раз я не вижу решения.
П.С. БД крутится на HP ML350 3-летнем, под ASP Linux, Firebird 2.1.1 вроде бы (с пингвином совсем туго дружу, на уровне починить базу безопасности да запустить бекап-ресторе-гфикс).
П.П.С. ресторе на сервере почему-то делается часов 6-7, хотя на моей рабочей машинке (совсем печальный Целерончик под XP) делается 1,5 часа
есть БД, работает уже 3-4 года активно, ежедневный объем данных растет не значительно (в теории).
База до начала этого года была в пределах 10-12 Гб (Бекап 5-7 Гб). В этом году наблюдаю резкое увеличение прожорливости - прирост по 4-5 Гб в месяц, в результате БД = 40 Гб (бекап - 36 Гб). Делаю бекап-ресторе - максимум худеет на пару гектар. Ресторил на разных машинах, результат одинаковый. Попробовал сравнить статистику с начала года и на сегодня - разница по месту, занимаемого таблицами - была 2,5 Гб, стала 3,5 Гб грубо. (Т.е. никак не в 3-4 раза). Вроде индексы в пределах 3-ки. Подскажите, хоть в какую сторону копать, сам кодер, не чистый системщик (но админить приходится все равно все это мне), но в этот раз я не вижу решения.
П.С. БД крутится на HP ML350 3-летнем, под ASP Linux, Firebird 2.1.1 вроде бы (с пингвином совсем туго дружу, на уровне починить базу безопасности да запустить бекап-ресторе-гфикс).
П.П.С. ресторе на сервере почему-то делается часов 6-7, хотя на моей рабочей машинке (совсем печальный Целерончик под XP) делается 1,5 часа
Re: Растет размер БД Firebird (совсем не линейно)
gstat -h покажите
Re: Растет размер БД Firebird (совсем не линейно)
еще желательно с периодичностью в несколько дней получать gstat -a -r база -user ... -pass ... >stat.txt, и анализировать это дело IBAnalyst-ом (или сразу им получать статистику)
Re: Растет размер БД Firebird (совсем не линейно)
Статистика заголовка
тут единственное что меня смущает - это "Next transaction", вчера был 61643 кстати. но на локальной копии, которую поднял для теста, этот параметр в норме, т.е. на единицу больше чем "Oldest snapshot" - но на размере базы это никак не сказалось - все также печально
Скажите, пожалуйста, как сюда корректно выложить файл полной статистики?
(хотя там кроме индексов и десятка пустых таблиц IBАнализатор вроде бы не жалуется особо)
Код: Выделить всё
Database header page information:
Flags 0
Checksum 12345
Generation 104714
Page size 16384
ODS version 11.1
Oldest transaction 609
Oldest active 610
Oldest snapshot 610
Next transaction 104706
Bumped transaction 1
Sequence number 0
Next attachment ID 129
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Sep 4, 2011 12:08:19
Attributes
Variable header data:
Sweep interval: 20000
*END*
Скажите, пожалуйста, как сюда корректно выложить файл полной статистики?
(хотя там кроме индексов и десятка пустых таблиц IBАнализатор вроде бы не жалуется особо)
Re: Растет размер БД Firebird (совсем не линейно)
Сборка мусора остановлена, БД ничего больше не остаётся как только расти.
Re: Растет размер БД Firebird (совсем не линейно)
я конечно профан честно говоря во всем этом, но в эту сторону начал копать на локальной копии. По пунктам - я взял бекап рабочей базы, восстановил на своем компе, сделал ручной gfix -sweep db.gdb, сделал бекап-ресторе на своем компе - Некст транзактион маленький, а вот результата по размеру так и не получил. Поэтому я и не стал делать сборку мусора ручную на рабочей базе (это возможно только в выходные или ночью, на всякий пожарный).
После Вашего замечания пошел еще разок внимательно перечитаю статьи про мусор.
После Вашего замечания пошел еще разок внимательно перечитаю статьи про мусор.
Re: Растет размер БД Firebird (совсем не линейно)
значит за сутки надолбили 45 тысяч транзакций. Значит, базу ресторили из бэкапа примерно 2-3 суток назад. И судя по застрявшему Oldest transaction, возможно есть некие приложения, которые эти двое-трое суток подключены к базе.это "Next transaction", вчера был 61643 кстати.
прислать в zip/rar на support@ibase.ruСкажите, пожалуйста, как сюда корректно выложить файл полной статистики?
Re: Растет размер БД Firebird (совсем не линейно)
Это значит, что в БД примерно 36ГБ данных, не считая индексов и прочего.nbura писал(а):БД = 40 Гб (бекап - 36 Гб).
Ну так с чего бы ей худеть ?nbura писал(а):Делаю бекап-ресторе - максимум худеет на пару гектар.
По капоту стучал ? Стёкла протирал ?nbura писал(а):Ресторил на разных машинах, результат одинаковый.
А вот тут - подробнее. Что за статистика, как считается ?nbura писал(а):Попробовал сравнить статистику с начала года и на сегодня - разница по месту, занимаемого таблицами - была 2,5 Гб, стала 3,5 Гб грубо.
Re: Растет размер БД Firebird (совсем не линейно)
постараюсь ответить сразу двоим ув. собеседникам, чтобы лишний раз не флудить)
факты:
1. да, базу бекап-ресторнул в это воскресенье, база работает в обычное рабочее время, всегда ,кроме воскресенья (просто для справки).
2. база не моя, наследственная, стараюсь конечно в ней порядок по ходу дела наводить, но у предыдущего черта был свой, отдельный учебник по СУБД, с блджеком и прочими видать. Так что индексы были не те или не там, никаких внешних ключей, все запросы конструктором в иб эксперте, про доствшийся продукт на Делфи и говорить неохота. (даже не знаю, зачем я это написал, просто наболело видать )
3.
4.
поэтому и вызывает недоумение, что за 3 года она доросла до 12 Гб, а за 8 месяцев сего года - уже 40Гб стала.
5.
6. на всякий случай кину на почту архив результатов статистики, честно говоря не понял из текста, будет он вам полезен или нет, если что удалите
7. Ночью ребутну сервис файербёрда на сервере для чистоты и сделаю gfix -sweep конечно же.
П.С. в принципе основная цель моих телодвижений - понять, БД должна быть такого размера при текущих данных, или есть необходимость её подчистить-подправить. Т.е. постараюсь зря не отнимать Ваше время.
факты:
1. да, базу бекап-ресторнул в это воскресенье, база работает в обычное рабочее время, всегда ,кроме воскресенья (просто для справки).
2. база не моя, наследственная, стараюсь конечно в ней порядок по ходу дела наводить, но у предыдущего черта был свой, отдельный учебник по СУБД, с блджеком и прочими видать. Так что индексы были не те или не там, никаких внешних ключей, все запросы конструктором в иб эксперте, про доствшийся продукт на Делфи и говорить неохота. (даже не знаю, зачем я это написал, просто наболело видать )
3.
по поводу рестора на разных машинах - предположил, чтобы исключит вероятность кривой установки сервера или еще чего случайного.По капоту стучал ? Стёкла протирал ?
4.
наполнение базы идем, можно сказать пропорционально, объем ежедневных операций вырос, но не в разы, может в полтора раза, может чуть больше.Ну так с чего бы ей худеть ?
поэтому и вызывает недоумение, что за 3 года она доросла до 12 Гб, а за 8 месяцев сего года - уже 40Гб стала.
5.
Попробовал сравнить статистику с начала года и на сегодня - разница по месту, занимаемого таблицами - была 2,5 Гб, стала 3,5 Гб грубо.
результаты gstat выкинуты в таблицу, и просуммированы столбцы размера таблиц (понимаю что это не точные размеры данные, но просто хотел увидеть, откуда увеличение размера пошло)А вот тут - подробнее. Что за статистика, как считается ?
6. на всякий случай кину на почту архив результатов статистики, честно говоря не понял из текста, будет он вам полезен или нет, если что удалите
7. Ночью ребутну сервис файербёрда на сервере для чистоты и сделаю gfix -sweep конечно же.
П.С. в принципе основная цель моих телодвижений - понять, БД должна быть такого размера при текущих данных, или есть необходимость её подчистить-подправить. Т.е. постараюсь зря не отнимать Ваше время.
Re: Растет размер БД Firebird (совсем не линейно)
в IBA я вижу чистых голых данных 1.8 гиг, индексов 1 гиг. Если база при этом 40 гиг (и бэкап 36), значит вывод очень простой - в базе 37 гиг БЛОБОВ. Картинок, документов, и прочего.в результате БД = 40 Гб (бекап - 36 Гб)
Даже если брать таблицы, фрагментированные блобами, то там выходит страниц с данными (не блобами) не более чем на 5 гиг.
Действительно, Oldest Active (не Oldest transaction, я ошибся) торчит уже 2 дня, т.е. эти два дня существует приложение с активной транзакцией, которая мешает сборке мусора. Мусор накопился в таблице
ER_T_ZAY_MAT - там 1.6 млн версий при 110к записей. Это может быть причиной тормозов.
Все это и многое другое прекрасно видно в IBAnalyst (в. т.ч. в Отчете).
Индексов тоже много ненужных (по именам видно, что созданных вручную, и имеющих 1 уникальное значение)
В общем, блобами заполнена ваша база. И чем дальше, тем их больше, и они больше.
Re: Растет размер БД Firebird (совсем не линейно)
добавлю - может, в базу кто-то несколько фильмов залил?
-
- Сообщения: 15
- Зарегистрирован: 25 окт 2004, 19:13
Re: Растет размер БД Firebird (совсем не линейно)
Таблица construction_data имеет реальную фрагментацию в 1%, т.е. блобы заполонили наши улицы .
Как это ни странно, может помочь уменьшение размеров страницы до 4к. Попробуйте.
С уважением,
Алексей Ковязин
IBSurgeon (www.ib-aid.com)
Как это ни странно, может помочь уменьшение размеров страницы до 4к. Попробуйте.
С уважением,
Алексей Ковязин
IBSurgeon (www.ib-aid.com)
Re: Растет размер БД Firebird (совсем не линейно)
не, Алексей, лучше не надо уменьшать размер страницы. Пусть "киборги - они захватили всю планету", но бОльших блобов-то все равно там 80% базы. И со страницей в 4к общая производительность может ухудшиться. Хотя, неизвестно, как приложение с этими блобами оперирует. Тем более что приложение "унаследованное", и ковырять его уже никто не будет, как я понял.
Вдогонку автору:
1. в контроллере сервера дисковый кэш выключен (WriteThrough вместо WriteBack). Либо просто выключен, либо батарейки нет, и т.д.
2. в винде рестор делается через лок. протокол, на линуксе - через tcp
см. http://www.ibase.ru/devinfo/restorespeed.htm
обратить внимание на линуксовую картинку. Там бэкап 1.5 гиг, результирующая база 4 гига.
На линуксе рестор по tcp в 4-5 раз медленнее локального протокола почему-то.
Вдогонку автору:
предположений 2ресторе на сервере почему-то делается часов 6-7, хотя на моей рабочей машинке (совсем печальный Целерончик под XP) делается 1,5 часа
1. в контроллере сервера дисковый кэш выключен (WriteThrough вместо WriteBack). Либо просто выключен, либо батарейки нет, и т.д.
2. в винде рестор делается через лок. протокол, на линуксе - через tcp
см. http://www.ibase.ru/devinfo/restorespeed.htm
обратить внимание на линуксовую картинку. Там бэкап 1.5 гиг, результирующая база 4 гига.
На линуксе рестор по tcp в 4-5 раз медленнее локального протокола почему-то.
Re: Растет размер БД Firebird (совсем не линейно)
Добрый день, уважаемые коллеги!
Итак, по порядку:
1. мусор ручками собрал, статистика заголовка выглядит теперь так
2. С версионностью таблицы "ER_T_ZAY_MAT" разобрался, действительно, был мой косяк - был запрос, обнуляющий один столбец почти по всем записям, исправил условие, версии не плодятся.
3. Главный подозреваемый: таблица "construction_data" - по структуре - там используется одно блоб поле, ранее туда лились картинки (эти данные уже потерли давно), теперь льются EMF, что как бы гораздо экономичнее. И как раз размер этих файликов - от 3 до 10+ кб (подозреваю, что среднее около 5 -6 наверное). Записей в этой таблице, имеющих ненулевой блоб - около 100 000 (есть, кстати желание спросить шефа насчет удаления блобов допустим до 2009 года - это треть записей где-то).
Для эксперимента создал локальную тестовую базу только с этой таблицей, скопировал последнии 2500 записей. (для переноса использовал экспорт данных из запроса, собственно файл с данными - 25 метров, что подтверждает предположение о среднем размере Блобов+размер записи). Бекап тестовой базы - теже 25-26 метров, т.е все честно . Затем тестил восстановление с разными размерами страниц, логично, что уменьшение страницы в данном случае давало результат:
16к Page = 44 M DB
8к Page = 39 M DB
4к Page (и все что меньше) = 33 M DB
(Для справки, файл экспорта для всех данных этой таблице занял 500 М)
Соответсвенно напрашивается вопрос - есть смысл восстановить БД с размером 8 или 4? Если учесть, что остальные блобы практически не влияют на размер, их там по пальцам?
4. Вопрос немного не по теме - есть ли смысл включать синхронный режим (Forced Write) в моем случае?
Итак, по порядку:
1. мусор ручками собрал, статистика заголовка выглядит теперь так
Код: Выделить всё
Database header page information:
Flags 0
Checksum 12345
Generation 186518
Page size 16384
ODS version 11.1
Oldest transaction 160445
Oldest active 160446
Oldest snapshot 160446
Next transaction 186509
Bumped transaction 1
Sequence number 0
Next attachment ID 214
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Sep 4, 2011 12:08:19
Attributes
Variable header data:
Sweep interval: 20000
*END*
3. Главный подозреваемый: таблица "construction_data" - по структуре - там используется одно блоб поле, ранее туда лились картинки (эти данные уже потерли давно), теперь льются EMF, что как бы гораздо экономичнее. И как раз размер этих файликов - от 3 до 10+ кб (подозреваю, что среднее около 5 -6 наверное). Записей в этой таблице, имеющих ненулевой блоб - около 100 000 (есть, кстати желание спросить шефа насчет удаления блобов допустим до 2009 года - это треть записей где-то).
Для эксперимента создал локальную тестовую базу только с этой таблицей, скопировал последнии 2500 записей. (для переноса использовал экспорт данных из запроса, собственно файл с данными - 25 метров, что подтверждает предположение о среднем размере Блобов+размер записи). Бекап тестовой базы - теже 25-26 метров, т.е все честно . Затем тестил восстановление с разными размерами страниц, логично, что уменьшение страницы в данном случае давало результат:
16к Page = 44 M DB
8к Page = 39 M DB
4к Page (и все что меньше) = 33 M DB
(Для справки, файл экспорта для всех данных этой таблице занял 500 М)
Соответсвенно напрашивается вопрос - есть смысл восстановить БД с размером 8 или 4? Если учесть, что остальные блобы практически не влияют на размер, их там по пальцам?
4. Вопрос немного не по теме - есть ли смысл включать синхронный режим (Forced Write) в моем случае?
Re: Растет размер БД Firebird (совсем не линейно)
Дополнение: если есть необходимость, я правлю и базу и клиента.Тем более что приложение "унаследованное", и ковырять его уже никто не будет, как я понял.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Растет размер БД Firebird (совсем не линейно)
У тебя в базе висит чертовски длинная snapshot транзакция. Посмотри в таблицах мониторинга кому она принадлежит и убей (хозяина, не транзакцию).
Re: Растет размер БД Firebird (совсем не линейно)
1. Влад уже сказал - действительно опять висит транзакция. при 50к транзакций в день отставание на 6к это примерно 1/10 рабочего времени, т.е. при 8 часовом приложении транзакция активна около часа. Это как бы намек, что в перспективе оно может превратиться и в трое суток, как в твоем первом примере.
2. ок
3. фиг с ней
по скорости оптимальный размер страницы это 8-16к. 4к это уже мало для нынешних баз, тем более для базы в 40 гиг.
Подавляюще бОльшая часть вашей БД составляет блобы. Поэтому нужно оценивать не размер данных (в какие-то несчастные 39-44 мб), а скорость работы с блобами. Подозреваю, что вы разницу между 8 и 16к на своей большой базе не увидите.
- что такое Forced Writes вобще - http://www.ibase.ru/ibfaq.htm#fwoff.
- с соответствующими пунктами в firebird.conf
- выяснить, есть-ли батарейка на raid
- есть-ли UPS.
если ответы на пункты 2 и 3 - да, то можно включить FW. Вообще по умолчанию FW включен.
2. ок
3. фиг с ней
такое впечатление, что все что я пишу - игнорируетсяесть смысл восстановить БД с размером 8 или 4?
по скорости оптимальный размер страницы это 8-16к. 4к это уже мало для нынешних баз, тем более для базы в 40 гиг.
Подавляюще бОльшая часть вашей БД составляет блобы. Поэтому нужно оценивать не размер данных (в какие-то несчастные 39-44 мб), а скорость работы с блобами. Подозреваю, что вы разницу между 8 и 16к на своей большой базе не увидите.
перед выключением (вообще-то) Forced Writes нужно ознакомитьсяесть ли смысл включать синхронный режим (Forced Write) в моем случае?
- что такое Forced Writes вобще - http://www.ibase.ru/ibfaq.htm#fwoff.
- с соответствующими пунктами в firebird.conf
- выяснить, есть-ли батарейка на raid
- есть-ли UPS.
если ответы на пункты 2 и 3 - да, то можно включить FW. Вообще по умолчанию FW включен.
Re: Растет размер БД Firebird (совсем не линейно)
добавлю, что если уж уменьшать размер страницы, то неплохо бы соответственно увеличить размер кеша. А то эффект может оказаться обратным.
Re: Растет размер БД Firebird (совсем не линейно)
Уважаемые собеседники, спасибо всем отвечавшим! С вашей помощью я упорядочил всю кашу в своей голове, надеюсь теперь в ней глупых истерик не возникнет . Наконец то научился нормально использовать IBA, до этого не было особой нужды.
По теме:
1. думаю при регулярной сборке мусора и периодическом ресторе базы транзакции меня волновать не будут.
2. насчет размера страниц и подозрения на необоснованно увеличение размера базы - это я тоже не подумал, так как: бекап то все равно был почти размером с БД, так что размер страниц, фрагментирование - это все не имеет отношение к моей проблеме.
3. при более внимательном иследовании БД обнаружил несколько таблиц-логов и таблиц, вышедших из работы еще 3 года назад. К тому же было включено логирование IBE$LOG****. Подукоротив все эти таблички, получил уменьшение ночного бекапа на 60%. В воскресенье сделаю ресторе - думаю и база будет в пределах 20 Гб.
Итог: размер БД - это моя невнимательность, ничего военного там не было. А вот тема мусора/версий и его ежедневного прироста - спасибо Вам, упорядочил, быстродействие ощутимо возросло.
П.С. FW решил не трогать пока, бесперебойник есть, рейд есть, до этого база никогда не портилась при мне (хотя свет бывает рубят раз в пару месяцев).
П.П.С. Вопрос не по теме: если я перед ресторе переименновал БД , заресторил со старым названием, то все клиентские приложения по прежнему работали со старой БД, хотя она и переименованная была (ребут сервиса Firebird ситуацию не изменял, а вот перезагрузка сервера - ставила все на свое место). Это какая-то особенность работы Firebird под Линуксом (или может это FW OFF как раз так себя ведет)? Как я уже и говорил, в Линуксе я баран.
А так тему можно закрывать, еще раз - Всем говорю спасибо
По теме:
1. думаю при регулярной сборке мусора и периодическом ресторе базы транзакции меня волновать не будут.
2. насчет размера страниц и подозрения на необоснованно увеличение размера базы - это я тоже не подумал, так как: бекап то все равно был почти размером с БД, так что размер страниц, фрагментирование - это все не имеет отношение к моей проблеме.
3. при более внимательном иследовании БД обнаружил несколько таблиц-логов и таблиц, вышедших из работы еще 3 года назад. К тому же было включено логирование IBE$LOG****. Подукоротив все эти таблички, получил уменьшение ночного бекапа на 60%. В воскресенье сделаю ресторе - думаю и база будет в пределах 20 Гб.
Итог: размер БД - это моя невнимательность, ничего военного там не было. А вот тема мусора/версий и его ежедневного прироста - спасибо Вам, упорядочил, быстродействие ощутимо возросло.
П.С. FW решил не трогать пока, бесперебойник есть, рейд есть, до этого база никогда не портилась при мне (хотя свет бывает рубят раз в пару месяцев).
П.П.С. Вопрос не по теме: если я перед ресторе переименновал БД , заресторил со старым названием, то все клиентские приложения по прежнему работали со старой БД, хотя она и переименованная была (ребут сервиса Firebird ситуацию не изменял, а вот перезагрузка сервера - ставила все на свое место). Это какая-то особенность работы Firebird под Линуксом (или может это FW OFF как раз так себя ведет)? Как я уже и говорил, в Линуксе я баран.
А так тему можно закрывать, еще раз - Всем говорю спасибо
Re: Растет размер БД Firebird (совсем не линейно)
это особенность линукса. можно хоть удалить файл, но если он открыт каким-то процессом ФБ, то этот процесс будет и дальше работать с этим файлом.то все клиентские приложения по прежнему работали со старой БД