ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / что можно выудить из latch free в v$session_wait?
25 сообщений из 51, страница 2 из 3
  2  все
что можно выудить из latch free в v$session_wait?
    #35470877
Фотография RA\/EN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RA\/EN
Участник
sql+На русский не нужно переводить. Я просто хотел понять как ты понимаешь суть ожидания, чего именно ждут сессии. В данном твоя случае ссылка на документ этого не раскрывает.
Ну свое понимание данного ожидания я раскрыл - добавить больше к процитированному ничего не имею.
Ваше слово, товарищ маузер! (с) - что Вы подразумеваете под этим ожиданием?
...
Рейтинг: 0 / 0
05.08.2008, 12:55
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35470915
sql+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sql+
Гость
то же самое что в документации.
...
Рейтинг: 0 / 0
05.08.2008, 13:07
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35471042
Фотография RA\/EN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RA\/EN
Участник
sql+то же самое что в документации.
Ну хоть бы процитировал (а то я документацию не читаю ) и обсновал вот это свое глубокомысленное высказывание в мой адрес:
sql+Подозреваю что ты неправильно понимаешь смысл данного события.
--
BTW, для остальных, демка появления RbOS:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
SQL> create table rboswait(id primary key,v) as select level,lpad('x', 2000 ,'x') from dual connect by level<= 120000 ;
 
Table created
 
SQL> 
SQL> SELECT e.total_waits, e.time_waited FROM v$session_event e
   2    WHERE e.sid = sys_context('USERENV','SID') AND e.event = 'read by other session'
   3   /
 
TOTAL_WAITS TIME_WAITED
----------- -----------
 
SQL> -- предварительно запускаем аналогичный блок в другой сессии, только c FOR i IN 1..1e7
SQL> BEGIN
   2     FOR i IN  1 ..1e5 LOOP
   3       FOR r1 IN (SELECT to_number(to_char(systimestamp,'ssff3'))* 2  n FROM dual) LOOP
   4         FOR r2 IN (
   5           SELECT COUNT(v) FROM rboswait WHERE ID BETWEEN r1.n- 10  AND r1.n+ 10 ) LOOP
   6             NULL;
   7           END LOOP;
   8       END LOOP;
   9     END LOOP;
  10   END;
  11   /
 
PL/SQL procedure successfully completed
 
SQL> 
SQL> SELECT e.total_waits, e.time_waited FROM v$session_event e
   2    WHERE e.sid = sys_context('USERENV','SID') AND e.event = 'read by other session'
   3   /
 
TOTAL_WAITS TIME_WAITED
----------- -----------
        3604            94 
 
SQL>
SQL написан так, чтобы обе сессии одновременно хотели один и тот же блок, не находящийся в кэше.
...
Рейтинг: 0 / 0
05.08.2008, 13:50
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35471164
sql+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sql+
Гость
RA\/EN
Ну хоть бы процитировал (а то я документацию не читаю ) и обсновал вот это свое глубокомысленное высказывание в мой адрес:
sql+Подозреваю что ты неправильно понимаешь смысл данного события.


Я написал "подозреваю, что непонимаешь", а не "уверен, что непонимаешь".
А обосновать я не могу по причине твоего отказа прокомментировать.
Я уже сказал, что квотирование документации нераскрывает твоего понимания.

Хотя я без претензий, потому что что-то знать и уметь рассказать это что-то другому - суть разная.
...
Рейтинг: 0 / 0
05.08.2008, 14:22
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35471626
Попрошайка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Попрошайка
Гость
sql+, достаточно будет мне добавить, что происходит вымывание из buffer cache наиболее часто востребованных блоков, что приводит к необходимости копирования их с диска в ОЗУ в рамках конкурирующих за данный блок процессов? Теперь от RAVEN'a ты отстанешь?...:)
...
Рейтинг: 0 / 0
05.08.2008, 16:29
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35471638
Попрошайка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Попрошайка
Гость
Попрошайка sql+, достаточно будет мне добавить, что происходит вымывание из buffer cache наиболее часто востребованных блоков, что приводит к необходимости копирования их с диска в ОЗУ в рамках конкурирующих за данный блок процессов? Теперь от RAVEN'a ты отстанешь?...:)

