powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Firebird (gbak restore) и ОЗУ
25 сообщений из 37, страница 1 из 2
Firebird (gbak restore) и ОЗУ
    #38929881
morcano
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вечер добрый.
Есть *fdb база (размер ~60гб), конфигурация сервера:
ПО - Win2008R2 + Firebird 2_1 Classic Server
Железо - Intel Xeon 5620 (x2), RAID10, 48GB RAM (В данный момент пока что стоит Standard версия ОС - видно только 32)
Клиентов ~ 150 ч.

По мере роста базы появилась проблема, заключается в следующем:
относительно недавно процедура restore которая раньше в среднем занимала ~4-7 часов сейчас выполняется почти сутки.
Restore выполняется с ключом "-v" - никаких ошибок я не заметил, все как обычно, но гораздо медленнее чем раньше.
По завершении, тот прирост производительности который был раньше ощутим (после прогона "бекап-рестор") перестал быть виден.

Делаю как обычно так:
автор-rep -c -user SYSDBA -password masterkey -g g:\backup.fbk f:\base.fdb -v -se localhost:service_mgr

dbstat (база после рестора)
авторDatabase header page information:
Flags 0
Checksum 12345
Generation 22557
Page size 16384
ODS version 11.1
Oldest transaction 22532
Oldest active 22533
Oldest snapshot 22533
Next transaction 22536
Bumped transaction 1
Sequence number 0
Next attachment ID 13
Implementation ID 26
Shadow count 0
Page buffers 3000
Next header page 0
Database dialect 3
Creation date Apr 6, 2015 10:40:48
Attributes no reserve

Variable header data:
Sweep interval: 0
*END*


При restore мониторил ресурсы - дисковая подсистема почти не участвует, но довольно много ест ОЗУ. Получается, что объем ОЗУ нужно подгонять ближе к размеру самой базы? Пришел к этому выводу после тестов на более мощном железе, где размер оперативной памяти был 64 гб (из них около 50 свободно) - ближе к концу процедуры восстановления память была забита под завязку..
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38929925
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morcanoДелаю как обычно так:
-rep -c
ну откуда ты, прости господи, взял этот бред в опциях?
http://www.ibase.ru/devinfo/gbak.htm

morcanoPage buffers 3000
зачем размер кэша прописан в файле БД?

Какая точная версия Firebird?
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38929936
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morcanoПри restore мониторил ресурсы - дисковая подсистема почти не участвует, но
довольно много ест ОЗУ.
Добавь к ключам при восстановлении -O.

И забудь про "ускорение через бэкап-рестор", ищи более правильные пути, читай ibase.ru.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38929956
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morcanoПо завершении, тот прирост производительности который был раньше ощутим (после прогона "бекап-рестор") перестал быть виден.

Делаю как обычно так:
автор-rep -c -user SYSDBA -password masterkey -g g:\backup.fbk f:\base.fdb -v -se localhost:service_mgr

dbstat (база после рестора)
авторDatabase header page information:
Flags 0
Checksum 12345
Generation 22557
Page size 16384
ODS version 11.1
Oldest transaction 22532
Oldest active 22533
Oldest snapshot 22533
Next transaction 22536
Bumped transaction 1
Sequence number 0
Next attachment ID 13
Implementation ID 26
Shadow count 0
Page buffers 3000
Next header page 0
Database dialect 3
Creation date Apr 6, 2015 10:40:48
Attributes no reserve

Variable header data:
Sweep interval: 0
*END*




По производительности делаю предположение - клиент sweep interval выставил в 0 и руками его ни разу не запускал + бэкап без уборки мусора (-g), вот они и потери производительности. Сразу вопросы:
1. Что за софт?
2. Sweep когда последний раз сам запускал?
3. Спасительный backup-restor когда последний раз делал?
По производительности - Дима прав, backup-restore это не выход, особенно для режима работы 24/7.
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38929957
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
4. b/r как часто делаешь? И по какой причине - потеря производительности или по расписанию? Вопрос 3 можешь не отвечать.
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38929963
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
Attributes	no reserve
А это зачем?
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38929988
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morcanoStandard версия ОС - видно только 32По какой причине стоит недоОСь, которая не использует все ресурсы? Причем ресурс САМЫЙ критический с точки зрения приозводительности.

