ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Unix-системы [игнор отключен] [закрыт для гостей] / Нагрузочный тест дисковой системы
48 сообщений из 48, показаны все 2 страниц
  все  
Нагрузочный тест дисковой системы
    #36333273
receiver
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
receiver
Участник
Я администратор Oracle. Имею подозрения, что низкая производительность базы данных связана с низкой производительностью на запись дисковой стойки.
Время выполнения копирования 4Гб файла на этой стойке больше, чем на другой, подобной.
2,5 минуты против 1,5. Но наверняка есть какие-то тестовые программы, которые дают четкий ответ о производительности дисков.

Где взять?!
...
Рейтинг: 0 / 0
26.11.2009, 12:50
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36333552
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
receiver,

iometer, iozone, bonnie++

покажите sar -d 2 10
и select * from AUX_STATS$;
...
Рейтинг: 0 / 0
26.11.2009, 13:51
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36333555
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
receiver
Время выполнения копирования 4Гб файла на этой стойке больше, чем на другой, подобной.
оракле кстати файлы не копирует. Ему random read нужен.
...
Рейтинг: 0 / 0
26.11.2009, 13:53
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36333627
Фотография Adekamer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Adekamer
Участник
hdparm -t
...
Рейтинг: 0 / 0
26.11.2009, 14:10
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36333678
Dkfl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dkfl
Участник
Тут посмотри
...
Рейтинг: 0 / 0
26.11.2009, 14:20
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36333797
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
Денис, запрос вот

SQL> select * from AUX_STATS$;

SNAME PNAME PVAL1 PVAL2
------------------------------ ------------------------------ ---------- -----------------
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 12-25-2007 18:57
SYSSTATS_INFO DSTOP 12-25-2007 18:57
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 779.906
SYSSTATS_MAIN IOSEEKTIM 5.491
SYSSTATS_MAIN IOTFRSPEED 3019.889
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR


А с программами iometer, iozone, hdparam, bonie+ и т.д. где искать? Пути к ним не установлены.
Даже в sar я не вижу исполняемых файлов

bash-3.00$ ls -l /var/adm/sa/
total 30
-rw-r--r-- 1 root root 14184 Jul 11 2007 sa11
-rw-r--r-- 1 root root 101 Jul 11 2007 sar11

Дистрибутивов нет, да и устанавливать я не умею.


> оракле кстати файлы не копирует. Ему random read нужен.
Не совсем понимаю. Я вижу в событиях ожидания среднее время записи > 1000 ms.
Кажется, это больше, чем много.
Ищу, почему.
...
Рейтинг: 0 / 0
26.11.2009, 14:50
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36334039
kvasandrew
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kvasandrew
Участник
iostat -xznM
...
Рейтинг: 0 / 0
26.11.2009, 16:22
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36334339
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
Оператор insert into test.test (select * from test.coep_test where rownum < 200000);
отрабатывал полторы минуты и за это время iostat -xnzM 5 30 записал такие значения (см. файл)

Кто-нибудь скажет, что здесь "много"?
...
Рейтинг: 0 / 0
26.11.2009, 18:30
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36334377
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
receiver,

Сколько винтов в этой "дисковой стойке", как сконфигурены массивы ?
...
Рейтинг: 0 / 0
26.11.2009, 18:56
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36334402
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
Вот такую строчку мне прислал ихний администратор

автор
Для остальных систем используется одна полка
Sun StorEdge 3510 FC Array Rack Ready, 12 * 146GB 10Krpm, 5 raid


От себя скажу, что система тестовая, совершенно не нагруженная в обычном режиме.

Но копирование данных одного завода в другой (в Oracle) занимает 6 суток против 10 часов
на других серверах. Причем у некоторых серверов данные на стойках, у других на внутренних дисках. И все равно время выполнения < 12 часов.
А эти висят и висят.

Я сделал тестовую табличку. Вставляю туда 20000 записей. Время ~ 2 минуты
На других серверах ~ 5 секунд.
...
Рейтинг: 0 / 0
26.11.2009, 19:17
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36335195
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
expimp,

Массив старенький (это DotHill SANnet II, модельке лет 5-6 уже, если не больше), особой производительностью на нагрузках типа последовательный доступ большими блоками он и впрямь не отличается.
Но у Вас-то задача - не копирование файлов, насколько я понимаю.
Погоняйте типовые для Вашей базы запросы (не один и тот же много раз подряд), и покажите iostat.
...
Рейтинг: 0 / 0
27.11.2009, 11:17
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36335242
Взгляд со стороны
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Взгляд со стороны
Гость
Вот это:receiverЯ администратор Oracle. крайне слабо вяжется со всем остальнымreceiverИмею подозрения, что низкая производительность базы данных связана с низкой производительностью на запись дисковой стойки.
Время выполнения копирования 4Гб файла на этой стойке больше, чем на другой, подобной.
2,5 минуты против 1,5. Но наверняка есть какие-то тестовые программы, которые дают четкий ответ о производительности дисков.

Где взять?!

Т.е. фраза звучит примерно как:

"Я водитель дальнобойщик, но имею подозрения, что в грузовике руль нужно крутить руками.
Пробую крутить - крутится очень туго, что я делаю не так?
Кстати, и не подскажите, где тут педаль газа, или как там ее зовут"

---

Все это очень печально, конечно. Кушать то "администратору" поди тоже хочется, это понятно.
...
Рейтинг: 0 / 0
27.11.2009, 11:32
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36336004
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
Зачем так много писать? Прорабатываете книжку "Метод слепой десятипальцевой печати"?

Вопрос то простой был - какой программой можно получить удобочитаемые данные о производительности дисковой системы. И сравнить эти данные с парой других массивов.
...
Рейтинг: 0 / 0
27.11.2009, 15:24
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36336154
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
expimp,

Собрать данные - iostat
Протестировать производительность - iometer, iozone : но нужно правильно указать паттерн нагрузки.
...
Рейтинг: 0 / 0
27.11.2009, 16:18
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36336224
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Салограмотные "оптимизаторы" - залог высокой оплаты консалтерам при последующем восстановлении данных
...
Рейтинг: 0 / 0
27.11.2009, 16:48
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36336579
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
expimp

Но копирование данных одного завода в другой (в Oracle) занимает 6 суток против 10 часов
на других серверах. Причем у некоторых серверов данные на стойках, у других на внутренних дисках. И все равно время выполнения < 12 часов.
А эти висят и висят.




1. Вы про Oracle ASM не забыли нам сказать, или его там нет ?
2. В раиде все диски целые ?
3. Всегда так было или после каких то действий поплохело ? Каких ?
...
Рейтинг: 0 / 0
27.11.2009, 20:17
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36336600
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
expimpОператор insert into test.test (select * from test.coep_test where rownum < 200000);
отрабатывал полторы минуты и за это время iostat -xnzM 5 30 записал такие значения (см. файл)

Кто-нибудь скажет, что здесь "много"?


Тут всего мало , кроме disk is busy :)

ИМХО похоже что проблема на хосте, а не на сторадже.
При проблемах на сторадже ожидания wsvc_t asvc_t должны быть больше.
...
Рейтинг: 0 / 0
27.11.2009, 20:53
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36336607
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Relic Hunter
Участник
receiver,

Текс...
можно посмотреть на обеих системах?

1. unix - /etc/vfstab - на предмет forcedirectio
2. oracle - filesystemio_options, db_file_multiblock_read_count

Thanx!!!
...
Рейтинг: 0 / 0
27.11.2009, 21:14
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36336629
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
Relic Hunterreceiver,

Текс...
можно посмотреть на обеих системах?

1. unix - /etc/vfstab - на предмет forcedirectio
2. oracle - filesystemio_options, db_file_multiblock_read_count

Thanx!!!

+1

И еще ИМХО .
В статистике одноблочные рандомные записи, если блок базы 8 к.
Процессор дискового контроллера просто зашиватется на пересчете контрольных сумм страйпов, особенно если они длинные.
Изменяется только 8к, а пересчитать контрольную сумму нужно для всего длинного страйпа.
Подозреваю, что системы которые сравниваются могут иметь очень разный
размер страйпа в раидах, при слабом контроллере и маленьком кеше.

в поддержку предыдущей версии , что проблема на хосте:
Но насколько я понимаю время потраченное на
пересчет страйпов должно увеличить значения wsvc_t asvc_t.
Еще настораживает маленький wait ( длина очереди на ввод вывод) .
...
Рейтинг: 0 / 0
27.11.2009, 21:51
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36336899
Взгляд со стороны
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Взгляд со стороны
Гость
expimpЗачем так много писать? Прорабатываете книжку "Метод слепой десятипальцевой печати"?

Вопрос то простой был - какой программой можно получить удобочитаемые данные о производительности дисковой системы. И сравнить эти данные с парой других массивов.

Ну здравствуй, еще один "одминестратор".

Может быть ты нам расскажешь, каким это образом с помощью утилит тестирования синтетической пропускной
способности ты диагностируешь причину, почему это две одинаковые (подобные?) железки
дают разные такие себе результаты?

Еще раз, для тех, кому с первого раза туго доходит - факт проблемы уже якобы установлен,
вопрос - в чем причина?

Еще раз. Третий. В чем ПРИЧИНА низкой производительности?
...
Рейтинг: 0 / 0
28.11.2009, 12:11
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36336947
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nik_x
Участник
Взгляд со стороны,

> Еще раз. Третий. В чем ПРИЧИНА низкой производительности?

В чем? ПРИЧИНА. ... Нащальника:)
...
Рейтинг: 0 / 0
28.11.2009, 14:20
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36338602
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
Нашел топик, один к одному с нашими проблемами.
Говорят, проблема была в отключеном кэше на стойке.
Еще раз задал вопрос нашим заказчикам, включен ли кэш у них.
Жду ответа.
...
Рейтинг: 0 / 0
30.11.2009, 12:23
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36338663
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
Ответили, "Write-back cash на сторидже включен."

