|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Сыпанулся индекс на фрагментированной таблице (oncheck –cI <имя индекса>.) Таблица большая 550 Гб, почти 600 млн. строк. Обращения к этой таблице (insert, update, delete) происходят в режиме 24 Х 7. Заблокировать доступ к таблице не представляется возможным. Разворачивание БД из бэкапа займет около 8 часов. Проверка всех данных таблицы и индексов еще часов 12. Посоветуйте пожалуйста как исправить эту ситуацию с наименьшими потерями по времени? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2015, 10:53 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Забыл написать. Версия 11.70.FC6 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2015, 11:01 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2015, 11:39 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
online то конечно хорошо, хоть он online токо по тому, что не нужна блокировка таблицы, блокировки строк все-равно будут нужно также учитывать специфику приложений не забывайте про PDQ при построении индекса последний раз когда делал online вылилось нехорошими последствиями и пришлось тупо перезапускать сервер из-за малюсенького индекса. Если у вас есть репликация - не факт что на DR сервере битый индекс, возможно стоит перейти туда. Проверить битый ли там индекс достаточно запросом, который будет использовать данный индекс на проблемных значениях. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2015, 12:18 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Спасибо за советы. База без реплики. Индекс по полю c типом DATE. Индекс чуть более 10 Гб Пока пришел к решению, что надо сделать на бэкапе (проверить сколько по времени, один ли индекс поврежден и т.д) drop index create index ... online. 1. Можно по-подробнее, что может быть плохого? 2. PDQ выставить в 0 ? Учитывая что в этой таблице в течении всего дня (без перерывов делаются вставки и удаления строк) Т.е. отдать приоритет всем DML операциям, а затем созданию индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2015, 12:54 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
PDQ нужно использовать(включить) при создании индекса. т.е. помимо конф. параметра MAX_PDQPRIORITY нужно выставить переменную PDQPRIORITY или через оператор set ... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2015, 14:45 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Сергей Б1. Можно по-подробнее, что может быть плохого? 1. Некое замедление в работе, местами м.б. значительное 2. Если приложение при старте парсит а потом по мере надобности візівает запросі - после удаления индекса возможно будет нужен перезапуск приложения. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2015, 14:52 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Сергей БСпасибо за советы. База без реплики. Индекс по полю c типом DATE. Индекс чуть более 10 Гб Пока пришел к решению, что надо сделать на бэкапе (проверить сколько по времени, один ли индекс поврежден и т.д) drop index create index ... online. 1. Можно по-подробнее, что может быть плохого? 2. PDQ выставить в 0 ? Учитывая что в этой таблице в течении всего дня (без перерывов делаются вставки и удаления строк) Т.е. отдать приоритет всем DML операциям, а затем созданию индекса. Блииин !!! Ну зачем же дроп-то сначала ?!!!! Останетесь без индекса (хоть и битого) - прощай производительность (возможно в разы - сиквенс скан на 600 миллионов строк на каждый раз когда был нужен индекс вы себе представили да ?) Сначала создайте новый на тоже поле. Что бы создался - desc добавьте. А потом уже старый удаляйте. Обеспечте что бы новый индекс лез в логи без "длинной транзакции" (база ведь с логированием ?). При типичных настройках это значит что сумма всех логов лучше что бы была равна двум размерам операции ((получается 20Г). Из неожиданного - проверьте что бы место под бэкап этих 10Г логов неожиданно не кончилось :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2015, 22:30 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Век живи, век учись. Это я по поводу создания второго индекса на том же поле при помощи DESC. Тонко, тонко... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2015, 04:11 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Спасибо за совет. Павел, а как отключить логирование при создании индекса? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2015, 12:30 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Сергей БСпасибо за совет. Павел, а как отключить логирование при создании индекса? # LOG_INDEX_BUILDS - Enable (1) or disable (0) index page logging. # Required for RSS. Optional for HDR and SDS. Возможно у вас и не включён. Для изменения параметра требуется перезапуск. Выше я немного лишнего нагнал написав так, что получилось "база с логированием - индекс логируется". Верно: база с логированием - индекс как в LOG_INDEX_BUILDS У меня-то RSS всегда как бесплатный бэкап включён, по этому LOG_INDEX_BUILDS то же всегда 1. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2015, 22:40 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Бэкап ты можешь не любить, но HADR ты иметь обязан! Ведь индекс (быть или не быть) наш ДБА спасти обязан! ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2015, 10:10 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Яковлев ПавелСергей БСпасибо за совет. Павел, а как отключить логирование при создании индекса? # LOG_INDEX_BUILDS - Enable (1) or disable (0) index page logging. # Required for RSS. Optional for HDR and SDS. Верно: база с логированием - индекс как в LOG_INDEX_BUILDS Параметр LOG_INDEX_BUILDS действует для случаев RSS,HDR,SDS. Автор вроде ничего такого не говорил. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2015, 11:10 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Еще раз спасибо. БД без RSS,HDR,SDS. Часто используемый запрос стал выполняться очень долго. Судить, что запрос работает, можно только по onstat –u –r. (поле nreads). Может привести скрин или строку??? Поля reg_paym_dt , reg_date, recv_code , p.pm_state, p.paym_ord проиндексированы. Update statistic high по всей таблицы сделан. На всякий случай, таблица фрагментирована по выражению by round robin in. Почти все чанки зеркалируются Вот запрос Код: plsql 1. 2. 3. 4. 5. 6. 7.
Если запустить запрос без min ( ), то в выборке окажутся св среднем 300000 – 700000 записей и время выполнения около 30 сек Если время выборки установить в пределах 2-3 часов, запрос тоже отрабатывает быстро (2-3 сек), не зависимо от выбранной даты и месяца. Следующая конструкция выполняется менее 2 секунд. Нет оператора min ( ) 1. QUERY: (OPTIMIZATION TIMESTAMP: 06-26-2015 14:31:41) ------ SELECT p.reg_date FROM plat p WHERE p.reg_paym_dt >= '2015-06-13 00:00:00' AND p.reg_paym_dt <= '2015-06-13 23:59:59' AND p.recv_code in (110,101,510,810,403,72101,11101) AND p.pm_state = 3 AND p.paym_ord > 0 Estimated Cost: 449280 Estimated # of Rows Returned: 71534 1) informix.p: INDEX PATH Filters: ((informix.p.recv_code IN (110 , 101 , 510 , 810 , 403 , 72101 , 11101 )AND informix.p.pm_state = 3 ) AND informix.p.paym_ord > 0 ) (1) Index Name: informix.paym__ix_reg_paym_dt Index Keys: reg_paym_dt (Serial, fragments: ALL) Lower Index Filter: informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second Upper Index Filter: informix.p.reg_paym_dt <= datetime(2015-06-13 23:59:59) year to second Query statistics: ----------------- Table map : ---------------------------- Internal name Table name ---------------------------- t1 p type table rows_prod est_rows rows_scan time est_cost ------------------------------------------------------------------- scan t1 81901 71534 464778 00:01.38 449281 2. Создаю по этому запросу темповую таблицу и по ней ищу min (date). Время выполнения менее 2 сек QUERY: (OPTIMIZATION TIMESTAMP: 06-26-2015 14:36:46) ------ Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Estimated Cost: 449280 Estimated # of Rows Returned: 71534 1) informix.p: INDEX PATH Filters: ((informix.p.recv_code IN (110 , 101 , 510 , 810 , 403 , 72101 , 11101 )AND informix.p.pm_state = 3 ) AND informix.p.paym_ord > 0 ) (1) Index Name: informix.paym__ix_reg_paym_dt Index Keys: reg_paym_dt (Serial, fragments: ALL) Lower Index Filter: informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second Upper Index Filter: informix.p.reg_paym_dt <= datetime(2015-06-13 23:59:59) year to second Query statistics: ----------------- Table map : ---------------------------- Internal name Table name ---------------------------- t1 p t2 tmp_r_d type table rows_prod est_rows rows_scan time est_cost ------------------------------------------------------------------- scan t1 81901 71534 464778 00:00.80 449281 type table rows_ins time ----------------------------------- insert t2 81901 00:00.99 QUERY: (OPTIMIZATION TIMESTAMP: 06-26-2015 14:36:47) ------ select min (reg_date) from tmp_r_d; Estimated Cost: 2946 Estimated # of Rows Returned: 1 1) informix.tmp_r_d: SEQUENTIAL SCAN Query statistics: ----------------- Table map : ---------------------------- Internal name Table name ---------------------------- t1 tmp_r_d type table rows_prod est_rows rows_scan time est_cost ------------------------------------------------------------------- scan t1 81901 81901 81901 00:00.04 2946 type rows_prod est_rows rows_cons time ------------------------------------------------- group 1 1 81901 00:00.04 3. Делаю запрос с оператором min, но интервал выборки 2 часа QUERY: (OPTIMIZATION TIMESTAMP: 06-26-2015 14:40:37) ------ Код: sql 1. 2. 3. 4. 5. 6. 7.
Estimated Cost: 9689 Estimated # of Rows Returned: 1 1) informix.p: INDEX PATH Filters: ((informix.p.recv_code IN (110 , 101 , 510 , 810 , 403 , 72101 , 11101 )AND informix.p.pm_state = 3 ) AND informix.p.paym_ord > 0 ) (1) Index Name: informix.paym__ix_reg_paym_dt Index Keys: reg_paym_dt (Serial, fragments: ALL) Lower Index Filter: informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second Upper Index Filter: informix.p.reg_paym_dt <= datetime(2015-06-13 01:59:59) year to second Query statistics: ----------------- Table map : ---------------------------- Internal name Table name ---------------------------- t1 p type table rows_prod est_rows rows_scan time est_cost ------------------------------------------------------------------- scan t1 2108 5961 8619 00:00.02 9689 type rows_prod est_rows rows_cons time ------------------------------------------------- group 1 1 2108 00:00.02 5. делаю запрос с min(p.reg_date) за интервал 1 день. Код: sql 1. 2. 3. 4. 5. 6. 7.
О том, что он не висит видно из команды (колонка nreads) onstat -r -u | grep 1599044 > /tmp/tmp.log nreads 182f12df58 ---PR-- 1599044 informix - 0 0 2 6905200 17408 182f12df58 ---PR-- 1599044 informix - 0 0 2 6905920 17408 182f12df58 ---P--- 1599044 informix - 0 0 2 6906576 17408 ………………………………………………………………………………………… 182f12df58 B--PR-- 1599044 informix - 19ed5cda0 0 2 7232992 17408 182f12df58 B--PR-- 1599044 informix - 19f61d160 0 2 7233696 17408 Query statistics: ----------------- Table map : ---------------------------- Internal name Table name ---------------------------- t1 p type table rows_prod est_rows rows_scan time est_cost ------------------------------------------------------------------- scan t1 1 71534 552110204 55:12.79 1059 type rows_prod est_rows rows_cons time ------------------------------------------------- group 1 1 1 55:12.79 за каким х.. запрос сканирует всю таблицу rows_scan = 552110204 Как отвадить информикс от этого? Не пойму, почему стало так долго выполняться. Как Вот план его выполнения -- execution plan at /home/informix/sqexplain.out at QUERY: (OPTIMIZATION TIMESTAMP: 06-25-2015 15:04:51) ------ SELECT min (reg_date) FROM plat p WHERE p.reg_paym_dt >= '2015-06-13 00:00:00' AND p.reg_paym_dt <= '2015-06-13 23:59:59' Estimated Cost: 133 Estimated # of Rows Returned: 1 1) informix.p: INDEX PATH Filters: (informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second AND informix.p.reg_paym_dt <= datetime(2015-06-13 23:59:59) year to second ) (1) Index Name: informix.paym__ix_reg_date Index Keys: reg_date (Aggregate) (Serial, fragments: ALL) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2015, 15:47 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Сергей Б, Когда быстро - у вас используется индекс: informix.paym__ix_reg_paym_dt Когда медленно - informix.paym__ix_reg_date. Наверно он битый. Попробуйте хинтом выключить индекс informix.paym__ix_reg_date. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.06.2015, 16:30 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
IkirСергей Б, Когда быстро - у вас используется индекс: informix.paym__ix_reg_paym_dt Когда медленно - informix.paym__ix_reg_date. Наверно он битый . Попробуйте хинтом выключить индекс informix.paym__ix_reg_date. Причём тут битость индекса?! План выполнения оптимизатор выбирает неэффективно. Основных вариантов 3: 1. Статистика такова. что не отражает суровую реальность. И есть вариант, что лучше её не соберёшь. 2. Ой, всё. Независимо от возможности или невозможности решения проблемы со статистикой простым решением является создание индекса reg_paym_dt, reg_date. И прочтите хоть что-то про оптимизацию запросов ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2015, 02:57 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
АнатоЛойОсновных вариантов 3: 1. Статистика такова. что не отражает суровую реальность. И есть вариант, что лучше её не соберёшь. 2. Ой, всё. А сообщение пятая строка сверху вас не смущает? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2015, 08:00 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
IkirАнатоЛойОсновных вариантов 3: 1. Статистика такова. что не отражает суровую реальность. И есть вариант, что лучше её не соберёшь. 2. Ой, всё. А сообщение пятая строка сверху вас не смущает? Нет, не смущает. Потому-что статистика не молот Тора. Статистика помогает оптимизатору выбрать оптимальное решение, но не гарантирует его САМА ПО СЕБЕ. Я написал: "есть вариант", но не утверждал, что 100% в данном случае мы на него наткнулись. Поможет индекс, по двум полям, поможет хинт с указанием выбора нужого индекса или указаним игнорирования ненужного индекса. А ещё поможет понимание, что оптимизатор для каждого запроса получает (не всегда отображаеиое явно в плане, к сожалению) цель запроса: получить все записи или пользователю достаточно первой. И у меня ошушение, что настройки сервера или сессии в последнем запросе указывают на получение первой записи. Вот оптимизатор с текущей статистикой и ошибается..... Так что помочь должно ещё указание оптимизации ALL_ROWS или выгрузка INTO TEMP :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2015, 11:41 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Сергей БЕще раз спасибо. БД без RSS,HDR,SDS. Часто используемый запрос стал выполняться очень долго. Так в итоге проблемный индекс перестроили ? А его битую версию прибили ? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2015, 23:07 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
АнатоЛойПоможет индекс, по двум полям, поможет хинт с указанием выбора нужого индекса или указаним игнорирования ненужного индекса. Согласен. Первый вариант затратный, но скорее всего и более оптимальный будет с точки зрения быстродействия. Второй вариант НЕ затратный, пригоден для экспериментов прямо сейчас, но и скорее всего менее оптимальный. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2015, 19:46 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Спасибо за советы. Извините, что так долго не отвечал, база большая. Все делается долго. Сейчас временно запросы делаются через темповые таблицы На текущий момент провожу эксперименты на тестовой базе, плюс параллельно на бою . Бой Отключил индекс по полю. Время выполнения запроса менее секунды Код: sql 1.
Бэкап (виртуалка) На бэкапе (на ругань про ISAM error: no free disk space for sort пока не обращаю внимания) Смотрю индексы paym__ix_reg_date, paym__ix_reg_paym_dt. Они не «битые» Запустил на выходные oncheck -cI ok_arch:plat Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Код: sql 1. 2. 3. 4. 5. 6. 7.
QUERY: (OPTIMIZATION TIMESTAMP: 06-29-2015 13:33:18) ------ Код: sql 1. 2. 3. 4. 5. 6. 7.
Estimated Cost: 4 Estimated # of Rows Returned: 1 1) informix.p: INDEX PATH Filters: ((informix.p.recv_code IN (110 , 101 , 510 , 810 , 403 , 72101 , 11101 )AND informix.p.pm_state = 3 ) AND informix.p.paym_ord > 0 ) (1) Index Name: informix.paym__ix_reg_paym_dt Index Keys: reg_paym_dt (Serial, fragments: ALL) Lower Index Filter: informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second Upper Index Filter: informix.p.reg_paym_dt <= datetime(2015-06-13 23:59:59) year to second Query statistics: ----------------- Table map : ---------------------------- Internal name Table name ---------------------------- t1 p type table rows_prod est_rows rows_scan ti me est_cost ------------------------------------------------------------------- scan t1 81901 1 464778 00:09.44 5 type rows_prod est_rows rows_cons time ------------------------------------------------- group 1 1 81901 00:09.53 Создал индекс (не убивая старого, время создания 8 часов) create index paym__ix_reg_paym_dt_n on .plat (reg_paym_dt desc) online; Код: sql 1. 2. 3. 4. 5. 6. 7.
QUERY: (OPTIMIZATION TIMESTAMP: 06-29-2015 08:32:11) ------ SELECT min(p.reg_date) FROM plat p WHERE p.reg_paym_dt >= '2015-06-13 00:00:00' AND p.reg_paym_dt <= '2015-06-13 23:59:59' AND p.recv_code in (110,101,510,810,403,72101,11101) AND p.pm_state = 3 AND p.paym_ord > 0 Estimated Cost: 3 Estimated # of Rows Returned: 1 1) informix.p: INDEX PATH Filters: ((informix.p.recv_code IN (110 , 101 , 510 , 810 , 403 , 72101 , 11101 )AND informix.p.pm_state = 3 ) AND informix.p.paym_ord > 0 ) (1) Index Name: informix.paym__ix_reg_paym_dt_n Index Keys: reg_paym_dt (desc) (Serial, fragments: ALL) Lower Index Filter: informix.p.reg_paym_dt <= datetime(2015-06-13 23:59:59) year to second Upper Index Filter: informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second Query statistics: ----------------- Table map : ---------------------------- Internal name Table name ---------------------------- t1 p type table rows_prod est_rows rows_scan time est_cost ------------------------------------------------------------------- scan t1 81901 1 464778 00:23.71 4 type rows_prod est_rows rows_cons time ------------------------------------------------- group 1 1 81901 00:23.85 Запрос отработал за 23.85 секунды, по старому индексу работает 09.53. Пока никаких мыслей, что делать с таблицей на бою. Напоминаю, как временный вариант, сейчас запрос работает через временную таблицу ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2015, 13:53 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Сергей Б, надеюсь вы в курсе что время не всегда идеальный показатель производительности. Возможно что индекс по двум полям пока не был востребован, и грузился с диска для вашего запроса, а для индекса по одному полю уже находился в памяти... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2015, 01:54 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
АнатоЛойСергей Б, надеюсь вы в курсе что время не всегда идеальный показатель производительности. Возможно что индекс по двум полям пока не был востребован, и грузился с диска для вашего запроса, а для индекса по одному полю уже находился в памяти... 1. Пардон, был недостаточно внимателен. Вышесказанное относится к индексу reg_paym_dt ASC и reg_paym_dt DESC. 2. По поводу моего совета с индексом по (reg_paym_dt, reg_date) забейте, я был неправ - для вашего запроса c фильтрами он не поможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2015, 10:29 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Еще раз спасибо за ответы. АнатоЛой, это запрос работал раньше очень быстро. Мне показали логи, выполнявшие этот запрос и ранее. Просто в какой-то момент времени (пару недель назад, начал «дурить» запрос. На эмоциях я и создал тему, что полетел индекс. После восстановления бэкапа на тестовой среде (виртуалка) оказалось, что А) индексы не битые (сейчас проверяю индексы varchar (255,16) когда выдавалось сообщениеno free disk space for sort) Б) в трейсе на обоих серверах выборка идет по одному и тому же индексу (только на бою работает около часа, а на тестовом сервере пару минут) В) update statistics high - не помог Из-за чего это произошло – пока не понятно. И как "вылечить" это тоже ясности нет. Дня через 3 попробую содать индекс как советовал Павел (запрос не массовый). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2015, 11:19 |
|
Сыпанулся индекс на фрагментированной таблице
|
|||
---|---|---|---|
#18+
Сергей Б, как минимум на боевой другая нагрузка, степень загруженности дисков и памяти и степень разнообразности запросов. Проблема на боевом может быть не в этом запросе, он мог и не измениться. Просто выросла нагрузка в другом месте или появилась новая, а именно этот запрос оказался на границе своей производительности и первым обратил на себя внимание. Сравните общую производительности сервера раньше и сейчас. Смотрите в статистике запросов и сравнивайте dskreads и bufreads. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2015, 16:06 |
|
|
start [/forum/topic.php?fid=44&msg=38991546&tid=1606855]: |
0ms |
get settings: |
16ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
34ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
392ms |
get tp. blocked users: |
1ms |
others: | 361ms |
total: | 817ms |
0 / 0 |