CftClub.ru
Клуб специалистов ЦФТ-Банк

Обновление системных пайп(PIPES_REFRESH)
На страницу 1, 2  След.
 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> АРМы
Предыдущая тема :: Следующая тема  
Автор Сообщение
a_abdugani
Участник со стажем


Вступление в Клуб: 14.04.2011
СообщениеСр Окт 09, 2013 08:37   Обновление системных пайп(PIPES_REFRESH) Ответить с цитатой
Полезность: Нет оценки
Доброго дня!
Подскажите, пожалуйста, как влияет системное задание Обновление системных пайп(PIPES_REFRESH), если удалить из очереди заданий? ЦФТ рекомендует установить периодичность выполнение операции 120-300 минут. Вообще-то, какую функцию выполняет это операция. Разгружает ли нагрузку БД?
Alexsey
Эксперт


Вступление в Клуб: 06.09.2007
СообщениеСр Окт 09, 2013 10:54   Re: Обновление системных пайп(PIPES_REFRESH) Ответить с цитатой
Полезность: Нет оценки
a_abdugani пишет:
Доброго дня!
Подскажите, пожалуйста, как влияет системное задание Обновление системных пайп(PIPES_REFRESH), если удалить из очереди заданий? ЦФТ рекомендует установить периодичность выполнение операции 120-300 минут. Вообще-то, какую функцию выполняет это операция. Разгружает ли нагрузку БД?

Вычищает пайпы.
_________________
всегда есть как минимум 2 выхода
a_abdugani
Участник со стажем


Вступление в Клуб: 14.04.2011
СообщениеПт Окт 11, 2013 08:10    Ответить с цитатой
Полезность: Нет оценки
Очишает пайпы. Это понятно. Разгружает ли оно сервер БД?
Alkov
Профи


Вступление в Клуб: 23.09.2010
СообщениеПт Окт 11, 2013 09:52    Ответить с цитатой
Полезность: Нет оценки
Если пайпы никем не вычитываются - то точно да Wink
a_abdugani
Участник со стажем


Вступление в Клуб: 14.04.2011
СообщениеПн Окт 14, 2013 10:15    Ответить с цитатой
Полезность: Нет оценки
Знаеть ли кто нибудь причины частого появление пайпов? Связано ли это с hardware?
Alexsey
Эксперт


Вступление в Клуб: 06.09.2007
СообщениеПн Окт 14, 2013 10:28    Ответить с цитатой
Полезность: Нет оценки
a_abdugani пишет:
Знаеть ли кто нибудь причины частого появление пайпов? Связано ли это с hardware?
Причины частого переполнения пайп, это большое количество отладочной информации, которая ни кем не вычитывается. Обычно отладка появляется при выявлении каких-либо проблем и включением отладочной информации в справочнике "DEBUG_TRIGER" и невыклчюением ее по окончании отладки.
_________________
всегда есть как минимум 2 выхода
a_abdugani
Участник со стажем


Вступление в Клуб: 14.04.2011
СообщениеПн Окт 14, 2013 19:58    Ответить с цитатой
Полезность: Нет оценки
Отладочная информация отключена. Интересно при каких проблемах появляется лишние пайпы.
vtar
Эксперт


Вступление в Клуб: 20.03.2009
СообщениеПн Окт 14, 2013 23:38    Ответить с цитатой
Полезность: Нет оценки
a_abdugani пишет:
Отладочная информация отключена. Интересно при каких проблемах появляется лишние пайпы.

в (г.) коде при переносе на продакшен осталось, типа лишнее , например без принудительного подъема Монитора ( debug_pipe( bla-bla-bla, 0 ))
alx
Участник - экстремал


Вступление в Клуб: 29.06.2007
СообщениеВт Окт 15, 2013 08:42    Ответить с цитатой
Полезность: Нет оценки
или, как вариант для библиотек, где debug_pipe не работает -
stdio.put_line_pipe('текст отладки',pipe_name);
devor
Профи


Вступление в Клуб: 13.02.2012
СообщениеПн Окт 21, 2013 10:59    Ответить с цитатой
Полезность: Нет оценки
Какую-то ерунду тут все автору написали.
Абдугани, у операции PIPES_REFRESH есть описание во вкладке "Комментарий".

