| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
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 |
|
Полезность: Нет оценки
|
Собственно на внешний перешли именно из за того что данная проблема возникала с внутренним  но там хоть я могу что то смотреть а внешний выглядит как черная коробочка которая не известно что делает. ЦФТ предложили перейти на внешний увеличив количество сервисов так как на тот момент у нас действительно было много запросов к нему. Тут немного начали копать в другую сторону подозрителен был факт того что при перезагрузке локальной машины пользователя некоторое время запросы выполнялись с нормальной скоростью что никак не должно было влиять на блокировщик. Мне сказали что при например проводках должен запускаться монитор коммуникационного канала локально 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 - не помню только где крутить. |
|
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