И что вариантов ДВА:

1. сделай так, чтобы блоки учавствующие в 'read by other session' сидели в кеше долго и с пользой,
2. сделай так, чтобы строчки в таких блоках ('read by other session') стали строчками дополнительных блоков, тем самым снимая нагрузку с "горячих" блоков.
...
Рейтинг: 0 / 0
05.08.2008, 16:32
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35473354
latch free
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
latch free
Гость
Попрошайка Попрошайка sql+, достаточно будет мне добавить, что происходит вымывание из buffer cache наиболее часто востребованных блоков, что приводит к необходимости копирования их с диска в ОЗУ в рамках конкурирующих за данный блок процессов? Теперь от RAVEN'a ты отстанешь?...:)

И что вариантов ДВА:

1. сделай так, чтобы блоки учавствующие в 'read by other session' сидели в кеше долго и с пользой,
2. сделай так, чтобы строчки в таких блоках ('read by other session') стали строчками дополнительных блоков, тем самым снимая нагрузку с "горячих" блоков.
вопрос: эти два варианта могут/должны быть реализованы на уровне приложения (если да, то как - не могу себе представить!) или Вы что-то другое имели в виду?
...
Рейтинг: 0 / 0
06.08.2008, 12:53
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35473516
Попрошайка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Попрошайка
Гость
Дело в том, что одна сессия читает блок с диска и помещает его в buffer cache. Понятно, что Oracle использует принцип хранить в buffer cache одну копию текущего блока, который потом уедет на диск (всякие там клоны блоков не рассматриваем). Поэтому он блокирует все другие сесии на предмет копирования того же самого блока - иначе будет каша, да и с точки производительности это так же не правильно и не логично. Но почему другие сесии ждут этот блок? Напрашивается ответ: "Потому, что другая сессия читает уже его, ну так получилось, что процессор обработал быстрее..., как вариант". А почему она читает? Потому, что его нет в buffer cache его нет. Почему его там нет? Потому, что:
1. его там никогда не было, а тут появилась необходимость ему там быть,
2. его кто-то выдавил из buffer cache.

Отсюда:

1. Пробуем понять по какой причине его там нет. Вдруг его кто-то вымывает из buffer cache, например другие не эффективные SQL. таким образом убрав причину исчезновения блока из buffer cache можно решить проблему с данным ожиданием.

По пункту два можно сказать так. Если смотреть с другой стороны, то возникает и другой вопрос: "Почему один и тот же блок понадобился одновременно разным сессиям?". Напрашивается ответ: "В нем либо много строк, либо это блок индекса (нарастающая нумерация, например) и т.п.". Соответственно, если такой блок разрядить, то есть сократить в нем количество строк на два три и более блоков, то эффект hot можно с него снять. Для индексов, как правило используется прием reverse, для таблицы, как правило pctfree.

Как бы так думаю.
...
Рейтинг: 0 / 0
06.08.2008, 13:27
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35473681
sql+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sql+
Гость
ПопрошайкаДело в том, что
.......
Вдруг его кто-то вымывает из buffer cache, например другие не эффективные SQL . таким образом убрав причину исчезновения блока из buffer cache можно решить проблему с данным ожиданием.
...
Соответственно, если такой блок разрядить, то есть сократить в нем количество строк на два три и более блоков, то эффект hot можно с него снять . Для индексов, как правило используется прием reverse, для таблицы, как правило pctfree.

Как бы так думаю.

1)Совсем необязательно, что неэффективные, могут и эффективные
2)Совсем необязательно, что данная проблема связана с горячими блоками. Если каждый блок запрашивается два раза в день одновременно несколькими сессиями , значит ли что он горячий? Нет. Но таких блоков запрашиваемых два раза на дню может быть мульон. В итоге статистика по данному ожиданию будет большая
3)Причина ожидания может быть очень простой - банально нехватает памяти - буферный кэш мал.
...
Рейтинг: 0 / 0
06.08.2008, 14:04
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35473736
Попрошайка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Попрошайка
Гость
sql+ ПопрошайкаДело в том, что
.......
Вдруг его кто-то вымывает из buffer cache, например другие не эффективные SQL . таким образом убрав причину исчезновения блока из buffer cache можно решить проблему с данным ожиданием.
...
Соответственно, если такой блок разрядить, то есть сократить в нем количество строк на два три и более блоков, то эффект hot можно с него снять . Для индексов, как правило используется прием reverse, для таблицы, как правило pctfree.

Как бы так думаю.

1)Совсем необязательно, что неэффективные, могут и эффективные
2)Совсем необязательно, что данная проблема связана с горячими блоками. Если каждый блок запрашивается два раза в день одновременно несколькими сессиями , значит ли что он горячий? Нет. Но таких блоков запрашиваемых два раза на дню может быть мульон. В итоге статистика по данному ожиданию будет большая
3)Причина ожидания может быть очень простой - банально нехватает памяти - буферный кэш мал.

А никто и не говорит, что все просто и все обязательно. Но когда блок одновременно запрашивается несколькими сессиями раз в три часа, то это НЕ есть проблема. Проблема - это когда она ухужшает производительность. В случае, который описываете вы, а именно якобы маленький buffer cache тождественно равно "блок вымывается" и никак не равен случаю, когда миллион разных блоков накручивают счетчик. Ради таких блоков (я бы их назвад множеством случайных блоков) никто и не собирался buffer cache раздвигать. Тут логичнее такие блоки расщепить. пусть они и Не горячие на столько, чтобы о них говорить, как о горячих.
...
Рейтинг: 0 / 0
06.08.2008, 14:14
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35473760
Попрошайка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Попрошайка
Гость
Кстати, эффективность SQL ведь не только по отношению к ресурсам сервера определяется, но и по отношению к другим SQL. Как вы считаете? Ведь, если два SQL мешают друг другу, то необходимо выявить причину и устранить ее, тем самым устранить не эффективность одного из них или обоих одновременно!
...
Рейтинг: 0 / 0
06.08.2008, 14:19
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35473769
Попрошайка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Попрошайка
Гость
ПопрошайкаКстати, эффективность SQL ведь не только по отношению к ресурсам сервера определяется, но и по отношению к другим SQL. Как вы считаете? Ведь, если два SQL мешают друг другу, то необходимо выявить причину и устранить ее, тем самым устранить не эффективность одного из них или обоих одновременно!


Примером может служить PQ, когда имеет место быть неравномерное наполнение в блоках определенных в рамках диапазонов.
...
Рейтинг: 0 / 0
06.08.2008, 14:22
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35473826
sql+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sql+
Гость
ПопрошайкаКстати, эффективность SQL ведь не только по отношению к ресурсам сервера определяется, но и по отношению к другим SQL. Как вы считаете? Ведь, если два SQL мешают друг другу, то необходимо выявить причину и устранить ее, тем самым устранить не эффективность одного из них или обоих одновременно!

Я бы сказал не по отношению к другому SQL, а пот отношению к тому же SQL, но по другому написаному и оптимизированному в иной степени.

Совсем необязательно, что это разные запросы. Этот может быть абсолютно тот же самый функционал и один и тот же запрос, причём идеально написанный и отлаженный. Просто двое или трое дядек в одном отделе, сидящие в одной комнате решили посмотреть один и тот же документ в своём корпоративном документообороте, что бы обсудить его. Вот вам и "buffer buzy waits(130)", он же "read by other session" в 10g. В совокопнусти с перегруженной дисковой системой и маленьким буферным кэшем.
...
Рейтинг: 0 / 0
06.08.2008, 14:34
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35474022
Попрошайка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Попрошайка
Гость
Хрен с ним, пусть будет, как будет. Как там с вопросом темы...:) "latch free в v$session_wait"
...
Рейтинг: 0 / 0
06.08.2008, 15:21
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35474277
latch free
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
latch free
Гость
ПопрошайкаХрен с ним, пусть будет, как будет. Как там с вопросом темы...:) "latch free в v$session_wait"
с большим интересом следил за развязанноой мною дискуссией, почерпнул много для себя полезного, всем огромное спасибо!

Думаю, что стоит описать ситуевину, приведшую к проблемам (тут я думаю скорее всего был ближе к реальности sql+ в своем последнем посте).