Кто подскажет, это все, чем можно управлять кэшем, или еще что-то может быть выключено?
...
Рейтинг: 0 / 0
30.11.2009, 12:43
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36338806
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
expimpОтветили, "Write-back cash на сторидже включен."

Кто подскажет, это все, чем можно управлять кэшем, или еще что-то может быть выключено ?


IMHO глобально выключено кеширование на чтении RTFM
...
Рейтинг: 0 / 0
30.11.2009, 13:28
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36339066
Мутаген
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мутаген
Гость
Покажите нам вывод команды egrep -v '^(\*|$)' /etc/system с сервера.

directio там включён. В соседнем топике был показан statspack, там в pfile было видно что filesystemio_options был выставлен как надо: в setall.
...
Рейтинг: 0 / 0
30.11.2009, 14:47
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36340606
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
expimp,

Может быть выключено кэширование на чтение
Может быть выбрана не подходящая политика кэширования чтения
Может быть выбран неподходящий к задаче stripe size на массиве
Дофига, в общем, может чего быть.
Но внятных аргументов того, что массив тормозит на основной его задаче, я тут так и не увидел.
...
Рейтинг: 0 / 0
01.12.2009, 11:27
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36340862
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
МутагенПокажите нам вывод команды egrep -v '^(\*|$)' /etc/system с сервера.

directio там включён. В соседнем топике был показан statspack, там в pfile было видно что filesystemio_options был выставлен как надо: в setall.


root@SF440DEV # egrep -v '^(\*|$)' /etc/system
set rlim_fd_cur=8192
set noexec_user_stack=1
rootdev:/pseudo/md@0:0,0,blk
...
Рейтинг: 0 / 0
01.12.2009, 12:43
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36340871
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
onstat-expimp

Но копирование данных одного завода в другой (в Oracle) занимает 6 суток против 10 часов
на других серверах. Причем у некоторых серверов данные на стойках, у других на внутренних дисках. И все равно время выполнения < 12 часов.
А эти висят и висят.




1. Вы про Oracle ASM не забыли нам сказать, или его там нет ?
2. В раиде все диски целые ?
3. Всегда так было или после каких то действий поплохело ? Каких ?

ASM'а нет. Диски целые. Батарейки заряжены. А плохо было всегда.
И товарищи уже года три сутками ждут выполнения своих задач. : (
...
Рейтинг: 0 / 0
01.12.2009, 12:45
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36340976
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
expimp,

По опубликованному Вами iostat.txt - дело было не в машине (с). Там никакой нагрузки на дисковую подсистему вообще незаметно.
Потому - надо iostat под нагрузкой.
...
Рейтинг: 0 / 0
01.12.2009, 13:16
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36341189
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
a_shatsexpimp,

Может быть выключено кэширование на чтение
Может быть выбрана не подходящая политика кэширования чтения
Может быть выбран неподходящий к задаче stripe size на массиве
Дофига, в общем, может чего быть.
Но внятных аргументов того, что массив тормозит на основной его задаче, я тут так и не увидел.

Читает "оно" нормально.

> Но внятных аргументов того, что массив тормозит на основной его задаче

В приложенном файле средние времена ожидания на запись для процессов DBWR и LGWR.
Я думаю, что это очень много.
...
Рейтинг: 0 / 0
01.12.2009, 14:25
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36341298
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
a_shatsexpimp,

По опубликованному Вами iostat.txt - дело было не в машине (с). Там никакой нагрузки на дисковую подсистему вообще незаметно.
Потому - надо iostat под нагрузкой.

Вот три минуты выполнялся оператор, который должен выполняться ~ 3-5 сек.

SQL> insert into test.test (select * from test.coep_test where rownum < 200000);

199999 rows created.
Elapsed: 00:03:00.32

И вот iostat -xM 5 50
...
Рейтинг: 0 / 0
01.12.2009, 15:03
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36341428
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
expimp,

Чуть более предметно. Видно, что наибольшая просадка - на записи лога.
Могу ошибаться, но подозреваю, что дело в RAID5: контроллер очень уж старенький, по нынешним временам - и слабенький. Было б RAID10 - было б полегче.
Ну или кто-то ошибается на предмет того, где лежит лог...
...
Рейтинг: 0 / 0
01.12.2009, 16:01
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36341432
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
expimpa_shatsexpimp,

По опубликованному Вами iostat.txt - дело было не в машине (с). Там никакой нагрузки на дисковую подсистему вообще незаметно.
Потому - надо iostat под нагрузкой.

Вот три минуты выполнялся оператор, который должен выполняться ~ 3-5 сек.

SQL> insert into test.test (select * from test.coep_test where rownum < 200000);

199999 rows created.
Elapsed: 00:03:00.32

И вот iostat -xM 5 50
а покажите
SQL> set autotrace on
SQL> insert into test.test (select * from test.coep_test where rownum < 200000);

или еще лучше
SQL> alter session set events '10046 trace name context forever, level 12';
SQL> insert into test.test (select * from test.coep_test where rownum < 200000);
SQL> disc
а файлик из udump выложите нам.
...
Рейтинг: 0 / 0
01.12.2009, 16:03
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36341557
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
Код: 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.
insert into test.test (select * from test.coep_test where rownum < 200000)

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.01          0          1          0           0
Execute      1      4.69     175.75        475      26523      86370      199999
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      4.69     175.76        475      26524      86370      199999

Rows     Row Source Operation
-------  ---------------------------------------------------
 199999  COUNT STOPKEY (cr=9598 pr=473 pw=0 time=1600200 us)
 199999   TABLE ACCESS FULL COEP_TEST (cr=9598 pr=473 pw=0 time=801073 us)

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential read                       312        0.00          0.13
  log buffer space                              168        0.98        155.16
  db file scattered read                          6        0.17          0.25
  buffer busy waits                               1        0.00          0.00
  log file switch completion                     18        0.98         15.66
  latch: cache buffers chains                     1        0.00          0.00
  SQL*Net message to client                       1        0.00          0.00
  SQL*Net message from client                     1        0.00          0.00
********************************************************************************

Уже три дня смотрю в трассировки с разным объемом redo size.
Если вставлять только 10000 записей, то пролетает мгновенно.
Но следующий оператор commit; опять приводит к крайне медленному log file parallel write
и, как следствие, к log buffer space.
...
Рейтинг: 0 / 0
01.12.2009, 16:42
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36341606
Фотография hell
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hell
Участник
http://www.oracle.com/technology/software/tech/orion/index.html


дааа, я вижу SAP идет в массы....

__________________
For more information, please proceed to http://ot-e.biz
...
Рейтинг: 0 / 0
01.12.2009, 16:59
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36341998
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
expimp
onstat-

1. Вы про Oracle ASM не забыли нам сказать, или его там нет ?
2. В раиде все диски целые ?
3. Всегда так было или после каких то действий поплохело ? Каких ?

ASM\'а нет. Диски целые. Батарейки заряжены. А плохо было всегда.
И товарищи уже года три сутками ждут выполнения своих задач. : (

Тут задавалисьнекоторые вопросы , ответьте на них пож.


Предоставьте результат паралельного выполнения
iostat -xM 5 50
vmstat 5 50
под нагрузкой.
...
Рейтинг: 0 / 0
01.12.2009, 20:04
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36342172
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
expimp
Код: plaintext
1.
2.
insert into test.test (select * from test.coep_test where rownum < 200000)
call     count       cpu    elapsed       disk      query    current        rows
Ну нафига нам идиотский вывод ткпроф. orasrp что-либ парсил уж тогда. Реальное время сколько было? Может там в своппингом полчаса занимались.

"log buffer space" или наверчено с параметром log_buffer или _log_io_size
т.е. show parameter log_buffer
или копия редо логов пишется например на внутренний "убитый" диск или лограйтер просто передает их на стендбай (а может там maximum protection), в общем кусок алертлога нужен, трассировка лограйтеров trace-м.
...
Рейтинг: 0 / 0
01.12.2009, 22:57
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36343555
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
vi /etc/vfstab
--------------
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
#device         device          mount           FS      fsck    mount   mount
#to mount       to fsck         point           type    pass    at boot options
#
fd      -       /dev/fd fd      -       no      -
/proc   -       /proc   proc    -       no      -
/dev/md/dsk/d1  -       -       swap    -       no      -
/dev/md/dsk/d0  /dev/md/rdsk/d0 /       ufs     1       no      -
/dev/md/dsk/d2  /dev/md/rdsk/d2 /var    ufs     1       no      -
/dev/dsk/c3t256000C0FFCB19FBd1s6 /dev/rdsk/c3t256000C0FFCB19FBd1s6      /oracle ufs     1       yes     -
/dev/md/dsk/d3  /dev/md/rdsk/d3 /sandisk        ufs     1       yes     -
/devices        -       /devices        devfs   -       no      -
ctfs    -       /system/contract        ctfs    -       no      -
objfs   -       /system/object  objfs   -       no      -
swap    -       /tmp    tmpfs   -       yes     -
10.1.103.41:/usr/sap/trans      -       /usr/sap/trans  nfs     -       yes     -
#10.1.103.41:/distr/SM4 -       /distr/SM4      nfs     -       yes     -
----------------------------------------------------------------------------
Код: plaintext
1.
2.
3.
4.
5.
SQL> show parameter filesystemio_options
filesystemio_options                 string      setall

SQL> show parameter db_file_multiblock_read_count
db_file_multiblock_read_count        integer     128
...
Рейтинг: 0 / 0
02.12.2009, 15:03
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36343923
expimp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expimp
Участник
Журавлев Денисexpimp
Код: plaintext
1.
2.
insert into test.test (select * from test.coep_test where rownum < 200000)
call     count       cpu    elapsed       disk      query    current        rows
Ну нафига нам идиотский вывод ткпроф. orasrp что-либ парсил уж тогда. Реальное время сколько было? Может там в своппингом полчаса занимались.

"log buffer space" или наверчено с параметром log_buffer или _log_io_size
т.е. show parameter log_buffer
или копия редо логов пишется например на внутренний "убитый" диск или лограйтер просто передает их на стендбай (а может там maximum protection), в общем кусок алертлога нужен, трассировка лограйтеров trace-м.

log_buffer integer 14282752 - по умолчанию для 10g

Пробовал менять _log_io_size от 64 до 6000. Результат = 0.
Удалил из ini-файла. Теперь стоит по умолчанию.

Вместе с insert into ... включил трассировку LGWR.

...
...
Код: 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.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
WAIT #0: nam='rdbms ipc message' ela= 1948611 timeout=199 p2=0 p3=0 obj#=-1 tim=1528351210980
WAIT #0: nam='rdbms ipc message' ela= 2939090 timeout=300 p2=0 p3=0 obj#=-1 tim=1528354150462
WAIT #0: nam='rdbms ipc message' ela= 2565431 timeout=300 p2=0 p3=0 obj#=-1 tim=1528356716060
WAIT #0: nam='log file parallel write' ela= 1828202 files=1 blocks=2056 requests=2 obj#=-1 tim=1528358547872
WAIT #0: nam='log file parallel write' ela= 9624630 files=1 blocks=11888 requests=6 obj#=-1 tim=1528368193276
WAIT #0: nam='log file parallel write' ela= 1312425 files=1 blocks=2057 requests=2 obj#=-1 tim=1528369526569
WAIT #0: nam='LGWR wait for redo copy' ela= 4 copy latch #=0 p2=0 p3=0 obj#=-1 tim=1528369530128
WAIT #0: nam='log file parallel write' ela= 8189920 files=1 blocks=11899 requests=6 obj#=-1 tim=1528377737422
WAIT #0: nam='LGWR wait for redo copy' ela= 8 copy latch #=0 p2=0 p3=0 obj#=-1 tim=1528377754558
WAIT #0: nam='log file parallel write' ela= 1355781 files=1 blocks=2051 requests=2 obj#=-1 tim=1528379113925
WAIT #0: nam='LGWR wait for redo copy' ela= 2 copy latch #=0 p2=0 p3=0 obj#=-1 tim=1528379117741
WAIT #0: nam='log file parallel write' ela= 8034609 files=1 blocks=11899 requests=6 obj#=-1 tim=1528387173542
WAIT #0: nam='log file parallel write' ela= 1411053 files=1 blocks=2044 requests=2 obj#=-1 tim=1528388609162
WAIT #0: nam='LGWR wait for redo copy' ela= 5 copy latch #=0 p2=0 p3=0 obj#=-1 tim=1528388612997
WAIT #0: nam='log file parallel write' ela= 8147296 files=1 blocks=11909 requests=6 obj#=-1 tim=1528396782734
WAIT #0: nam='log file parallel write' ela= 1255904 files=1 blocks=2037 requests=2 obj#=-1 tim=1528398059119
WAIT #0: nam='LGWR wait for redo copy' ela= 3 copy latch #=0 p2=0 p3=0 obj#=-1 tim=1528398062959
WAIT #0: nam='log file parallel write' ela= 8122988 files=1 blocks=11910 requests=6 obj#=-1 tim=1528406208480
WAIT #0: nam='log file parallel write' ela= 1479168 files=1 blocks=2048 requests=2 obj#=-1 tim=1528407712308
WAIT #0: nam='log file parallel write' ela= 8052079 files=1 blocks=11887 requests=6 obj#=-1 tim=1528415790736
WAIT #0: nam='log file parallel write' ela= 1348490 files=1 blocks=2055 requests=2 obj#=-1 tim=1528417159852
WAIT #0: nam='LGWR wait for redo copy' ela= 5 copy latch #=0 p2=0 p3=0 obj#=-1 tim=1528417163398
WAIT #0: nam='log file parallel write' ela= 8012516 files=1 blocks=11896 requests=6 obj#=-1 tim=1528425194481
WAIT #0: nam='log file parallel write' ela= 10259148 files=1 blocks=15040 requests=9 obj#=-1 tim=1528435501460
WAIT #0: nam='log file parallel write' ela= 10950 files=1 blocks=5 requests=1 obj#=-1 tim=1528435540560
WAIT #0: nam='control file sequential read' ela= 88 file#=0 block#=1 blocks=1 obj#=-1 tim=1528435541157
WAIT #0: nam='control file sequential read' ela= 53 file#=1 block#=1 blocks=1 obj#=-1 tim=1528435541319
WAIT #0: nam='control file sequential read' ela= 42 file#=2 block#=1 blocks=1 obj#=-1 tim=1528435541447
WAIT #0: nam='control file sequential read' ela= 45 file#=0 block#=58 blocks=1 obj#=-1 tim=1528435541578
WAIT #0: nam='control file sequential read' ela= 37 file#=0 block#=60 blocks=1 obj#=-1 tim=1528435541700
WAIT #0: nam='control file sequential read' ela= 54 file#=0 block#=61 blocks=1 obj#=-1 tim=1528435541851
WAIT #0: nam='control file sequential read' ela= 52 file#=0 block#=64 blocks=1 obj#=-1 tim=1528435541981
WAIT #0: nam='control file parallel write' ela= 36621 files=3 block#=63 requests=3 obj#=-1 tim=1528435578794
WAIT #0: nam='control file parallel write' ela= 25498 files=3 block#=59 requests=3 obj#=-1 tim=1528435604483
WAIT #0: nam='control file parallel write' ela= 29919 files=3 block#=57 requests=3 obj#=-1 tim=1528435634633
WAIT #0: nam='control file parallel write' ela= 30151 files=3 block#=1 requests=3 obj#=-1 tim=1528435665012
WAIT #0: nam='log file parallel write' ela= 11664 files=1 blocks=4 requests=1 obj#=-1 tim=1528435676872
WAIT #0: nam='log file sequential read' ela= 63 log#=0 block#=1 blocks=1 obj#=-1 tim=1528435677051
WAIT #0: nam='control file sequential read' ela= 60 file#=0 block#=81 blocks=1 obj#=-1 tim=1528435677154
WAIT #0: nam='log file single write' ela= 13966 log#=0 block#=1 blocks=1 obj#=-1 tim=1528435691227
WAIT #0: nam='log file sequential read' ela= 19 log#=0 block#=1 blocks=1 obj#=-1 tim=1528435691338
WAIT #0: nam='log file single write' ela= 17661 log#=0 block#=1 blocks=1 obj#=-1 tim=1528435709035
WAIT #0: nam='control file parallel write' ela= 29795 files=3 block#=64 requests=3 obj#=-1 tim=1528435738921
WAIT #0: nam='control file sequential read' ela= 63 file#=0 block#=618 blocks=1 obj#=-1 tim=1528435739123
WAIT #0: nam='control file sequential read' ela= 74 file#=0 block#=774 blocks=1 obj#=-1 tim=1528435739346
WAIT #0: nam='control file sequential read' ela= 70 file#=0 block#=1103 blocks=1 obj#=-1 tim=1528435739495
WAIT #0: nam='control file sequential read' ela= 39 file#=0 block#=61 blocks=1 obj#=-1 tim=1528435739621
WAIT #0: nam='control file parallel write' ela= 39592 files=3 block#=62 requests=3 obj#=-1 tim=1528435779343
WAIT #0: nam='control file parallel write' ela= 43703 files=3 block#=1104 requests=3 obj#=-1 tim=1528435823238
WAIT #0: nam='control file parallel write' ela= 27046 files=3 block#=60 requests=3 obj#=-1 tim=1528435850473
WAIT #0: nam='control file parallel write' ela= 30204 files=3 block#=58 requests=3 obj#=-1 tim=1528435880817
WAIT #0: nam='control file parallel write' ela= 29244 files=3 block#=1 requests=3 obj#=-1 tim=1528435910209
WAIT #0: nam='control file sequential read' ela= 49 file#=0 block#=64 blocks=1 obj#=-1 tim=1528435910362
WAIT #0: nam='control file sequential read' ela= 74 file#=0 block#=81 blocks=1 obj#=-1 tim=1528435915264
WAIT #0: nam='log file parallel write' ela= 19967 files=1 blocks=14 requests=2 obj#=-1 tim=1528435935750
WAIT #0: nam='log file parallel write' ela= 659844 files=1 blocks=901 requests=2 obj#=-1 tim=1528436597535
WAIT #0: nam='log file parallel write' ela= 8749733 files=1 blocks=13077 requests=9 obj#=-1 tim=1528445373985
WAIT #0: nam='log file parallel write' ela= 673480 files=1 blocks=908 requests=2 obj#=-1 tim=1528446071956
WAIT #0: nam='log file parallel write' ela= 9068211 files=1 blocks=13057 requests=9 obj#=-1 tim=1528455166391
WAIT #0: nam='log file parallel write' ela= 642802 files=1 blocks=924 requests=2 obj#=-1 tim=1528455833982
WAIT #0: nam='log file parallel write' ela= 7204857 files=1 blocks=10782 requests=6 obj#=-1 tim=1528463061198
WAIT #0: nam='log file parallel write' ela= 19679 files=1 blocks=17 requests=1 obj#=-1 tim=1528463099969
WAIT #0: nam='rdbms ipc message' ela= 4 timeout=300 p2=0 p3=0 obj#=-1 tim=1528463100196
WAIT #0: nam='rdbms ipc message' ela= 11487 timeout=300 p2=0 p3=0 obj#=-1 tim=1528463111736
WAIT #0: nam='log file parallel write' ela= 7922 files=1 blocks=8 requests=1 obj#=-1 tim=1528463119827
WAIT #0: nam='log file parallel write' ela= 23426 files=1 blocks=10 requests=1 obj#=-1 tim=1528463143405
WAIT #0: nam='log file parallel write' ela= 9210 files=1 blocks=2 requests=1 obj#=-1 tim=1528463152816
WAIT #0: nam='log file parallel write' ela= 17539 files=1 blocks=13 requests=1 obj#=-1 tim=1528463170477
WAIT #0: nam='rdbms ipc message' ela= 6 timeout=293 p2=0 p3=0 obj#=-1 tim=1528463170636
WAIT #0: nam='rdbms ipc message' ela= 909 timeout=293 p2=0 p3=0 obj#=-1 tim=1528463171583
WAIT #0: nam='log file parallel write' ela= 10608 files=1 blocks=10 requests=1 obj#=-1 tim=1528463182336
WAIT #0: nam='log file parallel write' ela= 19544 files=1 blocks=14 requests=1 obj#=-1 tim=1528463202105
WAIT #0: nam='rdbms ipc message' ela= 4 timeout=290 p2=0 p3=0 obj#=-1 tim=1528463202209
WAIT #0: nam='rdbms ipc message' ela= 2664 timeout=290 p2=0 p3=0 obj#=-1 tim=1528463205068
WAIT #0: nam='log file parallel write' ela= 18096 files=1 blocks=8 requests=1 obj#=-1 tim=1528463223375
WAIT #0: nam='rdbms ipc message' ela= 2811717 timeout=287 p2=0 p3=0 obj#=-1 tim=1528466035202
WAIT #0: nam='rdbms ipc message' ela= 559701 timeout=300 p2=0 p3=0 obj#=-1 tim=1528466595219
WAIT #0: nam='log file parallel write' ela= 15785 files=1 blocks=8 requests=1 obj#=-1 tim=1528466611259
WAIT #0: nam='rdbms ipc message' ela= 12214 timeout=241 p2=0 p3=0 obj#=-1 tim=1528466623562
WAIT #0: nam='log file parallel write' ela= 10920 files=1 blocks=2 requests=1 obj#=-1 tim=1528466634551
WAIT #0: nam='rdbms ipc message' ela= 4649 timeout=239 p2=0 p3=0 obj#=-1 tim=1528466639263
WAIT #0: nam='log file parallel write' ela= 9821 files=1 blocks=2 requests=1 obj#=-1 tim=1528466649142
WAIT #0: nam='log file parallel write' ela= 23427 files=1 blocks=5 requests=1 obj#=-1 tim=1528466672641
WAIT #0: nam='rdbms ipc message' ela= 2 timeout=235 p2=0 p3=0 obj#=-1 tim=1528466672757
WAIT #0: nam='rdbms ipc message' ela= 2301875 timeout=235 p2=0 p3=0 obj#=-1 tim=1528468974677
WAIT #0: nam='rdbms ipc message' ela= 2939239 timeout=300 p2=0 p3=0 obj#=-1 tim=1528471914104
WAIT #0: nam='log file parallel write' ela= 11389 files=1 blocks=1 requests=1 obj#=-1 tim=1528471925700
WAIT #0: nam='rdbms ipc message' ela= 2937542 timeout=300 p2=0 p3=0 obj#=-1 tim=1528474863326
WAIT #0: nam='rdbms ipc message' ela= 2939303 timeout=300 p2=0 p3=0 obj#=-1 tim=1528477802788
WAIT #0: nam='rdbms ipc message' ela= 506060 timeout=300 p2=0 p3=0 obj#=-1 tim=1528478309049
...
...
...
Рейтинг: 0 / 0
02.12.2009, 16:20
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36344554
kvasandrew
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kvasandrew
Участник
Ну расскажите сейчас :)
3510 самая путевая полка. Нужно просто уметь ее готовить :) Если напишите модель что побьет ее по производительности(под redolog) тут ребята(может в разделе Oracle обитают еще) сразу приз вручат :)

Сначала определите что у вас тормозит: погоняйте dd на полке, с разными block size, на чтение/запись. И iostat смотрите.
Если проблема в полке крутите в сторону stripe size (Random or sequential optimization).
Максимальные значения быстродействия получены были при последней версии прошивки, raid-1, одноконтроллерная конфигурация(в 2х контроллерной много накладных расходов на зеркалирование кэша).
По опыту raid5 тоже должен работать отлично, для большинства задач.
Ну и конечно смотреть на конфигурацию нужно, если она у вас на несколько хостов размазана то тормоза вполне понятны.
...
Рейтинг: 0 / 0
02.12.2009, 20:25
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36344677
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
в общем я бы теперь посмотрел на наличие битых фреймов в san и журнал массива
...
Рейтинг: 0 / 0
02.12.2009, 23:04
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36345361
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
kvasandrewНу расскажите сейчас :)
3510 самая путевая полка. Нужно просто уметь ее готовить :) Если напишите модель что побьет ее по производительности(под redolog) тут ребята(может в разделе Oracle обитают еще) сразу приз вручат :)

Бугага. 5-6 летней давности ящик с Инфортрендовским той же давности контроллером - путевая полка ? Почти любой современный энтри-левел на почти любом типе нагрузки ея порвет, как Тузик грелку. "Почти" - потому что теоретически, сурово упершись, можно найти такой паттерн нагрузки, на котором конкретный массив начального уровня не выиграет у этого.
Ибо - старенькая уж очень.
Модели - выбирайте на вкус: HP MSA 23xx, IBM DS3xxx, DotHill 2730 и выше. Любые с тем же интерфейсом.
...
Рейтинг: 0 / 0
03.12.2009, 11:23
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36345820
kvasandrew
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kvasandrew
Участник
Бугага. 5-6 летней давности ящик с Инфортрендовским той же давности контроллером - путевая полка ? Почти любой современный энтри-левел на почти любом типе нагрузки ея порвет, как Тузик грелку. "Почти" - потому что теоретически, сурово упершись, можно найти такой паттерн нагрузки, на котором конкретный массив начального уровня не выиграет у этого.
Ибо - старенькая уж очень.
Модели - выбирайте на вкус: HP MSA 23xx, IBM DS3xxx, DotHill 2730 и выше. Любые с тем же интерфейсом.[/quot]

