powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Использование памяти при восстановлении больших таблиц gbak
25 сообщений из 58, страница 1 из 3
Использование памяти при восстановлении больших таблиц gbak
    #38848862
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Имеется:
сервер с Windows 7 x64 и Firebird 2.5.3
База данных формируется ежемесячно. Объем около 40 ГБ. Есть тенденция на ее увеличение.
Таблиц всего 39, одна таблица является основной и содержит 150 - 200 млн. записей. Соответственно это количество тоже может увеличиваться.
Изначально Firebird был x86, потом пришлось перейти на x64

Суть проблемы.
Когда БД была около 10 ГБ бэкап и восстановление происходили без проблем.
При достижении 30 ГБ столкнулся с нехваткой оперативной памяти при восстановлении бэкапа.
Беглое изучение проблемы показало, что нехватка памяти возникает именно в процессе восстановления большой таблицы (одна большая транзакция?) и предел памяти в 2 гига на процесс просто напросто выбирался. Пришлось перейти на x64. Мониторинг ресурсов сервера указывает, что высвобождение памяти (коммит?) происходит после восстановления большой таблицы.

В документации про эту особенность рестора ничего не нашел. Также не нашел упоминаний об этом среди результатов поиска.

Это баг или фича?
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38848904
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть небольшое дополнение.

В текущий момент восстанавливается БД размером 44 ГБ
Восстановлено около 170 млн. записей
Процесс сервера Firebird занимает в памяти 3,8 ГБ

ЗЫ. Проверил момент высвобождения ресурсов. Ресурсы высвобождаются в момент завершения всей процедуры восстановления, а не после восстановления отдельной таблицы.
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38848934
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gregory K,хм,а можно глупый вопрос - память кто скушивает, fb?
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38848937
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. DDL таблицы покажите.
2. Попробуйте опцию рестора -one_at_a_time
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38848951
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
GallemarGregory K,хм,а можно глупый вопрос - память кто скушивает, fb?
Ага, он
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38848960
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hvlad1. DDL таблицы покажите.

Боюсь, что в структуре этой самой большой таблицы ничего примечательного. Реальные названия полей заменены (полагаю, что это не важно). В основном это отсылки на ID связанных мелких табличек.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
CREATE TABLE TABLE1 (
    ID             INTEGER NOT NULL,
    ADATE          DATE,
    ATIME          TIME,
    FIELD1       SMALLINT,
    FIELD2          INTEGER,
    FIELD3      SMALLINT,
    FIELD4    SMALLINT,
    FIELD5        SMALLINT,
    FIELD6           SMALLINT,
    FIELD7     SMALLINT,
    FIELD8       SMALLINT,
    FIELD9       SMALLINT,
    FIELD10      BIGINT,
    FIELD11          VARCHAR(15),
    FIELD12        INTEGER,
    FIELD13      SMALLINT,
    FIELD14          VARCHAR(15),
    FIELD15        INTEGER,
    FIELD16      SMALLINT,
    FIELD17      INTEGER,
    FIELD18     INTEGER,
    FIELD19  SMALLINT,
    FIELD20      SMALLINT,
    FIELD21       SMALLINT,
    FIELD22      SMALLINT,
    FIELD23            BLOB SUB_TYPE 1 SEGMENT SIZE 16,
    FIELD24       BIGINT,
    FIELD25       BIGINT,
    FIELD26          INTEGER,
    FIELD27       SMALLINT,
    FIELD28          SMALLINT,
    FIELD29            SMALLINT,
    FIELD30      SMALLINT,
    FIELD31         INTEGER,
    FIELD32       SMALLINT,
    FIELD33       SMALLINT,
    FIELD34          INTEGER,
    FIELD35          SMALLINT,
    FIELD36      SMALLINT,
    FIELD37         INTEGER,
    FIELD38     SMALLINT,
    FIELD39        SMALLINT,
    FIELD40      SMALLINT,
    FIELD41       SMALLINT,
    FIELD42          INTEGER,
    FIELD43       SMALLINT,
    FIELD44      SMALLINT
);



Индексы есть, но строятся они вручную после восстановления. Первичный ключ по полю ID раньше был, но я потом от него отказался. Есть триггер на вставку записи для генерации ID

Код: sql
1.
2.
3.
4.
5.
6.
7.
CREATE TRIGGER TABLE1_BI FOR TABLE1
ACTIVE BEFORE INSERT POSITION 0
as
begin
  if (new.id is null) then
    new.id = gen_id(gen_table1_id,1);
end
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38848968
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hvlad2. Попробуйте опцию рестора -one_at_a_time

gbak на восстановление вызываю так:
gbak -c -USE_ -REP -v -se localhost:service_mgr -user sysdba -pas masterkey db.fbk db.fdb -y log.log

Соответственно сейчас пробую так (это займет какое-то время):
gbak -c -one_at_a_time -USE_ -REP -v -se localhost:service_mgr -user sysdba -pas masterkey db.fbk db.fdb -y log.log

Ключ -USE_ использую в связи с тем, что внесение изменений в БД после бэкап/рестора не планируются и хочу максимально компактного размещения БД на диске
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849009
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gregory Kсервер с Windows 7 x64 и Firebird 2.5.3
Какие параметры конфига менял?

Gregory KПроцесс сервера Firebird занимает в памяти 3,8 ГБ
Чем смотрел и какую именно память?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849013
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gregory Khvlad1. DDL таблицы покажите.

Боюсь, что в структуре этой самой большой таблицы ничего примечательного. Ну почему же - ничего примечательного. Есть блоб и это наводит на мысли...
Если есть возможность отресторить такую таблицу без этого поля, или с нуллами в нём - было бы весьма интересно.
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849027
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad1. DDL таблицы покажите.
2. Попробуйте опцию рестора -one_at_a_time
Так если у него одна большая таблица, то разве это повлияет?
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849047
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovКакие параметры конфига менял?


Конфиг не менял

Dimitry SibiryakovЧем смотрел и какую именно память?


Простой Task manager
Колонка Memory (Private working set)
Соответственно кривая Physical Memory Usage History на вкладке Perfomance ведет себя соответственно (т.е. ползет вверх).
Также в период использования fb x86 непосредственно своими глазами наблюдал как память у процесса fb достигает предела в 2 гига после чего процесс падал.
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849054
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hvladНу почему же - ничего примечательного. Есть блоб и это наводит на мысли...
Если есть возможность отресторить такую таблицу без этого поля, или с нуллами в нём - было бы весьма интересно.

В блобе данных сравнительно не много.
Можно собрать статистику
Он используется потому, что длина строки, которая хранится в этом поле ну совсем не поддается никакому прогнозу

Для эксперимента могу попробовать бэкапнуть и отресторить без нее

Кусок лога рестора наводит на мысль, что это все же из-за одной большой транзакции.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
gbak:opened file C:\data\db.fbk
gbak:transportable backup -- data in XDR format
gbak:		backup file is compressed
gbak:created database C:\data\db.fdb, page_size 4096 bytes
gbak: started transaction 
...
gbak:     committing metadata 
gbak:finishing, closing, and going home
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849070
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gregory KВ блобе данных сравнительно не много.Это не важно. Все блобы, созданные в тр-ции, учитываются до её окончания.
Для этого в памяти создаётся небольшая структура - BlobIndex. Её размер 24 байта.
Посчитаем, сколько памяти займут 170млн таких структур ? А ведь их тоже нужно где-то хранить, и это минимум 8 байт (указатель) на каждую.
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849074
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NikolayV81hvlad1. DDL таблицы покажите.
2. Попробуйте опцию рестора -one_at_a_time
Так если у него одна большая таблица, то разве это повлияет?На общее потребление памяти - не сильно.
На момент освобождения памяти - должно быть весьма заметно.
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849083
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hvladЭто не важно. Все блобы, созданные в тр-ции, учитываются до её окончания.
Для этого в памяти создаётся небольшая структура - BlobIndex. Её размер 24 байта.
Посчитаем, сколько памяти займут 170млн таких структур ? А ведь их тоже нужно где-то хранить, и это минимум 8 байт (указатель) на каждую.

Хм. Для меня это новость. Спасибо. Покопаю в этом направлении

А для других типов в пределах транзакции до ее окончания память не выделяется?
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849132
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gregory Kgbak -c -USE_ -REP
параметры от балды пишем?

http://www.ibase.ru/devinfo/gbak.htm
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849144
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot Gregory K]hvlad
Код: plaintext
1.
gbak:created database C:\data\db.fdb, page_size 4096 bytes


Вы бы мил человек на таких объемах не скоромились. Ставьте уже 16к на страничку, не мучайте птичку.
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849148
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdvпараметры от балды пишем?

http://www.ibase.ru/devinfo/gbak.htm

А что не так?
Нельзя перезаписывать БД или нельзя использовать полное заполнение страниц?
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849152
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
pastorВы бы мил человек на таких объемах не скоромились. Ставьте уже 16к на страничку, не мучайте птичку.

Сарказм?

Помнится не очень давно (в рамках другого проекта) у меня были безуспешные попытки указать страницу меньшего размера. При ресторе в любом случае меньше 4096 получить не удавалось несмотря на явное на то указание. Это, видимо, тоже фича.
Ну или кривые ручки. Что вернее.
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849156
Фотография Gallemar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gregory K,меньше с больше путаешь
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849162
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
GallemarGregory K,меньше с больше путаешь

Я просто указал, что не смог изменить страницу в меньшую сторону.

И спасибо за совет. Обязательно попробую увеличить страницу.
Однако полагаю, что к описанной выше проблеме это не имеет отношение
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849177
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gregory KА что не так?
Нельзя перезаписывать БД или нельзя использовать полное заполнение страниц?
У тебя база read-only?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849229
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gregory KОднако полагаю, что к описанной выше проблеме это не имеет отношение
не имеет отношения, да, но зато будет быстрее.

Gregory KА что не так?
Нельзя перезаписывать БД
ты бы вместо того, чтобы задавать вопрос, прочитал документ. -c -rep это совершенно идиотское сочетание взаимоисключающих опций. Откуда ты это взял - неизвестно. Пишется либо только -c, либо только -rep (или -r o).
И, да, в любом случае опцию -rep никогда не рекомендуется использовать, потому что ты можешь остаться без БД. Бывшую опцию -r не зря в -rep переименовали.
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849280
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gregory KGallemarGregory K,меньше с больше путаешь

Я просто указал, что не смог изменить страницу в меньшую сторону.

И спасибо за совет. Обязательно попробую увеличить страницу.
Однако полагаю, что к описанной выше проблеме это не имеет отношение

будет. если запись больше 4к, или глубина индексов более 4х.

опять же, легко проверить.
...
Рейтинг: 0 / 0
Использование памяти при восстановлении больших таблиц gbak
    #38849299
Gregory K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdvты бы вместо того, чтобы задавать вопрос, прочитал документ. -c -rep это совершенно идиотское сочетание взаимоисключающих опций. Откуда ты это взял - неизвестно. Пишется либо только -c, либо только -rep (или -r o).
И, да, в любом случае опцию -rep никогда не рекомендуется использовать, потому что ты можешь остаться без БД. Бывшую опцию -r не зря в -rep переименовали.

Давайте все же на Вы. Если не трудно.
Я понимаю, что нас, идиотов тут немеренно, но капелька уважения никогда не повредит.

Теперь по существу.

Во-первых в руководстве явно указано про неоднозначность сочетания -c -r, а вот про -с -rep я не увидел. Упоминается лишь про то, что -rep пришло на смену -r. Я считал, что -c я восстановлю базу, а -rep - это ответ на вопрос что делать, если база уже существует.

Во-вторых если это сочетание недопустимо (а оно, судя по всему, допустимо, но режет глаз), почему бы об этом сразу в консоли не сказать? Ну типа "ты, уважаемый, определись, что ты хочешь - просто восстановить или перезаписать" и что одновременно это указывать нельзя. Раз гбаку понятно, что я хочу и я получаю нужный мне результат, то по-моему все в порядке.

В-третьих непонятно с чего вы решили, что я ресторю в боевую базу? Я намерено не стал грузить окружающих полной логикой работы всей системы. На самом деле, если интересно, оперативная запись данных идет в текущую месячную базу. Но поскольку индексов в ней нет, я по ночам делаю бэкап и последующий рестор в другую базу, назовем ее operate.gdb. Она всегда так называется и поэтому ее надо всегда перезаписывать без вопросов. По ней же и строю индексы и утром получаю состояние на вчерашний день со всеми индексами и прочими плюхами.

Ну и спасибо за советы. Послезавтра буду пробовать. Отпишусь.
ЗЫ. -c обязуюсь убрать :)
...
Рейтинг: 0 / 0
25 сообщений из 58, страница 1 из 3
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Использование памяти при восстановлении больших таблиц gbak
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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