Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Вечер добрый. Есть *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 свободно) - ближе к концу процедуры восстановления память была забита под завязку.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2015, 22:45 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
morcanoДелаю как обычно так: -rep -c ну откуда ты, прости господи, взял этот бред в опциях? http://www.ibase.ru/devinfo/gbak.htm morcanoPage buffers 3000 зачем размер кэша прописан в файле БД? Какая точная версия Firebird? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 00:17 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
morcanoПри restore мониторил ресурсы - дисковая подсистема почти не участвует, но довольно много ест ОЗУ. Добавь к ключам при восстановлении -O. И забудь про "ускорение через бэкап-рестор", ищи более правильные пути, читай ibase.ru. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 00:44 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 04:14 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
4. b/r как часто делаешь? И по какой причине - потеря производительности или по расписанию? Вопрос 3 можешь не отвечать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 04:30 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 05:56 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
morcanoStandard версия ОС - видно только 32По какой причине стоит недоОСь, которая не использует все ресурсы? Причем ресурс САМЫЙ критический с точки зрения приозводительности. Поставь полноценный линукс и пользуйся всей памятью. morcanoПо завершении, тот прирост производительности который был раньше ощутим (после прогона "бекап-рестор") перестал быть виден.Наличие прироста после б/р может говорить только о кривости прикладной софтины и никаго администрирования в части чиски мусора. Мы делаем бэкап-рестор практически только при смене версий ФБ. нагрузка-железо сопоставимое, плюс-минус лапоть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 08:23 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Ivan_PisarevskyПоставь полноценный линукс и пользуйся всей памятью. Если есть UDF для линукс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 12:01 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Hello, Gallemar! You wrote on 8 апреля 2015 г. 12:37:59: Gallemar> Если есть UDF для линукс.udf - зло. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 12:37 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Gallemar, а в чём сложности. С++ легко переносится между различными платформами. Не нравится C++ пиши на Lazarus. P.S. Насчёт зла согласен с МП ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 12:43 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
автор исчез, а я еще раз пересмотрел исходное сообщение, и теперь теоретизирую более конкретно: 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. (я именно поэтому и спрашивал про точную версию ФБ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 14:16 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
kdvнужно найти, что поменялось в этом интервале. Потому что "почти сутки" и 7 часов - это разница в 3 раза. Например, данные для индексов перестали помещаться в память и сортировка уходит на диск. Отсюда же и "backup/restore для ускорения перестал помогать". Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 14:29 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисGallemar, а в чём сложности. С++ легко переносится между различными платформами. Не нравится C++ пиши на Lazarus. P.S. Насчёт зла согласен с МП В обслуживаемой софтине в БД 200 с лишним UDF на паскале, исходного кода у меня нет, уже год долбаю разработчика чтобы переписал для Linux. Так что не для всех миграция Win-> Lin проста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 14:56 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Gallemar, в FB сейчас море встроенных функций. Если ты знаешь что делает каждая из этих UDF, то можешь подумать как их заменить на встроенные функции. 200 UDF это конечно мощно. Конечно есть ещё вещи которые без UDF сделать проблематично, но скорее всего после прочёсывания кода их не должно остаться более 20. А эти 20 при большом желании зная что они делают можно и самому переписать. P.S. Когда я обновлял базу с FB 1.5 до FB2.5 мне пришлось месяца три UDFки выпиливать и заменять их на встроенные функции. Но это того стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 15:28 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Hello, Gallemar! You wrote on 8 апреля 2015 г. 15:58:47: Gallemar> в БД 200 с лишним UDF на паскале мочить казлов! (с) Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 15:58 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Hello, Симонов Денис! You wrote on 8 апреля 2015 г. 15:59:44: Симонов Денис> UDFки выпиливать и заменять их на встроенные функции. Но это того стоит. +1 Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 15:59 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Версия FB на текущий момент - 2.1.1.1.17910 (x64) Делал только что restore с ключом -о (про "-c" + "-rep" почитал - исправился)) на своей рабочей машине (8gb ОЗУ), в диспетчере загруженность памяти была ~50% после чего рестор мне выдал: авторERROR: unable to allocate memory from operating system Хотя раньше (пару месяцев назад, когда база была "худее" гигов на 10) - на рабочей машине спокойно ресторил бекапы... Вчера так же тестил на другом сервере в котором стоит 64гб ОЗУ (10 было загружено) - заняло ~ 8 часов. Данные результаты наводят на мысль, что наверное я все таки уперся в оперативку... По поводу сборки мусора - каюсь, но ни разу не делал вручную. Сейчас на копии попробую. По поводу улучшения производительности после этой операции понятно, непонятен момент с размером базы, меняет ли она после этого свой размер? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 16:01 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
morcanoПо поводу улучшения производительности после этой операции понятно, непонятен момент с размером базы, меняет ли она после этого свой размер? А зачем? Освобождённое пространство может использоваться повторно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 16:06 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Hello, Morcano! You wrote on 8 апреля 2015 г. 16:06:22: Morcanoнепонятен момент с размером базы, меняет ли она после этого свой размер?нет зы: и в хидере убери нах "Attributes no reserve" Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 16:07 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
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 бита) не бывает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 16:23 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
morcanoВерсия FB на текущий момент - 2.1.1.1.17910 (x64) обновляй до 2.1.7. я уже привел причину твоей проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 16:42 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисНасколько мне известно Windows Server 2008 R2 x86 (читай 32 бита) не бываетТридцать два - не биты, а гигабайты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 16:42 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
morcanoВерсия FB на текущий момент - 2.1.1 А текущая версия Firebird этой ветки на данный момент = 2.1.7. morcanoПо поводу сборки мусора - каюсь, но ни разу не делал вручную. Я тебе больше скажу: собрать мусор вручную вообще невозможно. Но остаётся два вопроса: зачем ты отключил auto sweep и зачем ты выставил no reserve. morcanoДанные результаты наводят на мысль, что наверное я все таки уперся в оперативку... Лично меня это наводит на мысль, что ты от балды накрутил параметры сервера, чем и привёл его в состояние ступора. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 16:45 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
morcano По поводу сборки мусора - каюсь, но ни разу не делал вручную. Сейчас на копии попробую. По поводу улучшения производительности после этой операции понятно, непонятен момент с размером базы, меняет ли она после этого свой размер? Ключ -g убери. Это раз. Почитай за sweep и для чего он нужен, это два. Выполни рекомендацию kdv, это три. 1 и 2 позволят тебе не парится долгое время по производительности. 3 - избавят от проблем с памятью. И да,после уборки мусора/sweep база Fb не уменьшается, это тебе не MS SQL. Тормозящую базу проверь для начала IBAnalyst, авторства kdv + почитай справку от бесплатной версии,многое станет ясным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 16:52 |
|
||
|
Firebird (gbak restore) и ОЗУ
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисGallemar, в FB сейчас море встроенных функций. Если ты знаешь что делает каждая из этих UDF, то можешь подумать как их заменить на встроенные функции. 200 UDF это конечно мощно. Конечно есть ещё вещи которые без UDF сделать проблематично, но скорее всего после прочёсывания кода их не должно остаться более 20. А эти 20 при большом желании зная что они делают можно и самому переписать. P.S. Когда я обновлял базу с FB 1.5 до FB2.5 мне пришлось месяца три UDFки выпиливать и заменять их на встроенные функции. Но это того стоит. Денис,я с тобой полностью согласен. Но есть весомые причины мне не "причесывать" код, одна из самых весомых - я не разработчик данной софтины. Разбираться какие функции что выполняют - огромный труд, хотя и интересный. Ковыряться самому и править я не могу - даже если я что то в БД заменю с UDF на функции FB не факт что оно не улетит в топку при следующем апдейте софта,мы (я и мои девчата) итак уже имеем ежеквартальное развлечение с проверкой и правкой моих дописок после апдейта. Давить на разработчика я не могу,лично знаком с ведущим прогером, у него просто физически нет времени на перенос UDF на Lin. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2015, 17:04 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38930548&tid=1562930]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
175ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 281ms |

| 0 / 0 |