Нужно распределить вновь прибывшие записи из одной таблицы (TAB1, PK1, примерно 910000 записей) на N терминалов, чтобы те - случись что - могли работать и оффлайн дальше. Распределение происходит по определенным правилам, т.е. не все записи должны попасть на каждый терминал, но связь N:M.Решается это так (может не оптимально, прошу не бить сразу, но решение уже принято, запущено, уже так быстро не изменить): в промежуточную таблицу TAB2 пишутся после анализа кому какая запись принадлежит записи типа <TERM - номер терминала> <PK1 от таблицы TAB1>. Дальше есть процесс, распределяющий записи по терминалам, он делает SELECT ... FROM TAB1 JOIN TAB2 ON TAB1.PK1=TAB2.PK1 WHERE TAB1.TERM=NR1 и после успешной отсылки записей уничтожает свои (NR1) записи из TAB2, так что количество записей в ней всегда очень небольшое и этот SQL должен работать очень хорошо. Но не работает - см. топик! Наверно корень зла в том, что запускаются несколько ипостасей этого процесса (каждый обслуживает свою группу терминалов), запускаются они одновременно, просыпаются синхронно после паузы и одновременно пытаются поиметь одни и те же блоки из TAB1. Похоже на причину RbOS? Там еще кстати и таймоуты есть, т.е. бывает, что и не дожидается своего блока, так что ли?

Что смущает, что это не основное время ожидания, db file scattered read гораздо больше. Обычно они связываются с full table scan, но когда я смотрю план, то никаких full table scan нет... Может это быть от сильной фрагментации таблицы TAB1?
...
Рейтинг: 0 / 0
06.08.2008, 16:41
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35474324
Попрошайка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Попрошайка
Гость
Вы сделайте трассировку 10046 именно работы этих процессов, которые работают на терминалы. Можете?
...
Рейтинг: 0 / 0
06.08.2008, 16:53
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35474442
Фотография RA\/EN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RA\/EN
Участник
latch free ПопрошайкаХрен с ним, пусть будет, как будет. Как там с вопросом темы...:) "latch free в v$session_wait"
Дальше есть процесс, распределяющий записи по терминалам, он делает SELECT ... FROM TAB1 JOIN TAB2 ON TAB1.PK1=TAB2.PK1 WHERE TAB1.TERM=NR1 и после успешной отсылки записей уничтожает свои (NR1) записи из TAB2,
...
Похоже на причину RbOS? Там еще кстати и таймоуты есть, т.е. бывает, что и не дожидается своего блока, так что ли?
...
Что смущает, что это не основное время ожидания, db file scattered read гораздо больше. Обычно они связываются с full table scan, но когда я смотрю план, то никаких full table scan нет... Может это быть от сильной фрагментации таблицы TAB1?
1. Процесс, я правльно понял, внешнее приложение?
2. Надо трейс одного "порбега" одного из процессов.
...
3. Похоже - не то слово Похоже, авторы задались целью украсить статспак своего приложения экзотический событием ожидания
...
4.... а также INDEX FAST FULL SCAN
Приведите план запроса.

P.S. Ну и трассу бы (не обработанную tkprof) не помешало бы приложить - однако она будет немного "кривой" - думаю, трассировка настолько тормознет трассируемый процесс, что он будет выполняться параллельно с остальными лишь небольшую часть времени.
...
Рейтинг: 0 / 0
06.08.2008, 17:30
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35474489
Попрошайка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Попрошайка
Гость
Добавлю к RAVEN "2. Надо трейс одного "пробега" одного из процессов." ВО ВРЕМЯ РАБОТЫ ВСЕХ ОДНОВРЕМЕННО!
...
Рейтинг: 0 / 0
06.08.2008, 17:44
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35474865
Стив
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стив
Гость
Я вот чего хочу спросить у автора - не знаю, может это к данной проблеме и не относится - а почему в самом первом посте у вас блоки по 16 считываются? у вас db_file_multiblock_read_count, или как он там, в 16 выставлен? может стоит поболее поставить, ну там 64, например. Понимаю, что данный параметр зависит от железа ввода/вывода, но обычно данный параметр при фулсканах помогает.
хотя с конкуренцией за блоки он не помощник, конечно.
...
Рейтинг: 0 / 0
06.08.2008, 21:10
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #35474944
Попрошайка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Попрошайка
Гость
СтивЯ вот чего хочу спросить у автора - не знаю, может это к данной проблеме и не относится - а почему в самом первом посте у вас блоки по 16 считываются? у вас db_file_multiblock_read_count, или как он там, в 16 выставлен? может стоит поболее поставить, ну там 64, например. Понимаю, что данный параметр зависит от железа ввода/вывода, но обычно данный параметр при фулсканах помогает.
хотя с конкуренцией за блоки он не помощник, конечно.

Кстати, db_file_multiblock_read_count=0 в 10ке автоматически регулирует этот параметр на основе своего интеллекта.
...
Рейтинг: 0 / 0
06.08.2008, 22:52
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
что можно выудить из latch free в v$session_wait?
    #36585051
Фотография Foxter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Foxter
Участник
Уважаемые, а не подскажете как мне отследить время выполнения конкретного запроса для вывода индикации его исполнения (или в секундах, оставшихся до завершения или в %). Понимаю, что надо брать значения из V$SESSION_WAIT, но как мне узнать именно мой запрос?
...
Рейтинг: 0 / 0
19.04.2010, 10:47
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #36585533
Фотография Foxter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Foxter
Участник
FoxterУважаемые, а не подскажете как мне отследить время выполнения конкретного запроса для вывода индикации его исполнения (или в секундах, оставшихся до завершения или в %). Понимаю, что надо брать значения из V$SESSION_WAIT, но как мне узнать именно мой запрос?

Никаких соображений нет? Ммм... жаль, то есть получается, что прогресс выполнения запроса вообще никак контролировать нельзя?
...
Рейтинг: 0 / 0
19.04.2010, 14:02
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #36585594
Фотография suPPLer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
suPPLer
Участник
Foxter,

STFF прогресс выполнения запроса . Вкратце - рисуйте анимированное "Идёт работа, в Reset не тыкать!". :)
...
Рейтинг: 0 / 0
19.04.2010, 14:27
| Ответить | Цитировать | Написать  
что можно выудить из latch free в v$session_wait?
    #36586882
Фотография Foxter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Foxter
Участник
Спасибо, видимо так и придется поступить :)
...
Рейтинг: 0 / 0
20.04.2010, 10:05
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
что можно выудить из latch free в v$session_wait?
    #39362485
VDom
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VDom
Гость
Foxter,
Дело конечно прошлое, но может это кому поможет.
Есть такая вьюшка
SQL> desc v$session_longops
Name Null? Type
----------------------------------------- -------- ----------------------------
SID NUMBER
SERIAL# NUMBER
OPNAME VARCHAR2(64)
TARGET VARCHAR2(64)
TARGET_DESC VARCHAR2(32)
SOFAR NUMBER
TOTALWORK NUMBER
UNITS VARCHAR2(32)
START_TIME DATE
LAST_UPDATE_TIME DATE
TIMESTAMP DATE
TIME_REMAINING NUMBER
ELAPSED_SECONDS NUMBER
CONTEXT NUMBER
MESSAGE VARCHAR2(512)
USERNAME VARCHAR2(30)
SQL_ADDRESS RAW(8)
SQL_HASH_VALUE NUMBER
SQL_ID VARCHAR2(13)
QCSID NUMBER

Обычно её используют для оценки времени выполнения долгоиграющих вещей.
Например завершения бакапа, или время завершения отката большой транзакции.
Зная SQL_ID интересующего запроса можно узнать перспективы его завершения.
...
Рейтинг: 0 / 0
08.12.2016, 12:53
| Ответить | Цитировать | Написать  
25 сообщений из 51, страница 2 из 3
  2  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / что можно выудить из latch free в v$session_wait?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/moderation_log.php?user_name=%D0%9C%D0%9C%D0%AE]:
 0ms
get settings:
 12ms
get forum list:
 18ms
get settings:
 6ms
get forum list:
 19ms
check forum access:
 5ms
check topic access:
 5ms
track hit:
 114ms
get topic data:
 14ms
get forum data:
 4ms
get page messages:
 58ms
get tp. blocked users:
 2ms
others: 717ms
total:  974ms
созд. / загр.: 974ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]