Неймовірно довге відновлення резервної копії

Обговорення питань, пов'язаних з функціонуванням програми
Destroid
Повідомлень: 250
З нами з: 17 червня 2014, 09:55

Re: Неймовірно довге відновлення резервної копії

Повідомлення Destroid » 18 серпня 2016, 11:48

Да, пожалуйста, поделитесь опытом

poltava_energy
Повідомлень: 717
З нами з: 13 червня 2012, 09:38

Re: Неймовірно довге відновлення резервної копії

Повідомлення poltava_energy » 23 червня 2017, 07:48

Я просто залишу це тут :D
Схоже що медок пробив нове дніще у своїй повільнодії :shock:

Мізансцена:
Резервна копія філіалу (розмір ZBK 271 768 425 байт) відновлюється до основної бази (розмір якої ~15G) із заміною данних.

Результат:
Час відновлення - більше 9 годин!
Записано до БД ~ 8 Гігабайт що у 32 рази більше розміру даних у ZBK
Прочитано з БД ~ 4 Терабайти :shock: :twisted: що у 15 ТИСЯЧ РАЗІВ більше розміру даних у ZBK :roll:
medoc_restore02.png
medoc_restore02.png (3.45 Кіб) Переглянуто 10591 раз
Востаннє редагувалось 23 червня 2017, 10:59 користувачем poltava_energy, всього редагувалось 1 раз.

priup
Повідомлень: 7713
З нами з: 22 червня 2011, 12:23

Re: Неймовірно довге відновлення резервної копії

Повідомлення priup » 23 червня 2017, 09:48

poltava_energy писав:Я просто залишу це тут .............
Это ЗАЧЕМ? Стресс снять??
ЕСЛИ ХОТИТЕ ЧЕМ-ТО ПОМОЧЬ, то пишем ЗДЕСЬ: http://www.me-doc.com.ua/pages/mailer.php
И для надёжности отсылаем на офбланке разработчику претензию в бумажном виде, заказным письмом с уведомлением...........

А ТАК ВЫ ТОЛЬКО ВОЗДУХ ПОСОТРЯСАЛИ, А ТОЛКУ- "0" :!:

ferret
Повідомлень: 1026
З нами з: 13 липня 2012, 15:20
Звідки: Острова Зеленого Мыса

Re: Неймовірно довге відновлення резервної копії

Повідомлення ferret » 23 червня 2017, 10:03

poltava_energy писав:Я просто залишу це тут :D
Схоже що медок пробив нове дніще у своїй повільнодії :shock:
я таки вам скажу что это вполне нормальное время
На этом месте должна была быть какая-то подпись

poltava_energy
Повідомлень: 717
З нами з: 13 червня 2012, 09:38

Re: Неймовірно довге відновлення резервної копії

Повідомлення poltava_energy » 23 червня 2017, 10:45

ferret писав:я таки вам скажу что это вполне нормальное время
A u serious? :roll:

ferret
Повідомлень: 1026
З нами з: 13 липня 2012, 15:20
Звідки: Острова Зеленого Мыса

Re: Неймовірно довге відновлення резервної копії

Повідомлення ferret » 23 червня 2017, 10:52

poltava_energy писав:
ferret писав:я таки вам скажу что это вполне нормальное время
A u serious? :roll:
natürlich!
50 гиговая база восстанавливалась около 2 суток
На этом месте должна была быть какая-то подпись

poltava_energy
Повідомлень: 717
З нами з: 13 червня 2012, 09:38

Re: Неймовірно довге відновлення резервної копії

Повідомлення poltava_energy » 23 червня 2017, 10:58

ferret писав:
poltava_energy писав:A u serious? :roll:
natürlich!
50 гиговая база восстанавливалась около 2 суток
Іще раз повторю:
Резервна копія філіалу ... відновлюється до основної бази
Тобто тільки один філіал (за нашими масштабами невеликий) відновлюється більше 9 годин.
Скільки відновлюватиметься уся база мені навіть уявити страшно, враховуючи те що філіалів у нас більше двох десятків :(

ferret
Повідомлень: 1026
З нами з: 13 липня 2012, 15:20
Звідки: Острова Зеленого Мыса

Re: Неймовірно довге відновлення резервної копії

Повідомлення ferret » 23 червня 2017, 11:02

poltava_energy писав:
ferret писав:
poltava_energy писав:A u serious? :roll:
natürlich!
50 гиговая база восстанавливалась около 2 суток
Іще раз повторю:
Резервна копія філіалу ... відновлюється до основної бази
Тобто тільки один філіал (за нашими масштабами невеликий) відновлюється більше 9 годин.
Скільки відновлюватиметься уся база мені навіть уявити страшно, враховуючи те що філіалів у нас більше двох десятків :(
Еще учтите, что в ZBK нет базы пользователей с правами и доступами. Просю ненавязчиво сделать выгрузку отдельным файлом хотя бы, но тщетно...
На этом месте должна была быть какая-то подпись

MagicMan
Повідомлень: 14
З нами з: 18 червня 2017, 18:55

Re: Неймовірно довге відновлення резервної копії

Повідомлення MagicMan » 23 червня 2017, 23:35

ferret писав: natürlich!
50 гиговая база восстанавливалась около 2 суток
А что если я скажу Вам, что .zbk размером 1.2 GB восстанавливалась до базы размером в 4.02 GB на протяжении.... (барабанная дробь)... 14 ДНЕЙ ?
На SSD-диске!
Ни база, ни копия не битые.

priup
Повідомлень: 7713
З нами з: 22 червня 2011, 12:23

Re: Неймовірно довге відновлення резервної копії

Повідомлення priup » 26 червня 2017, 10:11

MagicMan писав:... что .zbk размером 1.2 GB восстанавливалась до базы размером в 4.02 GB на протяжении...14 ДНЕЙ ?
На SSD-диске!
Ни база, ни копия не битые.
Пишем сюда:
http://www.me-doc.com.ua/pages/mailer.php
И оформляем письменную претензию разработчику на офбланке предприятия ЗАКАЗНЫМ С УВЕДОМЛЕНИЕМ письмом. Скан этого письма отсылаем в тот же день своему дилеру по МЕДКУ!
Делать что то надо.............., а не воздух сотрясать!!! :mrgreen:

MagicMan
Повідомлень: 14
З нами з: 18 червня 2017, 18:55

Re: Неймовірно довге відновлення резервної копії

Повідомлення MagicMan » 26 червня 2017, 12:28

priup писав:Пишем сюда:
http://www.me-doc.com.ua/pages/mailer.php
И оформляем письменную претензию разработчику на офбланке предприятия ЗАКАЗНЫМ С УВЕДОМЛЕНИЕМ письмом. Скан этого письма отсылаем в тот же день своему дилеру по МЕДКУ!
Делать что то надо.............., а не воздух сотрясать!!! :mrgreen:
Да нет, про это я знаю. По этому вопросу я разъяснения получил.
А Вы разработчик?

BlackOwl
Повідомлень: 429
З нами з: 02 липня 2016, 12:47

Re: Неймовірно довге відновлення резервної копії

Повідомлення BlackOwl » 26 червня 2017, 12:54

MagicMan писав:
priup писав:Пишем сюда:
http://www.me-doc.com.ua/pages/mailer.php
И оформляем письменную претензию разработчику на офбланке предприятия ЗАКАЗНЫМ С УВЕДОМЛЕНИЕМ письмом. Скан этого письма отсылаем в тот же день своему дилеру по МЕДКУ!
Делать что то надо.............., а не воздух сотрясать!!! :mrgreen:
Да нет, про это я знаю. По этому вопросу я разъяснения получил.
А Вы разработчик?
Ну сколько ж тут уже писали, здеся разработчикоф нед! :oops:

priup
Повідомлень: 7713
З нами з: 22 червня 2011, 12:23

Re: Неймовірно довге відновлення резервної копії

Повідомлення priup » 26 червня 2017, 15:27

BlackOwl писав:...Ну сколько ж тут уже писали, здеся разработчикоф нед! :oops:
+120%

priup
Повідомлень: 7713
З нами з: 22 червня 2011, 12:23

Re: Неймовірно довге відновлення резервної копії

Повідомлення priup » 26 червня 2017, 15:30

MagicMan писав:
priup писав:Пишем сюда:
http://www.me-doc.com.ua/pages/mailer.php
И оформляем письменную претензию разработчику на офбланке предприятия ЗАКАЗНЫМ С УВЕДОМЛЕНИЕМ письмом. Скан этого письма отсылаем в тот же день своему дилеру по МЕДКУ!
Делать что то надо.............., а не воздух сотрясать!!! :mrgreen:
Да нет, про это я знаю. По этому вопросу я разъяснения получил.
А Вы разработчик?
А громада форума интересуется!!! Что сделал разработчик в ВАШЕМ случае, в своё оправдание.............. :mrgreen:

MagicMan
Повідомлень: 14
З нами з: 18 червня 2017, 18:55

Re: Неймовірно довге відновлення резервної копії

Повідомлення MagicMan » 26 червня 2017, 19:47

BlackOwl,
спасибо, я понял.

priup,
тоже самое, что и в Ваших случаях - "по Вашему вопросу создан волшебный запрос".

poltava_energy
Повідомлень: 717
З нами з: 13 червня 2012, 09:38

Re: Неймовірно довге відновлення резервної копії

Повідомлення poltava_energy » 15 липня 2019, 14:00

І знову повертаємося до цієї проблеми.
Знадобилося відновити із резервної копії один із наших філіалів, не самий маленький, не самий великий, так середній.

Так як деякі із представників медка постійно мені дорікали тим, що їхня програма вкрай тормознута, і тому її обовязково експлуатувати виключно на SSD. То, для чистоти експерименту, відновлення із ZBK відбувалося на домашньому компі i7-2600K/16G DDR3 із встановленим SSD Samsung 850 Pro 512GB на котрому виключно для медка було виділено окремий розділ у розмірі 100 гігабайт.

Резервна копія філіалу 2,5 гіга (розмір ZBK 2 624 843 115 байт) .
Відновлення відбувалося до свіжевстановленої копії медка із пустою базою.

Результат!
Час відновлення - із ранку шабату до сьогоднішнього обіду, приблизно 55 годин!
Записано до БД ~ 135 Гігабайт (145 547 636 736 байт) що у 55 раз більше розміру даних у ZBK
Прочитано з БД ~ 35 Терабайти (38 400 929 228 217 байт) :shock: :twisted: що у 15 ТИСЯЧ РАЗІВ більше розміру даних у ZBK :roll:
medoc_fkng_error_924.png
medoc_fkng_error_924.png (5.34 Кіб) Переглянуто 3011 разів
При цьому просессор був задіяний не більше ніж на 20%

І хоча кратність прочитанного залишилася на рівні минулого виміру - 15 ТИСЯЧ РАЗІВ.
То кратність записаного збільшилася на 72%, із 32 до 55.

Елементарний розрахунок показує, що середня швидкість відновлення із ZBK на SSD близько 45 мегабайт на годину.
Іще раз - 45 мегабайт НЕ НА секунду, на годину!
При швидкості SSD ~ 400 мегабайт НА секунду.

Висновок!
Навіть коли у вас буде швидкодіючий просессор та швидкодіючий диск, то швидко відновити базу з резервної копії вам всерівно не вдасться.

Белокопытов Геннадий
Универсал (склонность - системные вопросы)
Повідомлень: 10116
З нами з: 13 січня 2012, 11:21

Re: Неймовірно довге відновлення резервної копії

Повідомлення Белокопытов Геннадий » 15 липня 2019, 14:06

poltava_energy
Жодного разу на SSD з такою швидкістю відновлення даних не доводилося зіштовхуватися.
Саме для випадків з таким об’ємом, реалізовано новий формат резервних копій ZBF.
Відносно прочитаних та записаних даних, зверніть увагу на те, що операційна система виконує такі операції через TEMP каталог, а тільки потім до кінцевого каталогу.

hatmaster
Повідомлень: 595
З нами з: 21 вересня 2016, 12:52

Re: Неймовірно довге відновлення резервної копії

Повідомлення hatmaster » 15 липня 2019, 17:54

poltava_energy писав:
15 липня 2019, 14:00

Висновок!
Навіть коли у вас буде швидкодіючий просессор та швидкодіючий диск, то швидко відновити базу з резервної копії вам всерівно не вдасться.
У вас в експерименті задіяний мережевий Медок, тобто експеримент нічого нового не показав.

В мене складається враження, що створення/відновлення резкопії в мережевому Медку запускається з найнижчим приорітетом і при цьому задіяне лише одне ядро процесора. Тобто ця процедура розрахована на фоновий режим
Все пройдет, и это тоже. Реально лишь одно - мир иллюзорен! Все остальное фантастика ...

Голодный Пельмень
Повідомлень: 281
З нами з: 15 травня 2018, 13:05

Re: Неймовірно довге відновлення резервної копії

Повідомлення Голодный Пельмень » 16 липня 2019, 09:09

poltava_energy писав:
15 липня 2019, 14:00
Записано до БД ~ 135 Гігабайт (145 547 636 736 байт) що у 55 раз більше розміру даних у ZBK
Прочитано з БД ~ 35 Терабайти (38 400 929 228 217 байт) :shock: :twisted: що у 15 ТИСЯЧ РАЗІВ більше розміру даних у ZBK :roll:

Ничоси. :shock: :shock:

poltava_energy
Повідомлень: 717
З нами з: 13 червня 2012, 09:38

Re: Неймовірно довге відновлення резервної копії

Повідомлення poltava_energy » 16 липня 2019, 10:33

Белокопытов Геннадий писав:
15 липня 2019, 14:06
Саме для випадків з таким об’ємом, реалізовано новий формат резервних копій ZBF.
Наскільки я встиг помітити, формат збереження через ZBF не працює у випадку незначних помилок у БД. От і у даному випадку не спрацював.
Белокопытов Геннадий писав:
15 липня 2019, 14:06
Відносно прочитаних та записаних даних, зверніть увагу на те, що операційна система виконує такі операції через TEMP каталог, а тільки потім до кінцевого каталогу.
До чого тут папка TEMP, якщо мова йде лише про кількість прочитаного/записаного просессом Firebird Server який безпосередньо відновлював цю БД ?
hatmaster писав:
15 липня 2019, 17:54
У вас в експерименті задіяний мережевий Медок, тобто експеримент нічого нового не показав.

В мене складається враження, що створення/відновлення резкопії в мережевому Медку запускається з найнижчим приорітетом і при цьому задіяне лише одне ядро процесора. Тобто ця процедура розрахована на фоновий режим
Із резервної копії у ZBK відновлюється БД на SSD із швидкістю 45 мегабайт на годину!
45 мегабайт на годину ~ 770 кілобайт на хвилину ~ 13 кілобайт на секунду !!!
Задумайтеся над цими числами.
Востаннє редагувалось 16 липня 2019, 10:38 користувачем poltava_energy, всього редагувалось 2 разів.

Відповісти

Повернутись до “Помилки у роботі програми”