Поставь полноценный линукс и пользуйся всей памятью.


morcanoПо завершении, тот прирост производительности который был раньше ощутим (после прогона "бекап-рестор") перестал быть виден.Наличие прироста после б/р может говорить только о кривости прикладной софтины и никаго администрирования в части чиски мусора.

Мы делаем бэкап-рестор практически только при смене версий ФБ. нагрузка-железо сопоставимое, плюс-минус лапоть.
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930239
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_PisarevskyПоставь полноценный линукс и пользуйся всей памятью.

Если есть UDF для линукс.
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930308
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Gallemar!
You wrote on 8 апреля 2015 г. 12:37:59:

Gallemar> Если есть UDF для линукс.udf - зло.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930325
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

а в чём сложности. С++ легко переносится между различными платформами. Не нравится C++ пиши на Lazarus.

P.S. Насчёт зла согласен с МП
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930519
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор исчез, а я еще раз пересмотрел исходное сообщение, и теперь теоретизирую более конкретно:

morcanoотносительно недавно процедура restore которая раньше в среднем занимала ~4-7 часов сейчас выполняется почти сутки.
нужно найти, что поменялось в этом интервале. Потому что "почти сутки" и 7 часов - это разница в 3 раза.

morcanoПри restore мониторил ресурсы - дисковая подсистема почти не участвует, но довольно много ест ОЗУ
скорее всего проблема в том, что винда пытается бэкап удержать в файловом кэше ОС, и с течением времени все остальное выпадает в виртуалку.
Это описано тут
http://dyemanov.blogspot.ru/2012/03/firebird-vs-windows-file-system-caching.html

CORE-3791 исправлен в 2.1.5 и 2.5.2. для 2.1 сейчас последняя версия 2.1.7. Начать нужно с обновления ФБ на последнюю 2.1, и дальше проверить restore.
(я именно поэтому и спрашивал про точную версию ФБ).
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930548
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvнужно найти, что поменялось в этом интервале. Потому что "почти сутки" и 7 часов
- это разница в 3 раза.
Например, данные для индексов перестали помещаться в память и сортировка уходит на диск.
Отсюда же и "backup/restore для ускорения перестал помогать".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930598
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисGallemar,

а в чём сложности. С++ легко переносится между различными платформами. Не нравится C++ пиши на Lazarus.

P.S. Насчёт зла согласен с МП
В обслуживаемой софтине в БД 200 с лишним UDF на паскале, исходного кода у меня нет, уже год долбаю разработчика чтобы переписал для Linux. Так что не для всех миграция Win-> Lin проста.
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930654
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gallemar,

в FB сейчас море встроенных функций. Если ты знаешь что делает каждая из этих UDF, то можешь подумать как их заменить на встроенные функции. 200 UDF это конечно мощно. Конечно есть ещё вещи которые без UDF сделать проблематично, но скорее всего после прочёсывания кода их не должно остаться более 20. А эти 20 при большом желании зная что они делают можно и самому переписать.

P.S. Когда я обновлял базу с FB 1.5 до FB2.5 мне пришлось месяца три UDFки выпиливать и заменять их на встроенные функции. Но это того стоит.
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930709
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Gallemar!
You wrote on 8 апреля 2015 г. 15:58:47:

Gallemar> в БД 200 с лишним UDF на паскале
мочить казлов! (с)
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930712
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Симонов Денис!
You wrote on 8 апреля 2015 г. 15:59:44:

Симонов Денис> UDFки выпиливать и заменять их на встроенные функции. Но это того стоит.
+1

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930717
morcano
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Версия FB на текущий момент - 2.1.1.1.17910 (x64)
Делал только что restore с ключом -о (про "-c" + "-rep" почитал - исправился)) на своей рабочей машине (8gb ОЗУ), в диспетчере загруженность памяти была ~50% после чего рестор мне выдал:
авторERROR: unable to allocate memory from operating system
Хотя раньше (пару месяцев назад, когда база была "худее" гигов на 10) - на рабочей машине спокойно ресторил бекапы...

Вчера так же тестил на другом сервере в котором стоит 64гб ОЗУ (10 было загружено) - заняло ~ 8 часов. Данные результаты наводят на мысль, что наверное я все таки уперся в оперативку...

