Нагрузочный тест дисковой системы / Unix-системы

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Unix-системы [игнор отключен] [закрыт для гостей] / Нагрузочный тест дисковой системы

23 сообщений из 48, страница 2 из 2

все

Нагрузочный тест дисковой системы

#36340606

a_shats

Участник

Откуда: Москва

Сообщения: 807

Рейтинг: 0 / 0

expimp,

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

...

Рейтинг:

0 / 0

01.12.2009, 11:27

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36340862

expimp

Участник

Сообщения: 573

Рейтинг: 0 / 0

МутагенПокажите нам вывод команды 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

Участник

Сообщения: 573

Рейтинг: 0 / 0

onstat-expimp

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

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

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

...

Рейтинг:

0 / 0

01.12.2009, 12:45

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36340976

a_shats

Участник

Откуда: Москва

Сообщения: 807

Рейтинг: 0 / 0

expimp,

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

...

Рейтинг:

0 / 0

01.12.2009, 13:16

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36341189

expimp

Участник

Сообщения: 573

Рейтинг: 0 / 0

a_shatsexpimp,

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

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

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

В приложенном файле средние времена ожидания на запись для процессов DBWR и LGWR.
Я думаю, что это очень много.

...

Рейтинг:

0 / 0

01.12.2009, 14:25

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36341298

expimp

Участник

Сообщения: 573

Рейтинг: 0 / 0

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

Участник

Откуда: Москва

Сообщения: 807

Рейтинг: 0 / 0

expimp,

Чуть более предметно. Видно, что наибольшая просадка - на записи лога.
Могу ошибаться, но подозреваю, что дело в RAID5: контроллер очень уж старенький, по нынешним временам - и слабенький. Было б RAID10 - было б полегче.
Ну или кто-то ошибается на предмет того, где лежит лог...

...

Рейтинг:

0 / 0

01.12.2009, 16:01

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36341432

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

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

Участник

Сообщения: 573

Рейтинг: 0 / 0

Код: 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

Участник

Сообщения: 2 743

Рейтинг: 0 / 0

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-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

expimp
onstat-

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

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

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

Предоставьте результат паралельного выполнения
iostat -xM 5 50
vmstat 5 50
под нагрузкой.

...

Рейтинг:

0 / 0

01.12.2009, 20:04

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36342172

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

expimp

Код: plaintext

1.
2.

insert into test.test (select * from test.coep_test where rownum < 200000)
call     count       cpu    elapsed       disk      query    current        rows

...

Рейтинг:

0 / 0

01.12.2009, 22:57

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36343555

expimp

Участник

Сообщения: 573

Рейтинг: 0 / 0

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

Участник

Сообщения: 573

Рейтинг: 0 / 0

Журавлев Денис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

Участник

Сообщения: 38

Рейтинг: 0 / 0

Ну расскажите сейчас :)
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

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

в общем я бы теперь посмотрел на наличие битых фреймов в san и журнал массива

...

Рейтинг:

0 / 0

02.12.2009, 23:04

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36345361

a_shats

Участник

Откуда: Москва

Сообщения: 807

Рейтинг: 0 / 0

kvasandrewНу расскажите сейчас :)
3510 самая путевая полка. Нужно просто уметь ее готовить :) Если напишите модель что побьет ее по производительности(под redolog) тут ребята(может в разделе Oracle обитают еще) сразу приз вручат :)

Бугага. 5-6 летней давности ящик с Инфортрендовским той же давности контроллером - путевая полка ? Почти любой современный энтри-левел на почти любом типе нагрузки ея порвет, как Тузик грелку. "Почти" - потому что теоретически, сурово упершись, можно найти такой паттерн нагрузки, на котором конкретный массив начального уровня не выиграет у этого.
Ибо - старенькая уж очень.
Модели - выбирайте на вкус: HP MSA 23xx, IBM DS3xxx, DotHill 2730 и выше. Любые с тем же интерфейсом.

...

Рейтинг:

0 / 0

03.12.2009, 11:23

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36345820

kvasandrew

Участник

Сообщения: 38

Рейтинг: 0 / 0

Бугага. 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

Участник

Откуда: Москва

Сообщения: 807

Рейтинг: 0 / 0

kvasandrew,

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

Было бы очень интересно узнать, как и чем тестировали.

...

Рейтинг:

0 / 0

03.12.2009, 13:40

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36345891

a_shats

Участник

Откуда: Москва

Сообщения: 807

Рейтинг: 0 / 0

kvasandrew,

И да, если вопрос не в деньгах - чего было не применить тупо mid-range массивы, они всяко шустрее этого будут ? :)

...

Рейтинг:

0 / 0

03.12.2009, 13:41

| Ответить | Цитировать | Написать

Нагрузочный тест дисковой системы

#36347047

kvasandrew

Участник

Сообщения: 38

Рейтинг: 0 / 0

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

Участник

Откуда: Москва

Сообщения: 807

Рейтинг: 0 / 0

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

Участник

Сообщения: 38

Рейтинг: 0 / 0

a_shats,

ну по большому счету да. был, правда, опыт и с IBM но там вся начинка один в один с SUN так что разницы в тестах не было.

...

Рейтинг:

0 / 0

04.12.2009, 19:20

| Ответить | Цитировать | Написать

23 сообщений из 48, страница 2 из 2

все

Форумы / Unix-системы [игнор отключен] [закрыт для гостей] / Нагрузочный тест дисковой системы

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=25&msg=36341557&tid=1485282]:	0ms
get settings:	10ms
get forum list:	14ms
check forum access:	3ms
check topic access:	3ms
track hit:	45ms
get topic data:	8ms
get forum data:	2ms
get page messages:	60ms
get tp. blocked users:	1ms
others:	211ms

total:	357ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы