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

Производительность lock_info
На страницу 1, 2, 3  След.
 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA
Предыдущая тема :: Следующая тема  
Автор Сообщение
SuperMultik
Участник со стажем


Вступление в Клуб: 06.05.2009
СообщениеСр Май 06, 2009 15:06   Производительность lock_info Ответить с цитатой
Полезность: Нет оценки
Добрый день.
Есть внешний lock_info
запущено 3и сервиса периодически возникает проблема "притормаживания" пользовательских операций (различные взаимосвязь не выявлена) при этом в данный промежуток времени в статспаке видем такую картинку:
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
CPU time 791 75.0
pipe put 278 244 879 23.1 Concurrenc

x86_64 Linux, Oracle 10.2.0.4.0, ТЯ 6612
библиотеку liblock.so пересобрал использую через extproc32
до этого использовал библиотеку не пересобирая идущую в дистрибе после пересбора среднее время уменьшилось на 1 секунду но думаю это все равно много почти 9 секунд, причем количество запросов не большое 278 для 3х процессов блокировщика должно быть вообще не заметно.
Serj
Профи


Вступление в Клуб: 02.08.2007
СообщениеЧт Май 07, 2009 06:28   Re: Производительность lock_info Ответить с цитатой
Полезность: Нет оценки
SuperMultik пишет:
в статспаке видем такую картинку:
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
CPU time 791 75.0
pipe put 278 244 879 23.1 Concurrenc

x86_64 Linux, Oracle 10.2.0.4.0, ТЯ 6612
- может сама очередь слишком большая - событие вставки в пайпу вызывает большую нагрузку - смотрите длину пайпы.
SuperMultik
Участник со стажем


Вступление в Клуб: 06.05.2009
СообщениеЧт Май 14, 2009 10:17    Ответить с цитатой
Полезность: Нет оценки
проблема в том что очередь пуста, там всего несколько десятков запросов, в базе практически ничего не происходит в момент таких "зависаний". В из ЦФТ советовали перезагружать LOCK_INFO ежедневно но это никак не помогло. Значительно уменьшили колличество обращений к внешнему блокировщику увеличили колличество сервисов его до 3х. Никаких изменений не последовало.
SuperMultik
Участник со стажем


Вступление в Клуб: 06.05.2009
СообщениеЧт Май 14, 2009 10:29    Ответить с цитатой
Полезность: Нет оценки
очень смущает тот факт что среднее время ожидания аж 9 секунд это очень долго.
Serj
Профи


Вступление в Клуб: 02.08.2007
СообщениеЧт Май 14, 2009 11:11    Ответить с цитатой
Полезность: Нет оценки
Внешний блокировщик мы не используем - ничего сказать не могу, ожидания put_pipe не только зависит от очереди - может есть смысл вернуться к "внутреннему" блокировщику?
Вообще конечно если разбираться досконально то трэйсы сессии блокировщика -12 левела + dtrace процесса и долго и курить это все дело...
SuperMultik
Участник со стажем


Вступление в Клуб: 06.05.2009
СообщениеЧт Май 14, 2009 11:16    Ответить с цитатой
Полезность: Нет оценки
Собственно на внешний перешли именно из за того что данная проблема возникала с внутренним Sad но там хоть я могу что то смотреть а внешний выглядит как черная коробочка которая не известно что делает. ЦФТ предложили перейти на внешний увеличив количество сервисов так как на тот момент у нас действительно было много запросов к нему. Тут немного начали копать в другую сторону подозрителен был факт того что при перезагрузке локальной машины пользователя некоторое время запросы выполнялись с нормальной скоростью что никак не должно было влиять на блокировщик. Мне сказали что при например проводках должен запускаться монитор коммуникационного канала локально oramon, замечено что при возникновении проблем он не запускается. Посоветовали запускать его вручную перед запуском навигатора, ожидаем поможет ли, но это не удобно как минимум.
Serj
Профи


Вступление в Клуб: 02.08.2007
СообщениеЧт Май 14, 2009 11:19   Re: Производительность lock_info Ответить с цитатой
Полезность: Нет оценки
SuperMultik пишет:

x86_64 Linux, Oracle 10.2.0.4.0, ТЯ 6612
- а на металинке ничего нету? ,у нас SPARC Solaris - вышеописанных проблем нету и в помине....
SuperMultik
Участник со стажем


Вступление в Клуб: 06.05.2009
СообщениеЧт Май 14, 2009 11:24    Ответить с цитатой
Полезность: Нет оценки
там тоже курил
похожего на свою ситуацию что то не нашел, да и если я не ошибаюсь pipe put это именно большое время обращения к внешней процедуре, то есть как бы библиотека не принимает данные (кстати я правильно осознаю данный процесс?)
Serj
Профи


Вступление в Клуб: 02.08.2007
СообщениеЧт Май 14, 2009 12:04    Ответить с цитатой
Полезность: Нет оценки
SuperMultik пишет:
там тоже курил
похожего на свою ситуацию что то не нашел, да и если я не ошибаюсь pipe put это именно большое время обращения к внешней процедуре, то есть как бы библиотека не принимает данные (кстати я правильно осознаю данный процесс?)
- как из 1 возможно и это, еще можно в ОС strace посмотреть что делает процесс например во время ожидания, интересный момент - запуск монитора по-словам цфт должен помочь(??) - тогда получается что в пайпе есть не вычитанные сообщения - и чертовски странно что перезапуск локальной(!) машины как-то влияет на всё это безобразие(тогда при перезаходе в Навигатор должно так же себя вести приложение - т.е. нормально работать )- бог его знает, но может Novomon там самый новый поставить с самым новым Навигатором посмотреть - как себя ведет с ними система.
Serj
Профи


Вступление в Клуб: 02.08.2007
СообщениеЧт Май 14, 2009 12:07    Ответить с цитатой
Полезность: Нет оценки
В алерт логе или udump - ничего не появляется по поводу события - ну когда перестает запускаться монитор и появляются "висяки"?
SuperMultik
Участник со стажем


Вступление в Клуб: 06.05.2009
СообщениеЧт Май 14, 2009 12:18    Ответить с цитатой
Полезность: Нет оценки
ровным счетом тишина везде, в логе блокировщика тоже все очень чинно и благородно правда уровень логирования больше 3 я как то побоялся ставить, хотя наверное стоит.
Serj
Профи


Вступление в Клуб: 02.08.2007
СообщениеЧт Май 14, 2009 12:40    Ответить с цитатой
Полезность: Нет оценки
SuperMultik пишет:
ровным счетом тишина везде, в логе блокировщика тоже все очень чинно и благородно правда уровень логирования больше 3 я как то побоялся ставить, хотя наверное стоит.
- тогда грубо - при возникновении тормозов

Код:

 select kglnaobj from x$kglob, v$session_wait   where event='pipe put' and kglhdadr=p1raw;


- получаем пайпу - затем, как говорит цфт -монитор её вычитывает, мы же будем чикать -
Код:

exec DBMS_PIPE.PURGE("NAME');
- ежели пайпов несколько можно оформить в виде процедурки
w00per
Профи


Вступление в Клуб: 17.10.2007
СообщениеЧт Май 14, 2009 12:51    Ответить с цитатой
Полезность: Нет оценки
попробуйте запустить
Код:
select * from v_$session_wait
where event like 'pipe%'

SELECT MAX(pipe_size) FROM v_$db_pipes

_________________
I Lie About Everything.
SuperMultik
Участник со стажем


Вступление в Клуб: 06.05.2009
СообщениеЧт Май 14, 2009 12:56    Ответить с цитатой
Полезность: Нет оценки
эм просто если я правильно понял то это не решит проблему то в глобальном смысле, от того что мы очистим пайп.

SQL> SELECT MAX(pipe_size) FROM v_$db_pipes;

MAX(PIPE_SIZE)
--------------
1710
Serj
Профи


Вступление в Клуб: 02.08.2007
СообщениеЧт Май 14, 2009 12:58    Ответить с цитатой
Полезность: Нет оценки
w00per пишет:
попробуйте запустить
Код:
select * from v_$session_wait
where event like 'pipe%'

SELECT MAX(pipe_size) FROM v_$db_pipes
- сдается мне не в размере тут дело, писали же что очередь пустая - просто странный совет дает цфт - вычитывать канал монитором - по идее на канал (если ничего не путаю ) возможно поставить время ожидания для pipe put - не помню только где крутить.
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA Часовой пояс: GMT + 3
На страницу 1, 2, 3  След.
Страница 1 из 3

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