ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / RAID vs. DB2_PARALLEL_IO
25 сообщений из 39, страница 1 из 2
  1  все
RAID vs. DB2_PARALLEL_IO
    #36815345
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Добрый день!

Есть тестовая база 9.1.8 на файловой системе jfs2 поверх RAID10 (16HDD, 128K disk segment size)
Тестовая таблица создана в TS с PAGESIZE=16K, EXTENSIZE=32, PREFETCHSIZE=AUTOMATIC и одним контейнером.

NUM_IOSERVERS=AUTOMATIC=4

При включении DB2_PARALELL_IO=*:4 и выше тестовый запрос, генерирующий фуллскан, начинает работать в 3 раза медленнее чем при невключенном DB2_PARALELL_IO, что есть очень странно, учитывая, что в мануале как бы настойчиво рекомендуется использовать DB2_PARALEL_IO, если контейнер TS лежит на RAID-девайсе.

Игрища с изменением PREFETCHSIZE картину сильно не меняют. (+/- 10%)
При EXTENTSIZE < 32 запрос начинает выполняться еще дольше, увеличение EXTENSIZE > 32 результат не улучшает.
Переразбить рейд на 4x4, увы, не вариант. Нужно соптимизировать текущий конфиг.

При компрессии тестовой таблицы результаты выполнения запроса те же только скорость чтения с диска меньше в 3 раза.

Может быть еще что-то необходимо включить/изменить для распараллеливания I/O ?

Спасибо.
...
Рейтинг: 0 / 0
27.08.2010, 13:00
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36815703
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Добрый день.

16 дисков в RAID10 - это 8 параллельных зеркал.
Т.е. full stripe будет 128k*8=1024k
Поэтому при странице в 16k устанавливаем:
- EXTENTSIZE=8, чтоб extent попадал в segment size
- DB2_PARALELL_IO=*:8

Таким образом, при каждом префетче будет генерироваться 8 параллельных запросов, каждый на 128k (PAGESIZE*EXTENTSIZE).
В теории такой характер запроса должен быть оптимальным - все диски загружены.

Если не выставлять DB2_PARALLEL_IO, то при странице в 16k загрузить все диски сразу можно при EXTENTSIZE=64.
...
Рейтинг: 0 / 0
27.08.2010, 14:46
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36816310
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Mark BarinsteinДобрый день.

16 дисков в RAID10 - это 8 параллельных зеркал.
Т.е. full stripe будет 128k*8=1024k
Поэтому при странице в 16k устанавливаем:
- EXTENTSIZE=8, чтоб extent попадал в segment size
- DB2_PARALELL_IO=*:8

Таким образом, при каждом префетче будет генерироваться 8 параллельных запросов, каждый на 128k (PAGESIZE*EXTENTSIZE).
В теории такой характер запроса должен быть оптимальным - все диски загружены.

Если не выставлять DB2_PARALLEL_IO, то при странице в 16k загрузить все диски сразу можно при EXTENTSIZE=64.

Спасибо за совет.

Сделал тесткейс с тремя размерами экстента (8,32,64)

При выключенном DB2_PARALLEL_IO тестовый запрос выполняется :

extentsize 8 - ~70 сек
extentsize 32 - ~50 сек
extentsize 64 - ~70 сек

Т.е. запрос выполняется с одинаковой скоростью при размере экстента как 8 так и 64 страницы. Что есть весьма странно.

При DB2_PARALLEL_IO=*:8

extentsize 8 - ~320 сек
extentsize 32 - ~215 сек
extentsize 64 - ~200 сек

После каждого выполнения тестового запроса инстанс перестартовывал. Каждый вариант выполнял 3 раза и взял среднее время выполнения.
Опыты показывают явную деградацию перфоманса при включении DB2_PARALLEL_IO.
Как-то это ненормально, имхо
...
Рейтинг: 0 / 0
27.08.2010, 18:20
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36816367
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Надо бы этот запрос db2batch'ем выполнять.
Смотреть на io статистику по табличному пространству и сравнивать...
...
Рейтинг: 0 / 0
27.08.2010, 19:06
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36816432
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
Mark BarinsteinНадо бы этот запрос db2batch'ем выполнять.
Смотреть на io статистику по табличному пространству и сравнивать...

