Обновление системных пайп(PIPES_REFRESH)
На страницу 1, 2 След.
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
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 |
|
Полезность: Нет оценки
|
Если пайпы никем не вычитываются - то точно да  |
|
|
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 пишет: |
Интересная картина получается А что за системные задания. У нас дело странное. Сначала грешили на не правильный код одного программиста и реально такой присутствовал только на др.сервере на тестовом , там очень похожая ситуация , зацикливание было и сервер вставал, причем мертво , но перезапуск базы и все гуд.(на тестовом конфигурация железа и ос один в один с боевым)
На боевом сервере при зависоне , один раз успели подцепиться и потушить базу. Я думал будет чудо , но память не высвободилась , точнее высвободилась , но гигов на 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 пишет: |
Интересная картина получается А что за системные задания. У нас дело странное. Сначала грешили на не правильный код одного программиста и реально такой присутствовал только на др.сервере на тестовом , там очень похожая ситуация , зацикливание было и сервер вставал, причем мертво , но перезапуск базы и все гуд.(на тестовом конфигурация железа и ос один в один с боевым)
На боевом сервере при зависоне , один раз успели подцепиться и потушить базу. Я думал будет чудо , но память не высвободилась , точнее высвободилась , но гигов на 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.
Даю справку: правильный ответ - никак. |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
