Дополнительные настройки Firebird

Проблеми зв'язані з роботою сервер-клієнт MEDOC
Відповісти
Ktoia
Повідомлень: 79
З нами з: 23 січня 2015, 14:11

Дополнительные настройки Firebird

Повідомлення Ktoia » 03 листопада 2015, 17:37

Добрый день. Решил протестировать разные параметры настроек FB в ConnectionSetup.
Цель теста: найти оптимальные параметры для настроек медка.
Вводные данные:
Железо - Inter Core i5-3570 (4 ядра) ОЗУ - 8 Гб
ПО: Windows Server 2008R2, Firebird 2.5.4 x64, Medoc 10.01.081,
БД: zvit.fdb 43,5 Гб
Параметры тестирования: открытие реестра первичных документов за пол года (около 250 тыс.) на время (минуты)
Судя по результатам эти настройки практически не на что не влияют (кроме заведомо высоких)
Вкладення
medoc_27.jpg
medoc_27.jpg (52.5 Кіб) Переглянуто 5968 разів

Колпаков Б.И.
Повідомлень: 8802
З нами з: 29 липня 2011, 14:59
Звідки: Украина, Донецкая область, Бахмут
Контактна інформація:

Re: Дополнительные настройки Firebird

Повідомлення Колпаков Б.И. » 03 листопада 2015, 18:17

HDD or SSD ?
Firebird в каком режиме?
А базу переводили на Firebird 2.5.4 ? (Или это не нужно и Я что то путаю?)

С менеджером блокировки вообще тормоза!
Самые неожиданные это первая и последние строчки.

Ktoia
Повідомлень: 79
З нами з: 23 січня 2015, 14:11

Re: Дополнительные настройки Firebird

Повідомлення Ktoia » 03 листопада 2015, 18:43

Ой-да, забыл написать:
Тесты проводились на копии боевой базы. Поэтому HDD в 0-м рейде для быстроты.
На боевом сервере стоит Firebird который идет с дистрибутива медка, на тестовым специально установлен 2.5.4, опять же для тестов работы с разными версиями FB, так же особо разницы не почувствовал.
Firebird в режиме Classic Server, медок запускался локально с ezvit.exe, кстати не один из тестов не повлиял на скорость запуска клиента (все было довольно быстро)
Так же все тесты показали приблизительно одну и туже нагружу на железо.Это загрузка одного ядра на 100%, т.е. общая нагрузка на процессор не более 25% (обычно нагрузку на процессор создавал только клиент) Память около 300-600МБ
Кроме заведомо высоких, тест с 32-64-256-65536 на себя забрал сразу около 1.5гб памяти

P.S. Есть возможность протестировать базу на SSD винте, хотя в планы пока не входило, не думал что "узкое место" может быть в чтении\записи на диск

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

Ktoia
Повідомлень: 79
З нами з: 23 січня 2015, 14:11

Re: Дополнительные настройки Firebird

Повідомлення Ktoia » 16 листопада 2015, 14:19

Добрый день. Поговорим опять o FireBird.

Всем известна проблема работы Medoc+ FireBird+Zvit.fdb>20гб = тормоза. Как остановить рост Zvit.fdb? Есть такой "прекрасный" модуль в медке "архивация документов". С помощью этого модуля медок переносит первичную документацию с пометкой "архивный" из основной базы в архивную. Вот на работе с этим модулем я и остановлюсь подробнее.
И так что мы имеет на входе. Допустим Zvit.fdb около 60гб, а это значить что в базе приблизительно 500 тыс. документов. Необходимо заархивировать бОльшую часть документов, дабы уменьшит размер БД до рабочего состояния, допустим, не более 15гб. Тут стоит сразу оговорится о том, что все документы перемещенные в архивные базы ограничены только просмотром, т.е. ни каких операций по этим документам кроме печати Вы не сделаете. Из этого следует, что все документы добавить в архивные базы нельзя. В мое случаи исходящие документы это 90% от общего количества документов. Поэтому в архивные базы попали документы по следующему фильтру:
1) По НН исходящие от первого до предпоследнего месяца со статусами: Зареєстровано в ЕРПН, Затверджено контрагентом, Доставлено контрагенту, Відправлено контрагенту
2) По Дот2 исходящие от первого до предпоследнего месяца со статусами: Зареєстровано в ЕРПН, Затверджено контрагентом
3) Последний месяц все документы со статусом – Затверджено контрагентом.
Еще несколько нюансов.
1) Так как, разработчики медка не рекомендуют выполнять архивацию документов в момент работы с базой. Все операции необходимо проводить в нерабочее время, но процесс архивации очень длительный. Например, 300 тыс. документов может архивироваться порядка 4-7 суток в зависимости от ресурсов сервера. Поэтому эту операцию лучше запускать частями.
2) В модуле «Архивация документов» рекомендую выключать галочку «Архивация периодов» после каждого процесса архивации. Если эта галочка установлена, то при пометки документа как архивный, медок сразу пытается перекинуть документ в архивную базу. А это значить что, в рабочем режиме базы, мы запускаем архивацию в фоне, что не рекомендуется делать самими же разработчиками.
3) И еще почему не стоит запускать архивацию документов в фоне. Архивация всегда «съедает» всю ОЗУ на сервере, а это значить тормоза на сервере, т.е. тормоза медка.
4) На своем опыте еще могу рекомендовать каждый раз, при запуске новой архивации удалять файлы старых архивов из списка в модуле архивации. Если их не удалять, то медок повторно проверяет периоды, за которые созданы эти архивные базы и если за эти периоды есть новые архивные документы, пытается дописать их в уже существующие базы. Что увеличивает время выполнения архивации и приводит к глюкам в базе. Например задвоение документов.

И так для уменьшения размера базы, план действий следующий:
1) Закрывает доступ к медку пользователям.
2) Делаем бекап базы медка. Если что-то пойдет не так, что б было к чему вернуться.
3) Проверяем, не стоит ли галочка «архивация периодов» в модуле «архивация документов»
4) Выделяем все старые архивы и нажимаем «Видалити»
5) В реестре первичных документов помечаем необходимые документы как архивные. (За один раз медок может пометить не более 10 тыс. документов ).
6) Ставим галочку «архивация периодов», выбираем период (в моем случае это месяц) и путь для будущих файлов архивных БД.
7) Запускаем архивацию. Ждем.
8) После окончания архивации. Перезапускаем службу ZvitGrp
9) В модуле «архивация документов» снимаем галочку «архивация периодов» и добавляем удаленные ранее архивные базы (так же можно полностью удалить все архивные файлы размером 1 474 560 байт - это пустышки.)
10) Останавливаем службу ZvitGrp.
11) Устанавливаем\Запускаем утилиту IBExpert. (Для русскоязычного комьюнити ПО бесплатное)
12) Добавляем базу данных Zvit.FDB (Параметры подключения на скриншоте)
13) Далее в IBExpert запускаем бекап базы. «Службы»-«Резервирование БД» Выбираем нашу базу, указываем путь где будет создан *.fbk. Обязательно ставим галочку «Сборка мусора» и нажимаем «Начать резервное копирование». Ждем
14) После окончания бекапа запускаем «Службы»-«Восстановление БД». Выбираем «переписать существующую». Указываем путь к файлу *.fbk. Указываем путь к файлу клиентской библиотеки. (Он лежит в корне папки медка). Нажимаем start restore. Ждем
15) После окончания рестора базы, запускаем ZvitGrp.
16) Открываем доступ пользователям.

В итоге получаем: общий объем основной БД Zvit.fdb и архивных файлов будет составлять приблизительно все те же 60гб. Но размер Zvit.fdb будет зависеть прямо пропорционально от количества документов перенесённых в архивные базы. На опыте могу сказать, что базу Zvit.fdb удавалось уменьшить с 50гб до 5гб. Данную операцию рекомендую проводить хотя бы один раз в квартал, в зависимости от объема документов. В любом случае не давайте своей базе расти более чем на 40гб. Удачи.
Вкладення
medoc_ib1.jpg
medoc_ib1.jpg (127.22 Кіб) Переглянуто 5860 разів

Колпаков Б.И.
Повідомлень: 8802
З нами з: 29 липня 2011, 14:59
Звідки: Украина, Донецкая область, Бахмут
Контактна інформація:

Re: Дополнительные настройки Firebird

Повідомлення Колпаков Б.И. » 16 листопада 2015, 15:07

Т.е. после архивирование периодов база остается с размером 60Гб.
Интересно, а простой сбор мусора и бекап базы с помощью IBExpert сколько места освободил бы. :?

Ktoia
Повідомлень: 79
З нами з: 23 січня 2015, 14:11

Re: Дополнительные настройки Firebird

Повідомлення Ktoia » 16 листопада 2015, 15:52

Колпаков Б.И. писав:Т.е. после архивирование периодов база остается с размером 60Гб.
Вымысле база остается размером 60гб ? нет. она уменьшается. Вы внимательно прочитали?
Колпаков Б.И. писав:Интересно, а простой сбор мусора и бекап базы с помощью IBExpert сколько места освободил бы. :?
Ну 1-2гб мусора в зависимости от размера базы.Если не сделать архивацию то по сути "освобождать" нечего, так как база данных реально весит 60гб и это ее реальный размер с учетом количества документов в базе. А вот архивация удаляет эти документы из базы, поэтому после бекапа\рестора она уменьшается на тот объем который был перенесен в базы архивов.

Колпаков Б.И.
Повідомлень: 8802
З нами з: 29 липня 2011, 14:59
Звідки: Украина, Донецкая область, Бахмут
Контактна інформація:

Re: Дополнительные настройки Firebird

Повідомлення Колпаков Б.И. » 16 листопада 2015, 16:09

Я хотел сказать, что она уменьшается только после обработки IBExpert ?
Спасибо.

Ktoia
Повідомлень: 79
З нами з: 23 січня 2015, 14:11

Re: Дополнительные настройки Firebird

Повідомлення Ktoia » 16 листопада 2015, 16:25

Колпаков Б.И. писав:Я хотел сказать, что она уменьшается только после обработки IBExpert ?
Спасибо.
Да конечно, так как базы данных уменьшаться сами не умеют даже если в базе освободилось место, по сути ibexpert не уменьшает, а создает новую базу.

В принципе даже если не использовать IBexpert, а просто пользоваться архивацией, это должно сильно замедлить рост базы. так как новые документы будут размешаться на освободившиеся место в базе после переноса старых.

Ktoia
Повідомлень: 79
З нами з: 23 січня 2015, 14:11

Re: Дополнительные настройки Firebird

Повідомлення Ktoia » 22 грудня 2015, 18:58

Кстати забыл написать. Делал замеры на SSD винте и HDD винтах в 0 рейде
Если сравнивать с табличкой, то первое открытие документов дает ощутимый прирост в производительности. Второе и все последующие открытия документов скорее всего уже подгружаются из кэша, поэтому время открытия одинаковые.

В итоге имеем прирост производительности только после перезапуска сервера Firebird (пока не закэшировались данные) - довольно сомнительный плюс.

Колпаков Б.И.
Повідомлень: 8802
З нами з: 29 липня 2011, 14:59
Звідки: Украина, Донецкая область, Бахмут
Контактна інформація:

Re: Дополнительные настройки Firebird

Повідомлення Колпаков Б.И. » 22 грудня 2015, 23:52

Вывод - уменьшить кэш ?

Ktoia
Повідомлень: 79
З нами з: 23 січня 2015, 14:11

Re: Дополнительные настройки Firebird

Повідомлення Ktoia » 23 грудня 2015, 09:51

Не думаю. Все таки загрузка данных из кеша в любом случае в разы быстрее. Лучше найти золотую середину, что б первое открытие базы было не очень долгим ну и последующие не вызывали "изжогу"

Тут многое зависит от конфигурации сервера и размера БД.

Ivanhoe
Повідомлень: 497
З нами з: 16 березня 2016, 17:29

Re: Дополнительные настройки Firebird

Повідомлення Ivanhoe » 01 червня 2016, 10:22

Кстати, вопрос! При архивировании периодов создаются отдельные файлы, расположенные там, где укажет админ Медка. Вопрос: при бэкапе базы данных Медка, из менеджера архивов или при выходе из базы, данные из таких файлов сохраняются в этом бэкапе? Или проблемой сохранения резервных копий таких файлов есть личная проблема админа Медка, и средствами Медка это никак не решается?
«Чтобы правильно задать вопрос, нужно знать большую часть ответа». Роберт Шекли

AlexConsul

Re: Дополнительные настройки Firebird

Повідомлення AlexConsul » 01 червня 2016, 10:39

Ivanhoe писав:Кстати, вопрос! При архивировании периодов создаются отдельные файлы, расположенные там, где укажет админ Медка. Вопрос: при бэкапе базы данных Медка, из менеджера архивов или при выходе из базы, данные из таких файлов сохраняются в этом бэкапе? Или проблемой сохранения резервных копий таких файлов есть личная проблема админа Медка, и средствами Медка это никак не решается?
Эти файлы - отдельные "кусочки" Вашей БД. И хранятся они тоже отдельно. И статус первички, попавшей в эти "кусочки" - архивный. При резервном копировании эти документы не будут сохранятся в файл резервной копии. Эти "архивчики" так и будут валятся отдельными DBF-никами, и при необходимости Вы их либо подключите к базе для работы с ними, либо отсоедините.

Ivanhoe
Повідомлень: 497
З нами з: 16 березня 2016, 17:29

Re: Дополнительные настройки Firebird

Повідомлення Ivanhoe » 01 червня 2016, 10:57

Т.е. ответ на вопрос про бэкап таких отдельных файлов есть "спасение утопающих дело самих утопающих"? Я правильно понял, что резервирование таких файлов - личная проблема админа Медка, и никак с функционалом Медка не увязана? Повреждение/пропадание таких файлов ведет к невозможности просмотра документов, содержавшихся в таких файлах архивов периодов? Выведение архивированной первички из таких файлов обратно в статус "неархивных" в Медке не предусмотрено?
«Чтобы правильно задать вопрос, нужно знать большую часть ответа». Роберт Шекли

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

Re: Дополнительные настройки Firebird

Повідомлення priup » 01 червня 2016, 11:25

| Показать
Ivanhoe писав:Т.е. ответ на вопрос про бэкап таких отдельных файлов есть "спасение утопающих дело самих утопающих"? Я правильно понял, что резервирование таких файлов - личная проблема админа Медка, и никак с функционалом Медка не увязана? Повреждение/пропадание таких файлов ведет к невозможности просмотра документов, содержавшихся в таких файлах архивов периодов? Выведение архивированной первички из таких файлов обратно в статус "неархивных" в Медке не предусмотрено?
https://www.youtube.com/watch?v=iTOELJdMbdw
Ага…

AlexConsul

Re: Дополнительные настройки Firebird

Повідомлення AlexConsul » 01 червня 2016, 11:35

Ivanhoe писав:Т.е. ответ на вопрос про бэкап таких отдельных файлов есть "спасение утопающих дело самих утопающих"? Я правильно понял, что резервирование таких файлов - личная проблема админа Медка, и никак с функционалом Медка не увязана? Повреждение/пропадание таких файлов ведет к невозможности просмотра документов, содержавшихся в таких файлах архивов периодов? Выведение архивированной первички из таких файлов обратно в статус "неархивных" в Медке не предусмотрено?
Нет, т.к. эти файлы рассматриваются как отдельные, скажем, "попериодные" резервные копии первички. За их сохранность, как и за сохранность обычной резкопии .ZBK несёт ответственность пользователь.

Відповісти

Повернутись до “M.E.Doc сервер-клієнт”