Ну старенькая это не аргумент. Я говорю то что своими глазами видел. Не от хорошей жизни на таком старье работали, просто альтернативные варианты не давали нужных результатов (при 10мБ/с asvc_t 0.4-0.6 ms). И ни интегратор ни вендор, с которыми плотно работали, не смогли поставить решение по замене их.(вопрос был не в деньгах). Как вариант рассматривалось фиксирование разделов в кэше здорового массива, но это решение в разы дороже приведенной линейки. А про паттерн нагрузки как и сказал уже redolog-и.
IBMDS3xx те же FC диски 15000 rpm ничего нового там не придумали, Storageteck, HP тоже самое. Кэша побольше, но как показала практика алгоритм работы с ним не самый удачный раз не может такое старье порвать.
...
Рейтинг: 0 / 0
03.12.2009, 13:18
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36345884
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
kvasandrew,

Очень, очень странно. Организовать тестирование на чемнить посовременней можно, если хотите - надо бы только знать, чем и как тестить.
Ну, положим, IBM DS3400, как и прочие LSI-ные продукты, потоки не особенно любит (последовательный доступ большими блоками), и кэш там туповат. Но уж HP23xx (DotHill'ы новые) - у них с этим все в порядке. StorageTek линейка у Sun ныне по большей части тож LSI.

Было бы очень интересно узнать, как и чем тестировали.
...
Рейтинг: 0 / 0
03.12.2009, 13:40
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36345891
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
kvasandrew,

И да, если вопрос не в деньгах - чего было не применить тупо mid-range массивы, они всяко шустрее этого будут ? :)
...
Рейтинг: 0 / 0
03.12.2009, 13:41
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36347047
kvasandrew
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kvasandrew
Участник
a_shats, тестировали в боевых условиях так сказать.
Замена одного из зеркал под Veritas живого раздела на тестируемую полку.
Об абсолютных значениях трудно было судить(как я сказал основной параметр был asvc time при сплошном потоке записи ~10MB), но то что интересовало на графиках Enterprise manager не вооруженным взглядом видно было(Commit).

