4.4.Настройка производительности СУФД
4.4.1.Уровень приложения
Большое влияние на производительность системы оказывает уровень логирования, описанный в п. 4.3. Для постоянной стабильной работы сервера рекомендуется везде указывать уровень логирования не выше ERROR.
Для улучшения производительности системы, в файле etc/sufd.properties, можно выставить, для указанных ниже параметров, следующие значения:
sufd.hibernate.show_sql=false
sufd.hibernate.format_sql=false
Там же стоит выставить следующие значения:
client.log4j.console.threshold=ERROR
client.log4j.file.threshold=ERROR
Немалое влияние на производительность системы оказывает также работа транспорта. Необходимо корректно выбирать интервалы обработки пакетов (см. пункт «Настройка комплексов, транспортных адресов и транспортных подключений» документа «PM.040_Руководство по установке СУФД СБ6 v2.21»). Если нужна работа транспорта, приближенная к работе в реальном времени, то значения таймаутов должны быть в пределах 5 с. Если транспорт отправляет пакеты лишь периодически, то можно поднять значение таймаутов до приемлемого уровня.
Для повышения производительности системы на машинах с минимальным количеством оперативной памяти можно изменить настройки использования памяти. Для этого, в зависимости от используемой ОС, нужно выполнить следующие действия:
Для HP-UX, нужно отредактировать файл STAND/etc/gc/HP-UX.sh:
GC_SETTINGS=«-Xmx6g –Xms3g -XX:MaxPermSize=1g -XX:+UseParallelGC -XX:+UseParallelOldGC»
Для Windows нужно отредактировать файл \STAND\jetty.bat:
set GC_SETTINGS=-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+AggressiveHeap -XX:+UseParallelGC
где:
Xmx1500m – максимальный размер занимаемой СУФД памяти;
Xms512m – минимальный размер занимаемой СУФД памяти;
MaxPermSize=512m – размер сборщика временных файлов.
4.4.2.Уровень БД
Настройка производительности БД – это нетривиальная задача, которая периодически встает перед администратором БД. Нет единого решения, что нужно сделать, чтобы производительность БД была оптимальной. Обычно это зависит от множества факторов, таких как ОС и её настройки, параметры оборудования, настройки БД, настройки ППО и другие. Поэтому и мониторинг производительности включает в себя не только наблюдение за состоянием БД, но и наблюдение за состоянием аппаратной части.
Мониторинг производительности БД должен осуществляться администратором на постоянной основе. А в зависимости от ситуации и показателей инструментария для анализа БД и сервера БД, администратор принимает решение, каким образом он может исправить сложившуюся ситуацию.
Для базового мониторинга производительности и состояния БД можно выполнить следующие действия:
Проверить alert.log базы данных. Найти все сообщения об ошибках и проанализировать их.
Воспользоваться Oracle EM.
Использовать утилиты ОС по мониторингу аппаратной части, такие как nmon, top, topas, sar.
Воспользоваться документом «Инструкция по выявлению причин низкой производительности базы данных».
4.5.Создание и проверка бэкапов систем (БД и ППО)
Работы по резервному копированию и восстановлению системы необходимо производить в соответствии с документом «Регламент резервного копирования и восстановления АСФК».
4.6.Обновление систем СУФД и СУФД-Портал
4.6.1.Подготовка к обновлению
Проверить завершение Опер. дня.
Требуется проверить входящий каталог для абонентов ППО «СЭД» с внешней стороны. Т.е. Тоссер в данный момент не перекладывает входящие документы извне (исходящие документы из ППО «СЭД» уровней управлений и отделений). Желательно получить от сотрудников казначейства (начальников отделений) подтверждение в том, что документы за текущий опер. день в формате ТФФ предоставлены в полном объеме, как от УБП управления, так и от УБП отделений.
Также нужно получить подтверждение о закрытии опер. дня со стороны OEBS или о прекращении активности по регистрации документов, проведении по статусам и обработки отчетности в текущем опер. дне.
Проверить каталоги транспортного обмена.
Входящий каталог ППО «АСФК (СУФД)» (из которого непосредственно забираются файлы) должен быть пустым.
Желательно проверить карантин Тоссера, для предотвращения случаев падения СБ.
Желательно разобрать папку Bad (входящих ТФФ).
-
Проверить таблицы на предмет текущей обработки и зависших (ошибочных) документов.
-
Проверить интеграционные таблицы TB_Message. В них не должно быть документов в статусе, отличном от «3» (в обоих направлениях).
Запрос:
« select sys_from_code, status, count(*) from tb_message group by sys_from_code, status »
Выводимые поля:
«Направление» (2 – соответствует ППО «АСФК (OEBS)», 1 – соответствует ППО «АСФК (СУФД)»);
«Количество документов на статусе»;
«Статус» (статус «1» – документы еще не обработались, необходимо дождаться перехода на статус «3»; cтатус «2» – документы в обработке, необходимо дождаться перехода на cтатус «3»; cтатус «4» – документы обработаны с ошибкой, необходимо проанализировать ошибки, которые указаны в поле «tb_message.error_message»).
-
Проверить очереди для рассылки (не должно быть документов в статусе «3080» и «11101» в таблице DOC).
Запрос:
« select count(*) from doc where docstateid in (3080, 11101)»
Выводимые поля: «Количество документов».
В случае если количество больше нуля, дождаться его уменьшения. Если количество данных документов долго не уменьшается, то выполнить запрос:
« update doc set docstateid = 18 where docstateid in (3080, 11101) »
(далее выполнить шаг 3.3). Далее выполнить пункты 1 и 2 (п. 4.6.1) в срезе проверки транспортных каталогов и тоссера.
-
Необходимо проверить в таблице DOC наличие документов со статусом «18».
В случае их обнаружения, если их количество не уменьшается, запустить АП Обработки входящих документов (возможно, понадобится изменить параметр «Delay» у АП на значение «1 минута») и повторить шаги 3.1- 3.2.
Запрос:
« select count(*) from doc where docstateid = 18 »
Выводимые поля: «Количество документов».
-
Необходимо проверить в таблице DOC наличие документов со статусом «16».
В случае их обнаружения необходимо проанализировать ситуацию и изучить логи.
Запрос:
« select count(*) from doc where docstateid = 16 »
Выводимые поля: «Количество документов».
-
Необходимо проверить в таблице DOC наличие документов со статусом «20».
В случае их обнаружения необходимо проанализировать ситуацию и изучить логи.
Запрос:
« select count(*) from doc where docstateid = 20 »
Выводимые поля: «Количество документов».
-
Проверить транспортные очереди.
-
Проверить в таблицах QUEUE_DOCUMENT, QUEUE_PACKET_IN и QUEUE_PACKET_OUT записи со статусами RECEIVED и SEND_READY. В случае их обнаружения дождаться их обработки (перехода на статусы PROCESSED или NULL) .
Запрос:
« select item_status,DIRECTION,count(*) from QUEUE_DOCUMENT group by item_status,DIRECTION »
Выводимые поля:
«Статус»;
«Направление»;
«Количество документов на статусе».
-
Статус RECEIVED. Необходимо дождаться, пока оставшиеся с этим статусом документы перейдут на статус NULL.
-
Статус SEND_READY. Необходимо дождаться, пока оставшиеся с этим статусом документы перейдут на статус NULL или, в крайнем случае, SENT.
-
Статус SENDING (Direction «OUT»). Означает, что документ находится в обработке. Если он долго находится в этом статусе, то необходимо статус сбросить в SEND_READY и повторить шаг 4.2.
-
Статусы SENDING_ERROR, PROCESSING_ERROR. Необходимо проанализировать ошибки, описанные в поле ERROR_MESSAGE. Возможно (в случае ошибок, связанных, например, с недоступностью каких либо служб), понадобится переотправка или повторный прием. Для переотправки перевести документ на статус SEND_READY (при этом в поле DIRECTION должно быть значение OUT). Для повторного приема перевести документ на статус RECEIVED (при этом в поле DIRECTION должно быть значение IN).
Запрос:
« select STATUS,count(*) from QUEUE_PACKET_OUT group by STATUS »
Выводимые поля:
«Статус»;
«Количество документов на статусе».
-
Статус SEND_READY. Необходимо дождаться пока оставшиеся на этом статусе документы перейдут на статус NULL или, в крайнем случае, SENDED.
-
Статус SENDING. Этот статус означает, что документ находится в обработке. Если он долго находится в этом статусе, то необходимо сбросить в SEND_READY статус и повторить шаг 4.6.
-
Статусы ERROR, PROCESSING_ERROR. Необходимо проанализировать ошибки, описанные в поле ERRORMESSAGE. Возможно (в случае ошибок, связанных, например, с недоступностью файлового/FTP шлюза), понадобится переотправка или повторный прием. Для переотправки перевести документ на статус SEND_READY.
Запрос:
« select STATUS,count(*) from QUEUE_PACKET_IN group by STATUS »
Выводимые поля:
«Статус»;
«Количество документов на статусе».
-
-
Статус RECEIVED. Необходимо дождаться пока оставшиеся на этом статусе документы перейдут на статус NULL.
-
Статус PROCESSING. Этот статус означает, что документ находится в обработке. Если он долго находится в этом статусе, то необходимо сбросить в RECEIVED статус и повторить шаг 4.9.
-
Статусы ERROR, PROCESSING_ERROR. Необходимо проанализировать ошибки, описанные в поле ERRORMESSAGE. Возможно (в случае ошибок, связанных, например, с недоступностью файлового/FTP шлюза), понадобится переотправка или повторный прием. Для повторного приема перевести документ на статус RECEIVED.
-
Работа с автопроцедурами:
-
Остановить планировщик АП.
-
Дождаться окончания выполнения автопроцедур.
-
Произвести отключение Тоссера, предназначенного для переноса файлов формата ТФФ.
Остановить сервер приложений ППО «АСФК (СУФД)».
4.6.2.Установка обновления
Подробные инструкции по обновлению содержатся в пакетах обновления.
|