По поводу сборки мусора - каюсь, но ни разу не делал вручную. Сейчас на копии попробую. По поводу улучшения производительности после этой операции понятно, непонятен момент с размером базы, меняет ли она после этого свой размер?
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930734
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morcanoПо поводу улучшения производительности после этой операции понятно, непонятен момент с размером базы, меняет ли она после этого свой размер?

А зачем? Освобождённое пространство может использоваться повторно
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930737
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Morcano!
You wrote on 8 апреля 2015 г. 16:06:22:

Morcanoнепонятен момент с размером базы, меняет ли она после этого свой
размер?нет

зы: и в хидере убери нах "Attributes no reserve"
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930780
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morcanoВечер добрый.
Есть *fdb база (размер ~60гб), конфигурация сервера:
ПО - Win2008R2 + Firebird 2_1 Classic Server
Железо - Intel Xeon 5620 (x2), RAID10, 48GB RAM (В данный момент пока что стоит Standard версия ОС - видно только 32)
Клиентов ~ 150 ч.

что ты ты гонишь про ОС. Насколько мне известно Windows Server 2008 R2 x86 (читай 32 бита) не бывает
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930812
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morcanoВерсия FB на текущий момент - 2.1.1.1.17910 (x64)
обновляй до 2.1.7. я уже привел причину твоей проблемы.
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930815
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисНасколько мне известно Windows Server 2008 R2 x86 (читай 32 бита) не бываетТридцать два - не биты, а гигабайты.
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930819
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morcanoВерсия FB на текущий момент - 2.1.1
А текущая версия Firebird этой ветки на данный момент = 2.1.7.

morcanoПо поводу сборки мусора - каюсь, но ни разу не делал вручную.
Я тебе больше скажу: собрать мусор вручную вообще невозможно.

Но остаётся два вопроса: зачем ты отключил auto sweep и зачем ты выставил no reserve.

morcanoДанные результаты наводят на мысль, что наверное я все таки уперся в
оперативку...
Лично меня это наводит на мысль, что ты от балды накрутил параметры сервера, чем и привёл
его в состояние ступора.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930834
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morcano
По поводу сборки мусора - каюсь, но ни разу не делал вручную. Сейчас на копии попробую. По поводу улучшения производительности после этой операции понятно, непонятен момент с размером базы, меняет ли она после этого свой размер?
Ключ -g убери. Это раз. Почитай за sweep и для чего он нужен, это два. Выполни рекомендацию kdv, это три.
1 и 2 позволят тебе не парится долгое время по производительности. 3 - избавят от проблем с памятью.
И да,после уборки мусора/sweep база Fb не уменьшается, это тебе не MS SQL. Тормозящую базу проверь для начала IBAnalyst, авторства kdv + почитай справку от бесплатной версии,многое станет ясным.
...
Рейтинг: 0 / 0
Firebird (gbak restore) и ОЗУ
    #38930868
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисGallemar,

в FB сейчас море встроенных функций. Если ты знаешь что делает каждая из этих UDF, то можешь подумать как их заменить на встроенные функции. 200 UDF это конечно мощно. Конечно есть ещё вещи которые без UDF сделать проблематично, но скорее всего после прочёсывания кода их не должно остаться более 20. А эти 20 при большом желании зная что они делают можно и самому переписать.

P.S. Когда я обновлял базу с FB 1.5 до FB2.5 мне пришлось месяца три UDFки выпиливать и заменять их на встроенные функции. Но это того стоит.
Денис,я с тобой полностью согласен. Но есть весомые причины мне не "причесывать" код, одна из самых весомых - я не разработчик данной софтины. Разбираться какие функции что выполняют - огромный труд, хотя и интересный. Ковыряться самому и править я не могу - даже если я что то в БД заменю с UDF на функции FB не факт что оно не улетит в топку при следующем апдейте софта,мы (я и мои девчата) итак уже имеем ежеквартальное развлечение с проверкой и правкой моих дописок после апдейта. Давить на разработчика я не могу,лично знаком с ведущим прогером, у него просто физически нет времени на перенос UDF на Lin.
...
Рейтинг: 0 / 0
25 сообщений из 37, страница 1 из 2
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Firebird (gbak restore) и ОЗУ
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]