К сожелению к DotHill доступа не было, хотя у меня на счет него хорошие предчувствия. Если у SUN появится dothill железка может еще потестируют(мультивендорность не сильно приветствуется).

По поводу mid-range тоже не все ясно. HDS high end не давал таких результатов :) (вариант все сунуть в кэш был отвергнут)
...
Рейтинг: 0 / 0
03.12.2009, 20:10
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36347851
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
kvasandrewa_shats, тестировали в боевых условиях так сказать.
Замена одного из зеркал под Veritas живого раздела на тестируемую полку.
Об абсолютных значениях трудно было судить(как я сказал основной параметр был asvc time при сплошном потоке записи ~10MB), но то что интересовало на графиках Enterprise manager не вооруженным взглядом видно было(Commit).

К сожелению к DotHill доступа не было, хотя у меня на счет него хорошие предчувствия. Если у SUN появится dothill железка может еще потестируют(мультивендорность не сильно приветствуется).

По поводу mid-range тоже не все ясно. HDS high end не давал таких результатов :) (вариант все сунуть в кэш был отвергнут)
Понятненько :) Но у Хитачевских AMS-ок -то уж точно с кэшем все в порядке.
Но, я так понимаю, у Вас не стоял вопрос - попробовать других, тестили только то, что у Сана есть :)
...
Рейтинг: 0 / 0
04.12.2009, 11:16
| Ответить | Цитировать | Написать  
Нагрузочный тест дисковой системы
    #36349322
kvasandrew
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kvasandrew
Участник
a_shats,

ну по большому счету да. был, правда, опыт и с IBM но там вся начинка один в один с SUN так что разницы в тестах не было.
...
Рейтинг: 0 / 0
04.12.2009, 19:20
| Ответить | Цитировать | Написать  
48 сообщений из 48, показаны все 2 страниц
  все  
Форумы / Unix-системы [игнор отключен] [закрыт для гостей] / Нагрузочный тест дисковой системы
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=25&tid=1485282]:
 0ms
get settings:
 9ms
get forum list:
 17ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 183ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 98ms
get tp. blocked users:
 1ms
others: 226ms
total:  555ms
созд. / загр.: 555ms
x
x
Закрыть


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