Цитата:
Операция производит обновление списков пользовательских
сессий в подписках на события сброса кэша интерфейсных пакетов
типов, рассылаемых пакетом cache_mgr
. Также операция
удаляет неиспользуемые системные пайпы, принадлежащие
удаленным пользовательским сессиям
.
Операция может запускаться как самостоятельно, так и
через механизм заданий по расписанию. Рекомендуемая
периодичность запуска - несколько раз в сутки.
Операцию можно поставить в очередь как отдельно, так и через
операцию "Запуск системных заданий" ([SUBMIT_SYS_JOBS]).
devor
Профи


Вступление в Клуб: 13.02.2012
СообщениеПн Окт 21, 2013 11:13    Ответить с цитатой
Полезность: Нет оценки
Другими словами, операция обновляет список пользователей, стоящих в очереди за получением событий типа rtl.send_events
Например, если у вас есть настройка в справочнике FP_TUNE и ее значение кешируется, то при установке/изменении значения настройки, всем пользователям рассылается уведомление о сбросе кеша. В случае разных коллизий, пользователи могут это сообщение не получить и висеть в списках на получение.

Именно поэтому, флаг кеширования значений для настроек FP_TUNE нужно ставить обдуманно - если значение настройки будет часто меняться, то лучше кеширование для настройки не включать.
Andry
Участник - экстремал


Вступление в Клуб: 14.01.2009
СообщениеВт Окт 22, 2013 12:22    Ответить с цитатой
Полезность: Нет оценки
devor пишет:

Именно поэтому, флаг кеширования значений для настроек FP_TUNE нужно ставить обдуманно - если значение настройки будет часто меняться, то лучше кеширование для настройки не включать.

В былые времена работы с ЦФТ было интересно получить статистику по использованию этого кеша и статистику обращений к некеширующимся значениям.

Как определить - какие значения достойны быть кешированными (части используются и редко меняются)?
devor
Профи


Вступление в Клуб: 13.02.2012
СообщениеВт Окт 22, 2013 16:19    Ответить с цитатой
Полезность: Нет оценки
Andry пишет:

В былые времена работы с ЦФТ было интересно получить статистику по использованию этого кеша и статистику обращений к некеширующимся значениям.


В либе есть глобальная временная табличка со значениями. В ней самые востребованные значения "всплывают". Ее можно анализировать.

Andry пишет:

Как определить - какие значения достойны быть кешированными (части используются и редко меняются)?

Понятно, что востребованность зависит от роли пользователей (выполняемых функций), т.е. от используемого банком функционала.
В принципе, при желании можно и это проанализировать.
vtar
Эксперт


Вступление в Клуб: 20.03.2009
СообщениеСр Окт 23, 2013 14:57    Ответить с цитатой
Полезность: Нет оценки
devor пишет:
Какую-то ерунду тут все автору написали.
Абдугани, у операции PIPES_REFRESH есть описание во вкладке "Комментарий".

Ну да, в теме собрались клоуны, + дортаньян devor
А теперь читаем темку, как у людей валились серваки

http://www.cftclub.ru/viewtopic.php?t=739

У нас тоже похожее было. Полностью память сжиралась, swap полностью съедался тоже. По top наблюдали кучу процессов от oracle и лавинообразное уменьшение свободного места в swap. Соответственно работать с АБС было невозможно, приходилось останавливать БД (при этом ждать долго пока все процессы завершатся) и перезапускать сервер выключением/включением. Случилось у нас такое 2 раза с разницей, примерно, в 1 месяц. Обращались в Oracle и ЦФТ. Кто-то из них посоветовал перейти на Oracle 11.2.0.3, там, якобы, лучше с управлением памятью. Реально грешили на АБС и на управление блокировками. Общались по этому поводу с ЦФТ, в результате рекомендовали нам системные задания по расписанию в ЦФТ-Банк настроить. Теперь у нас запускается ряд системных заданий и вот уже 8 месяцев проблем нет.
Alexander пишет:
egoist пишет:

Интересная картина получаетсяSmile А что за системные задания. У нас дело странное. Сначала грешили на не правильный код одного программиста и реально такой присутствовал только на др.сервере на тестовом , там очень похожая ситуация , зацикливание было и сервер вставал, причем мертво , но перезапуск базы и все гуд.(на тестовом конфигурация железа и ос один в один с боевым)
На боевом сервере при зависоне , один раз успели подцепиться и потушить базу. Я думал будет чудо , но память не высвободилась , точнее высвободилась , но гигов на 16 , 40 еще где-то висели и так не нашли куда делись 40 гигов, всю статистику просмотрели , ни каких джобов , свапов, левых процессов oracle ни че пусто... я не знаю может руки такие кривые.... но так и не нашел эти 40 гигов , помогла только перезагрузка.


Вот эти:

SYSTEM_JOBS PIPES_REFRESH Обновление системных пайп SYSTEM_JOBS ORSA_REFRESH Обновить (очистить) очередь отчетов SYSTEM_JOBS LOCK_INFO_RUN Запуск процесса поддержки SYSTEM_JOBS LOCK_REFRESH Обновить список блокировок SYSTEM_JOBS CHECK_LIC_VALUES Проверка лицензионной SYSTEM_JOBS LOCK_INFO_STOP Останов процесса поддержки
devor
Профи


Вступление в Клуб: 13.02.2012
СообщениеСр Окт 23, 2013 15:34    Ответить с цитатой
Полезность: Нет оценки
vtar пишет:
devor пишет:
Какую-то ерунду тут все автору написали.
Абдугани, у операции PIPES_REFRESH есть описание во вкладке "Комментарий".

Ну да, в теме собрались клоуны, + дортаньян devor
А теперь читаем темку, как у людей валились серваки

http://www.cftclub.ru/viewtopic.php?t=739

У нас тоже похожее было. Полностью память сжиралась, swap полностью съедался тоже. По top наблюдали кучу процессов от oracle и лавинообразное уменьшение свободного места в swap. Соответственно работать с АБС было невозможно, приходилось останавливать БД (при этом ждать долго пока все процессы завершатся) и перезапускать сервер выключением/включением. Случилось у нас такое 2 раза с разницей, примерно, в 1 месяц. Обращались в Oracle и ЦФТ. Кто-то из них посоветовал перейти на Oracle 11.2.0.3, там, якобы, лучше с управлением памятью. Реально грешили на АБС и на управление блокировками. Общались по этому поводу с ЦФТ, в результате рекомендовали нам системные задания по расписанию в ЦФТ-Банк настроить. Теперь у нас запускается ряд системных заданий и вот уже 8 месяцев проблем нет.
Alexander пишет:
egoist пишет:

Интересная картина получаетсяSmile А что за системные задания. У нас дело странное. Сначала грешили на не правильный код одного программиста и реально такой присутствовал только на др.сервере на тестовом , там очень похожая ситуация , зацикливание было и сервер вставал, причем мертво , но перезапуск базы и все гуд.(на тестовом конфигурация железа и ос один в один с боевым)
На боевом сервере при зависоне , один раз успели подцепиться и потушить базу. Я думал будет чудо , но память не высвободилась , точнее высвободилась , но гигов на 16 , 40 еще где-то висели и так не нашли куда делись 40 гигов, всю статистику просмотрели , ни каких джобов , свапов, левых процессов oracle ни че пусто... я не знаю может руки такие кривые.... но так и не нашел эти 40 гигов , помогла только перезагрузка.


Вот эти:

SYSTEM_JOBS PIPES_REFRESH Обновление системных пайп SYSTEM_JOBS ORSA_REFRESH Обновить (очистить) очередь отчетов SYSTEM_JOBS LOCK_INFO_RUN Запуск процесса поддержки SYSTEM_JOBS LOCK_REFRESH Обновить список блокировок SYSTEM_JOBS CHECK_LIC_VALUES Проверка лицензионной SYSTEM_JOBS LOCK_INFO_STOP Останов процесса поддержки


"дортаньян" devor не понимает, как связана между собой отладка debug_pipe и системное задание PIPES_REFRESH.
Даю справку: правильный ответ - никак.
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> АРМы Часовой пояс: GMT + 3
На страницу 1, 2  След.
Страница 1 из 2

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru