Для начала попробуем перенести базу на ssd диск. Опубликовал новую версию основного процесса, гораздо более нагруженного по скриптам. Через неделю (когда уже запустилось значительное количество их экземпляров) все почувствовали, что база стала тормозить (( Вопрос. Возможно ли как-то оценить узкие места в существующей базе? Оптимизировать ее?
В общем произошло что-то не ясное. База по сути умерла. Размер за 3 дня вырос на 2гб (с 17 до 19). Мы каждую ночь осуществляем резервное копирование базы средствами бат файла по инструкции, которая есть в базе знаний. Работу скрипт всегда заканчивал в одно и то же время, около 4.30 утра (запускается что-то в районе 12 ночи). И тут по времени создаваемых файлов FDB стало видно, что с базой что-то не так. В первый день скрипт трудился до 5.30 утра. На второй день (сегодня) до 6.30 утра. Ну и базой стало уже сегодня невозможно пользоваться. Генерация страницы "Процессы" составила более 20 минут. Откатились на позавчерашнюю базу. Посмотрим что будет дальше. В экземплярах процессов сообщений об ошибках нет. Всего запущенных экземпляров не так уж и много, менее 70 штук. Что могло так нагрузить базу? В процессе используется в нескольких местах выход из задачи по скрипту, с проверкой значения каждую минуту. Я знаю, тут на форуме где-то уже проскальзовало, что это не оптимальный способ. Но наверное не могло же это ТАК повлиять?
В диагностике системы (Администрирование-Система-Диагностика системы) отчет о производительности системы смотрели? Кроме того если есть база 19 Гб и база 17 Гб, и есть подозрение что тормоза обусловлены этими 2 Гб, посмотрите обе базы подняв их на отдельном ПК и найдите где именно (в каких таблицах) база приросла на такой объем. Дольше стал производиться бэкап? Логи бэкапа ведутся? Что там?
Да проблему надо искать в том, почему так выросла база за 2 дня, и тормоза скорее всего из-за этого. Есть гипотеза что это связано с каким-то бесконечным циклом который образовался в процессе и который постоянно что-то пишет в базу. Версия про то, что есть эскалация по срипту не выглядит очень вероятной, но тоже может быть, особенно если 70 экземпляров процессов были активны одновременно. И стоит посмотреть какая таблица в БД значительно выросла после начала использования процессов.
Да, мысль про бесконечный цикл или какой-то постоянный запрос сразу пришла мне в голову тоже: у меня был аналогичный опыт, когда я на тестовой базе, где веду разработку процессов, однажды экспериментируя, создал минипроцесс с бесконечным циклом и штатными средствами элмы прервать этот процесс не смог (элма выдавала ошибку на попытку прервать). Так я его и оставил. И где-то за месяц с базой стало невозможно работать из-за аналогичных жутких тормозов (правда размер базы сильно не рос). Статистику производительности на текущий момент я выгрузил, правда случайно ее обнулил перед этим, поэтому период ее сбора составил 10 минут. Ну и статистика относится к восстановленной вчера базе. Вот я смотрю на эти цифры сейчас, сами значения вроде бы вполне понятны (кол-во запросов, кол-во фоновых задач и т.п.), но вот насколько эти цифры большие/маленькие (может огромные?), в разрезе их влияния на производительность системы совершенно не понятно для меня. Был бы признателен, если кто-нибудь глянет и скажет, что что-то не в порядке или наоборот все цифры не большие и причин для снижения производительности нет.
В кратком руководстве администратора стр 86 и далееочень хорошо излагается как анализировать эти отчеты. Сразу оговорюсь, из-за краткого периода отчета возможно все аномалии связаны с неудачным моментом, поэтому надо проверить на более длительном промежутке времени, но если все же основываться на предоставленных данных, то: Сравнив со своим вижу, что у чуть ниже загрузка по веб запросам, т.е. это не пользователи аномальную загрузку создают. А вот фоновая активность у вас в 5-10 раз выше. В фоновых задачах основное время отрабатывал метод Scheduler - StepSchedulerSweep. Планировщик. Судя по странице SQL запросов это вызвано единственным запросом который обращается к таблице SchedulerJobRunInfo. Стоит посмотреть на эту таблицу на предмет общего количества записей (она обычно немаленькая) актуальности индексов, посмотрел что показывает план выполнения самого длительного запроса. К сожалению с FB базами работал очень поверхностно, может коллеги смогут дать более толковые рекомендации как ускорять запросы к базам этого вендора. В вызовах методов на первом месте всевозможные методы связанные с процессами. Для столь сжатого промежутка времени это может говорить о неоптимальности построенного процесса 153 и 233 запуска для 2х сценариев за 15 минут, ну как бы сами сценарии отработали быстро, но реально ли нужна такая частота? Думаю стоит посмотреть архитектуру процессов на предмет оптимизации. Общее резюме пока такое - неоптимально сконструировав процессы, вы создали большую нагрузку на планировщик и на таблицу SchedulerJobRunInfo (большое количество записей). Замедление работы планировщика привело к замедлению работы той части системы которая с ним непосредственно связана (процессы например). Скорее всего недавний случай с резким ростом базы тоже связан с этим, например бесконечным циклом как говорили коллеги ранее.
Большое спасибо за столь развернутый, обстоятельный ответ! Он мне очень помог. Особенно спасибо за ссылку на руководство администратора, раньше он мне не попадался на глаза, очень и очень полезный документ. И раздел посвященный оценке производительности системы оказался очень подробный и ответил на все мои вопросы. С базой удалось разобраться и восстановить ее работоспособность. Проблема была действительно в моей новой версии основного процесса где использовалось 2 таймера. Один просто как элемент "таймер" на карте процесса, с периодичностью 1 минута. Второй как таймер проверке скрипта для автовыхода из задачи тоже с периодичностью 1 минута. В сумме на момент падения было около 60 активных процессов где работали эти 2 таймера. То есть 120 обновлений в минуту с записями в историю процессов и может еще какие-то таблицы в базе. Я когда создавал процесс, в целом не думал, что это может быть столь критично (учитывая производительность современного железа). В итоге процесс переопубликовал сократив периоды таймеров до 1 проверки в день. Ну и пришлось все активные процессы руками прервать и создать заново (( Сейчас уже третий рабочий день - полет нормальный. Размер базы после бэкап-ресторе почти не увеличивается, скорость восстановления gback такая же как была раньше. Спасибо за помощь!