Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Имеется: сервер с Windows 7 x64 и Firebird 2.5.3 База данных формируется ежемесячно. Объем около 40 ГБ. Есть тенденция на ее увеличение. Таблиц всего 39, одна таблица является основной и содержит 150 - 200 млн. записей. Соответственно это количество тоже может увеличиваться. Изначально Firebird был x86, потом пришлось перейти на x64 Суть проблемы. Когда БД была около 10 ГБ бэкап и восстановление происходили без проблем. При достижении 30 ГБ столкнулся с нехваткой оперативной памяти при восстановлении бэкапа. Беглое изучение проблемы показало, что нехватка памяти возникает именно в процессе восстановления большой таблицы (одна большая транзакция?) и предел памяти в 2 гига на процесс просто напросто выбирался. Пришлось перейти на x64. Мониторинг ресурсов сервера указывает, что высвобождение памяти (коммит?) происходит после восстановления большой таблицы. В документации про эту особенность рестора ничего не нашел. Также не нашел упоминаний об этом среди результатов поиска. Это баг или фича? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 07:06 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Есть небольшое дополнение. В текущий момент восстанавливается БД размером 44 ГБ Восстановлено около 170 млн. записей Процесс сервера Firebird занимает в памяти 3,8 ГБ ЗЫ. Проверил момент высвобождения ресурсов. Ресурсы высвобождаются в момент завершения всей процедуры восстановления, а не после восстановления отдельной таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 09:59 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory K,хм,а можно глупый вопрос - память кто скушивает, fb? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 10:37 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
1. DDL таблицы покажите. 2. Попробуйте опцию рестора -one_at_a_time ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 10:40 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
GallemarGregory K,хм,а можно глупый вопрос - память кто скушивает, fb? Ага, он ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 10:58 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
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. Индексы есть, но строятся они вручную после восстановления. Первичный ключ по полю ID раньше был, но я потом от него отказался. Есть триггер на вставку записи для генерации ID Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 11:14 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
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_ использую в связи с тем, что внесение изменений в БД после бэкап/рестора не планируются и хочу максимально компактного размещения БД на диске ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 11:24 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory Kсервер с Windows 7 x64 и Firebird 2.5.3 Какие параметры конфига менял? Gregory KПроцесс сервера Firebird занимает в памяти 3,8 ГБ Чем смотрел и какую именно память? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 12:05 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory Khvlad1. DDL таблицы покажите. Боюсь, что в структуре этой самой большой таблицы ничего примечательного. Ну почему же - ничего примечательного. Есть блоб и это наводит на мысли... Если есть возможность отресторить такую таблицу без этого поля, или с нуллами в нём - было бы весьма интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 12:10 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
hvlad1. DDL таблицы покажите. 2. Попробуйте опцию рестора -one_at_a_time Так если у него одна большая таблица, то разве это повлияет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 12:19 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovКакие параметры конфига менял? Конфиг не менял Dimitry SibiryakovЧем смотрел и какую именно память? Простой Task manager Колонка Memory (Private working set) Соответственно кривая Physical Memory Usage History на вкладке Perfomance ведет себя соответственно (т.е. ползет вверх). Также в период использования fb x86 непосредственно своими глазами наблюдал как память у процесса fb достигает предела в 2 гига после чего процесс падал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 12:37 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
hvladНу почему же - ничего примечательного. Есть блоб и это наводит на мысли... Если есть возможность отресторить такую таблицу без этого поля, или с нуллами в нём - было бы весьма интересно. В блобе данных сравнительно не много. Можно собрать статистику Он используется потому, что длина строки, которая хранится в этом поле ну совсем не поддается никакому прогнозу Для эксперимента могу попробовать бэкапнуть и отресторить без нее Кусок лога рестора наводит на мысль, что это все же из-за одной большой транзакции. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 12:43 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory KВ блобе данных сравнительно не много.Это не важно. Все блобы, созданные в тр-ции, учитываются до её окончания. Для этого в памяти создаётся небольшая структура - BlobIndex. Её размер 24 байта. Посчитаем, сколько памяти займут 170млн таких структур ? А ведь их тоже нужно где-то хранить, и это минимум 8 байт (указатель) на каждую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 12:58 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
NikolayV81hvlad1. DDL таблицы покажите. 2. Попробуйте опцию рестора -one_at_a_time Так если у него одна большая таблица, то разве это повлияет?На общее потребление памяти - не сильно. На момент освобождения памяти - должно быть весьма заметно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 12:59 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
hvladЭто не важно. Все блобы, созданные в тр-ции, учитываются до её окончания. Для этого в памяти создаётся небольшая структура - BlobIndex. Её размер 24 байта. Посчитаем, сколько памяти займут 170млн таких структур ? А ведь их тоже нужно где-то хранить, и это минимум 8 байт (указатель) на каждую. Хм. Для меня это новость. Спасибо. Покопаю в этом направлении А для других типов в пределах транзакции до ее окончания память не выделяется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 13:04 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 13:42 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
[quot Gregory K]hvlad Код: plaintext 1. Вы бы мил человек на таких объемах не скоромились. Ставьте уже 16к на страничку, не мучайте птичку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 13:54 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
kdvпараметры от балды пишем? http://www.ibase.ru/devinfo/gbak.htm А что не так? Нельзя перезаписывать БД или нельзя использовать полное заполнение страниц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 13:57 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
pastorВы бы мил человек на таких объемах не скоромились. Ставьте уже 16к на страничку, не мучайте птичку. Сарказм? Помнится не очень давно (в рамках другого проекта) у меня были безуспешные попытки указать страницу меньшего размера. При ресторе в любом случае меньше 4096 получить не удавалось несмотря на явное на то указание. Это, видимо, тоже фича. Ну или кривые ручки. Что вернее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 14:03 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory K,меньше с больше путаешь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 14:06 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
GallemarGregory K,меньше с больше путаешь Я просто указал, что не смог изменить страницу в меньшую сторону. И спасибо за совет. Обязательно попробую увеличить страницу. Однако полагаю, что к описанной выше проблеме это не имеет отношение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 14:09 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory KА что не так? Нельзя перезаписывать БД или нельзя использовать полное заполнение страниц? У тебя база read-only? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 14:23 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory KОднако полагаю, что к описанной выше проблеме это не имеет отношение не имеет отношения, да, но зато будет быстрее. Gregory KА что не так? Нельзя перезаписывать БД ты бы вместо того, чтобы задавать вопрос, прочитал документ. -c -rep это совершенно идиотское сочетание взаимоисключающих опций. Откуда ты это взял - неизвестно. Пишется либо только -c, либо только -rep (или -r o). И, да, в любом случае опцию -rep никогда не рекомендуется использовать, потому что ты можешь остаться без БД. Бывшую опцию -r не зря в -rep переименовали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 15:18 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory KGallemarGregory K,меньше с больше путаешь Я просто указал, что не смог изменить страницу в меньшую сторону. И спасибо за совет. Обязательно попробую увеличить страницу. Однако полагаю, что к описанной выше проблеме это не имеет отношение будет. если запись больше 4к, или глубина индексов более 4х. опять же, легко проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 15:57 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
kdvты бы вместо того, чтобы задавать вопрос, прочитал документ. -c -rep это совершенно идиотское сочетание взаимоисключающих опций. Откуда ты это взял - неизвестно. Пишется либо только -c, либо только -rep (или -r o). И, да, в любом случае опцию -rep никогда не рекомендуется использовать, потому что ты можешь остаться без БД. Бывшую опцию -r не зря в -rep переименовали. Давайте все же на Вы. Если не трудно. Я понимаю, что нас, идиотов тут немеренно, но капелька уважения никогда не повредит. Теперь по существу. Во-первых в руководстве явно указано про неоднозначность сочетания -c -r, а вот про -с -rep я не увидел. Упоминается лишь про то, что -rep пришло на смену -r. Я считал, что -c я восстановлю базу, а -rep - это ответ на вопрос что делать, если база уже существует. Во-вторых если это сочетание недопустимо (а оно, судя по всему, допустимо, но режет глаз), почему бы об этом сразу в консоли не сказать? Ну типа "ты, уважаемый, определись, что ты хочешь - просто восстановить или перезаписать" и что одновременно это указывать нельзя. Раз гбаку понятно, что я хочу и я получаю нужный мне результат, то по-моему все в порядке. В-третьих непонятно с чего вы решили, что я ресторю в боевую базу? Я намерено не стал грузить окружающих полной логикой работы всей системы. На самом деле, если интересно, оперативная запись данных идет в текущую месячную базу. Но поскольку индексов в ней нет, я по ночам делаю бэкап и последующий рестор в другую базу, назовем ее operate.gdb. Она всегда так называется и поэтому ее надо всегда перезаписывать без вопросов. По ней же и строю индексы и утром получаю состояние на вчерашний день со всеми индексами и прочими плюхами. Ну и спасибо за советы. Послезавтра буду пробовать. Отпишусь. ЗЫ. -c обязуюсь убрать :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 16:26 |
|
||
|
|

start [/forum/topic.php?fid=40&startmsg=38848862&tid=1563101]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
183ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 277ms |
| total: | 557ms |

| 0 / 0 |