Очень хорошо использовать db2top, db2pd (вместе с iostat, topas или nmon).

С уважением,
Вадим.
...
Рейтинг: 0 / 0
27.08.2010, 20:18
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36816455
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Я вряд ли могу сказать полезное по данной конкретной проблеме, но, абстрактно говоря, все эти RAID'ы (кроме первого) мне кажутся опасными с точки зрения настройки производительности.

Вот, full stripe получился в 1024k. А действительно ли выравнены экстенты по этому размеру? (Я не знаю, как устроена jfs2). Это не говоря о том, что, кроме fullscan'а, бывает и random reading. Спокойнее было бы просто сделать 8 зеркал и разместить на них по 8 контейнеров каждого tablespace.
...
Рейтинг: 0 / 0
27.08.2010, 20:41
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36816767
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
db2testДобрый день!

Есть тестовая база 9.1.8 на файловой системе jfs2 поверх RAID10 (16HDD, 128K disk segment size)
Тестовая таблица создана в TS с PAGESIZE=16K, EXTENSIZE=32, PREFETCHSIZE=AUTOMATIC и одним контейнером.

NUM_IOSERVERS=AUTOMATIC=4

При включении DB2_PARALELL_IO=*:4 и выше тестовый запрос, генерирующий фуллскан, начинает работать в 3 раза медленнее чем при невключенном DB2_PARALELL_IO, что есть очень странно, учитывая, что в мануале как бы настойчиво рекомендуется использовать DB2_PARALEL_IO, если контейнер TS лежит на RAID-девайсе.

Игрища с изменением PREFETCHSIZE картину сильно не меняют. (+/- 10%)
При EXTENTSIZE < 32 запрос начинает выполняться еще дольше, увеличение EXTENSIZE > 32 результат не улучшает.
Переразбить рейд на 4x4, увы, не вариант. Нужно соптимизировать текущий конфиг.

При компрессии тестовой таблицы результаты выполнения запроса те же только скорость чтения с диска меньше в 3 раза.

Может быть еще что-то необходимо включить/изменить для распараллеливания I/O ?

Спасибо.

FAQ: http://www-01.ibm.com/support/docview.wss?rs=71&uid=swg21298716

C.16 When using a RAID device for tablespaces, what should I set the EXTENTSIZE of the tablespace to?
It is recommended that you set the EXTENTSIZE to match the stripe set of the RAID device for efficient data retrieval. Further tuning may be required depending on benchmark tests run on your individual systems.

Example:-
If you have a RAID 5 (4+1) system with 128k strip size you could set your EXTENTSIZE at 64k and your PAGESIZE at 8k. (as a rule of thumb, EXTENTSIZE X PAGESIZE - 64X8, should equal to strip size X no of disks, - 128X4)



Посмотри глубину очередей и число серверов AIO -
Best Practices for DB2 on AIX 6.1 for POWER Systems
http://www.redbooks.ibm.com/redbooks/pdfs/sg247821.pdf

PS: Database Performance Tuning on AIX -
http://www.redbooks.ibm.com/redbooks/pdfs/sg245511.pdf

С уважением,
Вадим.
...
Рейтинг: 0 / 0
28.08.2010, 09:58
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36819126
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Mark BarinsteinНадо бы этот запрос db2batch'ем выполнять.
Смотреть на io статистику по табличному пространству и сравнивать...

Спасибо. Прогнал батчем вариант с EXTENTSIZE=8 со сборкой снэпшотов

Без DB2_PARALLEL_IO :

Код: 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.
 Buffer pool data logical reads           =  803764 
  Buffer pool data physical reads          =  644595 
  Buffer pool temporary data logical reads   =  0 
  Buffer pool temporary data physical reads  =  0 
  Asynchronous pool data page reads        =  644560 
  Buffer pool data writes                  =  0 
  Asynchronous pool data page writes       =  0 
  Buffer pool index logical reads          =  0 
  Buffer pool index physical reads         =  0 
  Buffer pool temporary index logical reads  =  0 
  Buffer pool temporary index physical reads =  0 
  Asynchronous pool index page reads       =  0 
  Buffer pool index writes                 =  0 
  Asynchronous pool index page writes      =  0 
  Buffer pool xda logical reads            =  0 
  Buffer pool xda physical reads           =  0 
  Buffer pool temporary xda logical reads  =  0 
  Buffer pool temporary xda physical reads =  0 
  Asynchronous pool xda page reads         =  0 
  Buffer pool xda writes                   =  0 
  Asynchronous pool xda page writes        =  0 
  Total buffer pool read time (millisec)   =  88035 
  Total buffer pool write time (millisec)  =  0 
  Total elapsed asynchronous read time     =  88024 
  Total elapsed asynchronous write time    =  0 
  Asynchronous data read requests          =  80572 
  Asynchronous index read requests         =  0 
  Asynchronous xda read requests           =  0 
  Direct reads                             =  0 
  Direct writes                            =  0 
  Direct read requests                     =  0 
  Direct write requests                    =  0 
  Direct reads elapsed time (ms)           =  0 
  Direct write elapsed time (ms)           =  0 
  Number of files closed                   =  0 
  Data pages copied to extended storage    =  0 
  Index pages copied to extended storage   =  0 
  Data pages copied from extended storage  =  0 
  Index pages copied from extended storage =  0 

....................................................................

* Summary Table:

Type      Number      Repetitions Total Time (s) Min Time (s)   Max Time (s)   Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------
Statement            1             1        66 . 241791        66 . 241791        66 . 241791         66 . 241791        66 . 241791              538               0 

* Total Entries:               1 
* Total Time:                 66 . 241791  seconds
* Minimum Time:               66 . 241791  seconds
* Maximum Time:               66 . 241791  seconds
* Arithmetic Mean Time:       66 . 241791  seconds
* Geometric Mean Time:        66 . 241791  seconds
---------------------------------------------

C установленным DB2_PARALLEL_IO=*:8
Код: 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.
Buffer pool data logical reads           =  803764 
  Buffer pool data physical reads          =  644595 
  Buffer pool temporary data logical reads   =  0 
  Buffer pool temporary data physical reads  =  0 
  Asynchronous pool data page reads        =  644572 
  Buffer pool data writes                  =  0 
  Asynchronous pool data page writes       =  0 
  Buffer pool index logical reads          =  0 
  Buffer pool index physical reads         =  0 
  Buffer pool temporary index logical reads  =  0 
  Buffer pool temporary index physical reads =  0 
  Asynchronous pool index page reads       =  0 
  Buffer pool index writes                 =  0 
  Asynchronous pool index page writes      =  0 
  Buffer pool xda logical reads            =  0 
  Buffer pool xda physical reads           =  0 
  Buffer pool temporary xda logical reads  =  0 
  Buffer pool temporary xda physical reads =  0 
  Asynchronous pool xda page reads         =  0 
  Buffer pool xda writes                   =  0 
  Asynchronous pool xda page writes        =  0 
  Total buffer pool read time (millisec)   =  2056982 
  Total buffer pool write time (millisec)  =  0 
  Total elapsed asynchronous read time     =  2056881 
  Total elapsed asynchronous write time    =  0 
  Asynchronous data read requests          =  80572 
  Asynchronous index read requests         =  0 
  Asynchronous xda read requests           =  0 
  Direct reads                             =  0 
  Direct writes                            =  0 
  Direct read requests                     =  0 
  Direct write requests                    =  0 
  Direct reads elapsed time (ms)           =  0 
  Direct write elapsed time (ms)           =  0 
  Number of files closed                   =  0 
  Data pages copied to extended storage    =  0 
  Index pages copied to extended storage   =  0 
  Data pages copied from extended storage  =  0 
  Index pages copied from extended storage =  0 

..........................................................................

* Summary Table:

Type      Number      Repetitions Total Time (s) Min Time (s)   Max Time (s)   Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------
Statement            1             1       276 . 043961       276 . 043961       276 . 043961        276 . 043961       276 . 043961              538               0 

* Total Entries:               1 
* Total Time:                276 . 043961  seconds
* Minimum Time:              276 . 043961  seconds
* Maximum Time:              276 . 043961  seconds
* Arithmetic Mean Time:      276 . 043961  seconds
* Geometric Mean Time:       276 . 043961  seconds
---------------------------------------------

Во втором случае Total elapsed asynchronous read time во много раз больше, правда не очень понятно из-за чего.
...
Рейтинг: 0 / 0
30.08.2010, 14:33
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36819246
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
GVF112GVF
Посмотри глубину очередей и число серверов AIO -
Best Practices for DB2 on AIX 6.1 for POWER Systems
http://www.redbooks.ibm.com/redbooks/pdfs/sg247821.pdf

PS: Database Performance Tuning on AIX -
http://www.redbooks.ibm.com/redbooks/pdfs/sg245511.pdf



Спасибо.
В моей системе для диска c базой queue_depth=10 и число запущенных aioserver'ов =120 (судя по ps -elfk | grep aio). В редбуке пишут, что для FC-дисков нужно число шпинделей умножать на 16, т.е. в моем случае 16*16=256=MAX. Думается, что это будет многовато :)
...
Рейтинг: 0 / 0
30.08.2010, 15:05
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36819830
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
db2testВо втором случае Total elapsed asynchronous read time во много раз больше, правда не очень понятно из-за чего.Похоже, что массив гораздо хуже обрабатывает параллельные запросы, чем последовательные. Xотя вроде бы должно быть наоборот...
...
Рейтинг: 0 / 0
30.08.2010, 18:46
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36820136
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
Mark Barinstein,

Думаю, что проблема кроется в физическом планировании базы данных.

- Нужно смотреть на план выполнения запрос (db2 explain tools).

- Как объекты базы данных затрагивает запрос (таблицы, индексы).
- Какие табличные пространства наиболее интенсивно используются (операции I/O - read/write).
Это легко посмотреть,используя утилиты - db2top (или db2pd).
На уровне ОС - можно использовать nmon/topas или iostat, sar.

Далее, можно понять, насколько эффективно выполняются параллельные операции I/O - в каких табличных пространствах и по каким контейнерам.

Может он у Вас вообще не расспаралеливает I/O на определенном
уровне выполнения SQL-запроса .... ;)

Посмотри в db2top как читаются/обновляются таблицы и что происходит на уровне табличных
пространств в момент выполнения SQL-запроса. Сколько контейнеров в табличном пространстве.
Где выполняются сортировки. Как стратегия размещение - таблиц, индексов и т.д.

Где затык - на уровне OC, адаптеров I/O, дисковой подсистемы и т.д.

С уважением,
Вадим.
...
Рейтинг: 0 / 0
31.08.2010, 00:15
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36820143
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
GVF112GVFMark Barinstein,

Думаю, что проблема кроется в физическом планировании базы данных.

- Нужно смотреть на план выполнения запрос (db2 explain tools) в том и другом случае.

- Какие объекты базы данных затрагивает SQL-запрос (таблицы, индексы).
- Какие табличные пространства наиболее интенсивно используются (операции I/O - read/write).
Это легко посмотреть,используя утилиты - db2top (или db2pd). На уровне ОС - можно использовать nmon/topas или iostat, sar.

Далее,
можно понять, насколько эффективно выполняются параллельные операции I/O - в каких табличных пространствах и по каким контейнерам.

Может он у Вас вообще не расспаралеливает I/O на определенном
уровне выполнения SQL-запроса .... ;)

Посмотри в db2top как читаются/обновляются таблицы и что происходит на уровне табличных
пространств в момент выполнения SQL-запроса. Сколько контейнеров в табличном пространстве.
Где выполняются сортировки. Какая стратегия размещения используется для таблиц, индексов и т.д.

Где затык (очереди на обслучивание) - на уровне OC, адаптеров I/O, дисковой подсистемы и т.д.

С уважением,
Вадим.

Марк,
sorry - это не в твой адреc .... this is message for db2test ...

Thanks!
Vadim.
...
Рейтинг: 0 / 0
31.08.2010, 00:23
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36823478
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
А ларчик просто открывался (с)

Как-то я забыл, что для 9.1 по дефолту таблспейсы создаются с FILE SYSTEM CACHING.

Ниже (если кому интересно) результаты тестовых прогонов (по 5 раз) запроса по таблицам с размером экстента соответственно 2,8,32 и 64 страницы по 16к при отсутствии/наличии
DB2_PARALLEL_IO и FILESYSTEM CACHING

test_without_DB2_PARALLEL_IO_and_ FILESYSTEM_CACHING

Код: plaintext
1.
2.
3.
4.
5.
6.
Type      Number      Repetitions Total Time (s) Min Time (s)   Max Time (s)   Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------
Statement            1             5       309 . 222739        56 . 709905        64 . 950014         61 . 844548        61 . 772272              538               0 
Statement            2             5       315 . 805930        60 . 130851        65 . 075317         63 . 161186        63 . 129848              538               0 
Statement            3             5       222 . 231195        42 . 174723        46 . 649124         44 . 446239        44 . 413304              538               0 
Statement            4             5       363 . 113416        69 . 720253        76 . 536755         72 . 622683        72 . 584005              538               0

test_without_DB2_PARALLEL_IO_and_ NO_FILESYSTEM_CACHING

Код: plaintext
1.
2.
3.
4.
5.
6.
Type      Number      Repetitions Total Time (s) Min Time (s)   Max Time (s)   Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------
Statement            1             5      2793 . 588222       517 . 360769       593 . 943016        558 . 717644       557 . 867094              538               0 
Statement            2             5       358 . 639447        65 . 048466        82 . 901180         71 . 727889        71 . 388998              538               0 
Statement            3             5       502 . 383938        97 . 031123       105 . 953915        100 . 476788       100 . 427785              538               0 
Statement            4             5       632 . 826169       108 . 303566       145 . 741493        126 . 565234       125 . 517762              538               0

test_ DB2_PARALLEL_IO-8 _and_ FILESYSTEM_CACHING

Код: plaintext
1.
2.
3.
4.
5.
6.
Type      Number      Repetitions Total Time (s) Min Time (s)   Max Time (s)   Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------
Statement            1             5      3246 . 401522       589 . 694620       739 . 681189        649 . 280304       647 . 445931              538               0 
Statement            2             5      1530 . 888882       247 . 685914       353 . 485397        306 . 177776       303 . 208272              538               0 
Statement            3             5      1082 . 126319       199 . 075194       242 . 910609        216 . 425264       215 . 872645              538               0 
Statement            4             5      1037 . 337798       188 . 844992       232 . 976233        207 . 467560       206 . 836456              538               0

test_ DB2_PARALLEL_IO-8 _and_ NO_FILESYSTEN_CACHING

Код: plaintext
1.
2.
3.
4.
5.
6.
Type      Number      Repetitions Total Time (s) Min Time (s)   Max Time (s)   Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------
Statement            1             5      1228 . 334537       224 . 353626       269 . 095073        245 . 666907       245 . 075791              538               0 
Statement            2             5       448 . 951955        82 . 728895       112 . 324726         89 . 790391        89 . 151512              538               0 
Statement            3             5       264 . 318431        46 . 500248        64 . 039753         52 . 863686        52 . 359854              538               0 
Statement            4             5       220 . 593527        40 . 882236        48 . 686108         44 . 118705        44 . 027419              538               0

Мысли по полученным результатам :

1. Включение DB2_PARALLEL_IO на таблспейсах с FILESYSTEM CAСHING приводит к существенному
падению производительности запросов с фуллсканом (исходная проблема).

2. EXTENTSIZE=2 - наихудший вариант для исходной дисковой конфигурации (raid10, 16hdd, 128к
disk segment size, 1024k full stripe), что, собственно, неудивительно.

3. При NO FILE SYSTEM CACHING (что по дефолту для таблспейсов начиная с 9.5) установка
DB2_PARALLEL_IO повышает производительность и чем больше EXTENTSIZE приближается к RAID
full stripe тем выше.

4. Кэш файловой системы иногда не так уж плох, как о нем говорят :)

5. etc....

Посмотрим на результаты с компрессией таблиц. To be continued ....

P.S. Понятно, что это все "сферический тест в вакууме" и как оно будет на реальном продакшене с миксом коротких запросов по индексу и периодическими фуллсканами еще "бабушка надвое сказала".
...
Рейтинг: 0 / 0
01.09.2010, 13:06
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36870029
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Исследования продолжаются ....
В полученных выше результатах для симуляцмм фуллскана использовал простейший запрос вида

select date, count(*) from table group by date
Теперь просто дергаю данные из тех же таблиц простым select * from table

Таблицы, напомню, с разным размером экстента.

Наблюдаю очень медленное чтение (db2top показывает 14-15 тыс. записей в секунду)
Не помогает ни вкл/выкл FILE SYSTEM CACHING, ни установка/снятие DB2_PARALLEL_IO, ни изменение PREFETCHSIZE, ни компрессия таблицы : на всех тестовых таблицах (extentsize=2,8,32) одна и та же скорость линейного чтения в ~15 000 записей в сек.

При этом запрос с группировкой в зависимости от extentsize в db2top'е показывает от 100 000 до 500 000 rows read в сек.

Где еще можно копнуть, чтоб скорость чтения таблицы простым селектом увеличить ?
...
Рейтинг: 0 / 0
28.09.2010, 14:31
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36871928
Vladimir Kiselev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir Kiselev
Гость
db2test
В моей системе для диска c базой queue_depth=10 и число запущенных aioserver'ов =120 (судя по ps -elfk | grep aio). В редбуке пишут, что для FC-дисков нужно число шпинделей умножать на 16, т.е. в моем случае 16*16=256=MAX. Думается, что это будет многовато :)
aioservers много не бывает, во всяком случае пишут, что неиспользуемые aioserverы ресурсов не кушают. Если их количества недостаточно, то максимально параллельных запросов будет в Вашем случае 120, а не 256.
Не знаю, поможет ли в Вашем случае, но я пользуюсь nmon для мониторинга (в режиме регистрации, а не в интерактиве), он показывает дисковые нагрузки и т.п. Возможно есть смысл посмотреть.
Буферпулы - это другая история, но они тоже влияют.
...
Рейтинг: 0 / 0
29.09.2010, 12:21
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36872209
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Vladimir Kiselev
aioservers много не бывает, во всяком случае пишут, что неиспользуемые aioserverы ресурсов не кушают. Если их количества недостаточно, то максимально параллельных запросов будет в Вашем случае 120, а не 256.
Не знаю, поможет ли в Вашем случае, но я пользуюсь nmon для мониторинга (в режиме регистрации, а не в интерактиве), он показывает дисковые нагрузки и т.п. Возможно есть смысл посмотреть.
Буферпулы - это другая история, но они тоже влияют.

iostat -AQ во время выполнения запроса показывает что AIO "курит бамбук". nmon+db2top тоже использую (больше правда в интерактиве). Буфферпул 4 Gb. Тут скорее интересно то, что FILE SYSTEM CACHING показывает лучший результат чем при отключенном кэшировании.

Меня сейчас больше беспокоит последняя проблема. Непонятно почему запрос с группировкой лупит по 300000/сек. строк по таблице, а простой select * from table в 20 раз меньше.
Кто-нибудь может привести свои цифры по rows read/s из db2top для простого select * from table на достаточно большой таблице (> 10 млн) ?
...
Рейтинг: 0 / 0
29.09.2010, 13:49
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36872650
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mustaccio
Участник
db2testНепонятно почему запрос с группировкой лупит по 300000/сек. строк по таблице, а простой select * from table в 20 раз меньше.

Думаю, что узкое место здесь - вывод результатов запроса на экран (или куда они там выводятся). Я почти уверен, что производительность "export to /dev/null of ixf select * from table" будет работать существенно быстрее.
...
Рейтинг: 0 / 0
29.09.2010, 16:03
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36872729
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
db2testМеня сейчас больше беспокоит последняя проблема. Непонятно почему запрос с группировкой лупит по 300000/сек. строк по таблице, а простой select * from table в 20 раз меньше.
Кто-нибудь может привести свои цифры по rows read/s из db2top для простого select * from table на достаточно большой таблице (> 10 млн) ?У db2batch есть rows_fetch и rows_out параметры.
Советую rows_out=0 и сравнить время выполнения запроса для rows_fetch=0 и rows_fetch=-1.
...
Рейтинг: 0 / 0
29.09.2010, 16:41
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36872816
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
mustaccio,

Все тесты провожу через db2batch c параметром SET ROWS_OUT 0. Т.е, если я правильно понимаю, то все записи фетчит сам db2batch, но на диск не вываливает.

Прогнал db2 "export to /dev/null of ixf select * from db2inst1.testtab32"
testtab32 - 21 млн. записей, pagesize=16k, extentsize=32, prefetchsize=auto

Во время прогона наблюдал за чтением в db2top
Снял скриншоты, как сюда картинки вставлять на разобрался сорри, архив с жипегами приаттачил.

Сразу после запуска наблюдаю картину (db2top1.jpg)
Идет зачем-то запись в какую-то временную таблицу со скоростью ~1 100 000 rows/s

Потом через момент времен равный как раз фетчу 21-мл записей с такой скоростью начинается чтение записей из этой же временной таблицы со скоростью ~800000 rows/s. (db2top2.jpg)

Потом опять как раз примерно через 25 секунд начинается третья фаза собственно с чтением почему-то из обеих таблиц (временной и рабочей testtab32) со скоростью ..... ~10 000 rows/s (db2top3.jpg). И так до самого конца еле-еле.

"Все чудесатее и чудесатее" (c)
...
Рейтинг: 0 / 0
29.09.2010, 17:12
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36872950
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
а не может быть проблемы с мультиблочным чтением (scattered read) ?
на сколько я знаю через кеш файловой системы мультиблочно читать не возможно принципиально т.к. это фича железяки. значит при FILESYSTEM_CACHING мультиблочно не мог бы читать, а с NO_FILESYSTEM_CACHING у вас явно разрыв не тот который должено было бы дать мультиблочное чтение.
...
Рейтинг: 0 / 0
29.09.2010, 17:57
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36873015
mustaccio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mustaccio
Участник
А вы не пробовали планы запросов смотреть? Так, на всякий случай спрашиваю, наверное, пробовали...

set current explain mode yes
select * from db2inst1.testtab32
set current explain mode no
db2exfmt -d <database name> -1 | more
...
Рейтинг: 0 / 0
29.09.2010, 18:33
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36873137
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
db2testVladimir Kiselev
aioservers много не бывает, во всяком случае пишут, что неиспользуемые aioserverы ресурсов не кушают. Если их количества недостаточно, то максимально параллельных запросов будет в Вашем случае 120, а не 256.
Не знаю, поможет ли в Вашем случае, но я пользуюсь nmon для мониторинга (в режиме регистрации, а не в интерактиве), он показывает дисковые нагрузки и т.п. Возможно есть смысл посмотреть.
Буферпулы - это другая история, но они тоже влияют.

iostat -AQ во время выполнения запроса показывает что AIO "курит бамбук". nmon+db2top тоже использую (больше правда в интерактиве). Буфферпул 4 Gb. Тут скорее интересно то, что FILE SYSTEM CACHING показывает лучший результат чем при отключенном кэшировании.

Меня сейчас больше беспокоит последняя проблема. Непонятно почему запрос с группировкой лупит по 300000/сек. строк по таблице, а простой select * from table в 20 раз меньше.
Кто-нибудь может привести свои цифры по rows read/s из db2top для простого select * from table на достаточно большой таблице (> 10 млн) ?

Нужно смотреть план выполнение запросов и сравнить их.

Да и вот еще,
Вы смотрели как ведет себя страничный файл (swap file) ?

С уважением,
Вадим.
...
Рейтинг: 0 / 0
29.09.2010, 20:19
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36873158
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
db2testmustaccio,

Все тесты провожу через db2batch c параметром SET ROWS_OUT 0. Т.е, если я правильно понимаю, то все записи фетчит сам db2batch, но на диск не вываливает.

Прогнал db2 "export to /dev/null of ixf select * from db2inst1.testtab32"
testtab32 - 21 млн. записей, pagesize=16k, extentsize=32, prefetchsize=auto

Во время прогона наблюдал за чтением в db2top
Снял скриншоты, как сюда картинки вставлять на разобрался сорри, архив с жипегами приаттачил.

Сразу после запуска наблюдаю картину (db2top1.jpg)
Идет зачем-то запись в какую-то временную таблицу со скоростью ~1 100 000 rows/s

Потом через момент времен равный как раз фетчу 21-мл записей с такой скоростью начинается чтение записей из этой же временной таблицы со скоростью ~800000 rows/s. (db2top2.jpg)

Потом опять как раз примерно через 25 секунд начинается третья фаза собственно с чтением почему-то из обеих таблиц (временной и рабочей testtab32) со скоростью ..... ~10 000 rows/s (db2top3.jpg). И так до самого конца еле-еле.

"Все чудесатее и чудесатее" (c)

Кодовые страницы базы и OS - такие же (совпадаю) ?
Как на счет сортировок ? Как ведет себя страничный файл OS ?

С уважением,
Вадим.
...
Рейтинг: 0 / 0
29.09.2010, 20:29
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36873265
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Mark Barinstein[У db2batch есть rows_fetch и rows_out параметры.
Советую rows_out=0 и сравнить время выполнения запроса для rows_fetch=0 и rows_fetch=-1.
Спасибо. Да, я с самого начала запускал с --#SET ROWS_OUT 0
Теперь добавил ROWS_FETCH 0, получил :

--#SET ROWS_FETCH 0 ROWS_OUT 0
Код: plaintext
1.
2.
3.
Type      Number      Repetitions Total Time (s) Min Time (s)   Max Time (s)   Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------
Statement            1             1       187 . 392776       187 . 392776       187 . 392776        187 . 392776       187 . 392776                0               0

--#SET ROWS_FETCH -1 ROWS_OUT 0
Код: plaintext
1.
2.
3.
Type      Number      Repetitions Total Time (s) Min Time (s)   Max Time (s)   Arithmetic Mean Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- --------------- -------------- -------------- -------------
Statement            1             1      1687 . 761951      1687 . 761951      1687 . 761951       1687 . 761951      1687 . 761951         20943733               0

Только вот чем поможет время без фетча....
...
Рейтинг: 0 / 0
29.09.2010, 22:46
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36873549
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Yo.!а не может быть проблемы с мультиблочным чтением (scattered read) ?
"мультиблочное чтение" это в смысле параллельное чтение экстентов несколькими префетчерами c одного контейнера ? Ну как бы это и было целю изначального тестирования. Пока не понятно то ли это проблема c DB2, то ли это ..."it depend's (c) :)
Yo.!
на сколько я знаю через кеш файловой системы мультиблочно читать не возможно принципиально т.к. это фича железяки. значит при FILESYSTEM_CACHING мультиблочно не мог бы читать
Тогда это объясняет ухудшение результата в разы при выставлении DB2_PARALLEL_IO и при FILE SYSTEM CACHING (например для EXTENTSIZE=32 это 44 сек. vs 215 сек.).

Yo.! а с NO_FILESYSTEM_CACHING у вас явно разрыв не тот который должено было бы дать мультиблочное чтение.
Ну вот оно и непонятно, при включении DB2_PARALLEL_IO=*:8 и при NO_FILESYSTEM_CACHING результат все равно хуже чем при кэшировании и без DB2_PARALLEL_IO (при EXTENTSIZE=32 52 сек. vs 44 сек).
...
Рейтинг: 0 / 0
30.09.2010, 08:51
| Ответить | Цитировать | Написать  
25 сообщений из 39, страница 1 из 2
  1  все
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / RAID vs. DB2_PARALLEL_IO
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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