ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / RAID vs. DB2_PARALLEL_IO
39 сообщений из 39, показаны все 2 страниц
  все  
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
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36873652
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
db2testТолько вот чем поможет время без фетча....Это проверка типа "куда время уходит".
Т.е. fetch такого огромного кол-ва записей даже не через сеть - дело весьма затратное.

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

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

Потом опять как раз примерно через 25 секунд начинается третья фаза собственно с чтением почему-то из обеих таблиц (временной и рабочей testtab32) со скоростью ..... ~10 000 rows/s (db2top3.jpg). И так до самого конца еле-еле.Для любого селекта оно должно построить курсор на сервере. Не вдаваясь в детели, курсор - таблица указателей на строки данных.
Для такого большого курсора организуется временная таблица, куда оно сначало и быстро пишет.
После этого надо параллельно со сканированием курсора обращаться к строкам и передавать эти строки клиенту.
Абсолютно некорректно сравнивать скорости работы count(*) и *, так как в последнем случае делается гораздо больше работы, ведь в случае count(*) не надо строить огромный курсор и передавать ещё более огромный результат клиенту.
...
Рейтинг: 0 / 0
30.09.2010, 09:54
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36873694
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
Yo.!а не может быть проблемы с мультиблочным чтением (scattered read) ?
на сколько я знаю через кеш файловой системы мультиблочно читать не возможно принципиально т.к. это фича железяки. значит при FILESYSTEM_CACHING мультиблочно не мог бы читать, а с NO_FILESYSTEM_CACHING у вас явно разрыв не тот который должено было бы дать мультиблочное чтение.Не можете привести ссылку, где вы это прочитали?
scattered read - это readv , которому всё равно, с каким флагом открыт файл.
Да и
Код: plaintext
1.
 Asynchronous pool data page reads        =  644560
при установленном FILE SYSTEM CACHING для табличного пр-ва говорит о том, что префетчеры всю работу и сделали.

Ну, вроде на win ещё оно может использоваться только если файл открыт c O_DIRECT (или как он там у них называется - прямое чтение в обход файлового кэша), но при чём здесь "фича железяки"...
...
Рейтинг: 0 / 0
30.09.2010, 10:08
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36874183
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
db2test
"мультиблочное чтение" это в смысле параллельное чтение экстентов несколькими префетчерами c одного контейнера ? Ну как бы это и было целю изначального тестирования. Пока не понятно то ли это проблема c DB2, то ли это ..."it depend's (c) :)

мне кажется префеч один, db2 это Vector I/O похоже называет:

Read requests typically require "x" bytes to be placed in a single I/O buffer. This I/O buffer is a contiguous area of memory and, if very large, may have to be broken down into smaller chunks and copied into other areas of memory to be used by an application, such as DB2. For example, DB2 may choose to pre-fetch multiple extents of data into the bufferpool in response to a query. An extent by default is 32 (4 KB) pages. From here, the extent is broken up into 4 KB chunks (the individual pages) and copied to the bufferpool.

Vector I/O allows the allocation of smaller I/O buffers; in this case, of size 4 KB. A single vector read fills these buffers, which directly relate to pages in the bufferpool, eliminating the need to perform the copies. To enable Vector I/O on Linux, you must set the DB2 registry variable DB2_SCATTERED_IO (shown in the command below) and restart DB2.
http://www.ibm.com/developerworks/data/library/techarticle/dm-0509wright/

[quot Mark Barinstein]Не можете привести ссылку, где вы это прочитали?
scattered read - это readv , которому всё равно, с каким флагом открыт файл.

под виндой
http://msdn.microsoft.com/en-us/library/aa365469%28VS.85%29.aspx
The file handle must be created with the GENERIC_READ right, and the FILE_FLAG_OVERLAPPED and FILE_FLAG_NO_BUFFERING flags.

чтение через кеш файловой системы совершенно не стыкуется с моим представлением процесса. я себе это представляю как задание контроллеру считать одной io операцией допустим 128 блоков, коньтроллер считывает и через DMA кладет все 128 в bufferpool.
...
Рейтинг: 0 / 0
30.09.2010, 12:35
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36874187
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
предыдущее сообщение чего-то покарежилось, дублирую:
db2test
"мультиблочное чтение" это в смысле параллельное чтение экстентов несколькими префетчерами c одного контейнера ? Ну как бы это и было целю изначального тестирования. Пока не понятно то ли это проблема c DB2, то ли это ..."it depend's (c) :)


мне кажется префеч один, db2 это Vector I/O похоже называет:

Read requests typically require "x" bytes to be placed in a single I/O buffer. This I/O buffer is a contiguous area of memory and, if very large, may have to be broken down into smaller chunks and copied into other areas of memory to be used by an application, such as DB2. For example, DB2 may choose to pre-fetch multiple extents of data into the bufferpool in response to a query. An extent by default is 32 (4 KB) pages. From here, the extent is broken up into 4 KB chunks (the individual pages) and copied to the bufferpool.

Vector I/O allows the allocation of smaller I/O buffers; in this case, of size 4 KB. A single vector read fills these buffers, which directly relate to pages in the bufferpool, eliminating the need to perform the copies. To enable Vector I/O on Linux, you must set the DB2 registry variable DB2_SCATTERED_IO (shown in the command below) and restart DB2.
http://www.ibm.com/developerworks/data/library/techarticle/dm-0509wright/

Mark BarinsteinНе можете привести ссылку, где вы это прочитали?
scattered read - это readv , которому всё равно, с каким флагом открыт файл.

под виндой
http://msdn.microsoft.com/en-us/library/aa365469%28VS.85%29.aspx
The file handle must be created with the GENERIC_READ right, and the FILE_FLAG_OVERLAPPED and FILE_FLAG_NO_BUFFERING flags.

чтение через кеш файловой системы совершенно не стыкуется с моим представлением процесса. я себе это представляю как задание контроллеру считать одной io операцией допустим 128 блоков, коньтроллер считывает и через DMA кладет все 128 в bufferpool.
...
Рейтинг: 0 / 0
30.09.2010, 12:37
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36874338
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Mark BarinsteinАбсолютно некорректно сравнивать скорости работы count(*) и *, так как в последнем случае делается гораздо больше работы, ведь в случае count(*) не надо строить огромный курсор и передавать ещё более огромный результат клиенту.
Марк, большое спасибо за explain :)
А каким образом можно увеличить скорость фетча ?
...
Рейтинг: 0 / 0
30.09.2010, 13:20
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36875466
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
db2testА каким образом можно увеличить скорость фетча ?
select * from ... FOR READ ONLY
и тут читать:
Specifying row blocking to reduce overhead
Т.е. в зависимости от типа соединения делать побольше aslheapsz или rqrioblk.
...
Рейтинг: 0 / 0
30.09.2010, 18:43
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36880752
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Развернул базу с тестовой таблицей на 9.7.2 под AIX (на той же файловой системе поверх RAID10 16HDD) и под SLES10 SP2 на VMWare (десктоп, 1 SATA HDD)

На SLES10 тестовый запрос с группировкой (без фетча большого курсора) с включенным кэшированием файловой системы (Ext3) выполняется на 50% медленнее чем с NO FILE SYSTEM CACHING (ну т.е как и задумано)

На AIX все также в 2,5-3 раза быстрее при FILE SYSTEM CACHING

Оба теста без DB2_PARALLEL_IO.

Как так выходит, что с кэшем FS на AIX'е получается быстрее ?
...
Рейтинг: 0 / 0
04.10.2010, 16:48
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36880764
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Mark Barinstein
select * from ... FOR READ ONLY
и тут читать:
Specifying row blocking to reduce overhead
Т.е. в зависимости от типа соединения делать побольше aslheapsz или rqrioblk.
Спасибо. Правда никого эффекта не произошло.
...
Рейтинг: 0 / 0
04.10.2010, 16:51
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36882477
Mark Barinstein
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mark Barinstein
Гость
db2testРазвернул базу с тестовой таблицей на 9.7.2 под AIX (на той же файловой системе поверх RAID10 16HDD) и под SLES10 SP2 на VMWare (десктоп, 1 SATA HDD)

На SLES10 тестовый запрос с группировкой (без фетча большого курсора) с включенным кэшированием файловой системы (Ext3) выполняется на 50% медленнее чем с NO FILE SYSTEM CACHING (ну т.е как и задумано)

На AIX все также в 2,5-3 раза быстрее при FILE SYSTEM CACHING

Оба теста без DB2_PARALLEL_IO.

Как так выходит, что с кэшем FS на AIX'е получается быстрее ?Ну, можно ещё с block based bufferpool поиграться.
Проведите тесты с размером блока в extentsize и разными процентами блочности.
...
Рейтинг: 0 / 0
05.10.2010, 14:19
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36951733
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Mark BarinsteinНу, можно ещё с block based bufferpool поиграться.
Проведите тесты с размером блока в extentsize и разными процентами блочности.
Спасибо, помогло. Намотаю на ус :)

При BLOCKSIZE=EXTENTSIZE и размере block area в 10% от размера буферпула результаты сравнялись. При этом, чем меньше BLOCKSIZE относительно EXTENTSIZE, тем хуже время выполнения запроса.

Компрессия таблицы также сравнивает результат с FILESYSTEM CACHING и блочным БП.
Т.е кролики это не только ценный мех компрессия не только уменьшает объем БД (у меня таблицы жмутся в 4-5 раз), но и значительно улучшает перфоманс запросов с sequential I/O.

Но в любом случае получить результат лучше, чем у FILESYSTEM CACHING, не получилось :)
...
Рейтинг: 0 / 0
12.11.2010, 14:05
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36966406
Camper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Camper
Гость
Извиняюсь, что вмешиваюсь.
Как я понимаю Вы используете AIX в качестве операционной системы, это так?
На уровне ОС настраивался ли асинхронный ввод-вывод?
...
Рейтинг: 0 / 0
19.11.2010, 17:03
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36986069
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
Провел тест еще раз, но уже на другом хосте (тоже AIX 5.3. TL10 SP1 + DB2 9.1.8)
Файловая система базы на LUN'е c того же RAID10 (16 HDD)

AUTOMATIC STORAGE таблспейс, EXTENTSIZE=32, PAGESIZE=16K, PREFETCHSIZE=AUTO
Т.е. все тоже самое.

Тест с NO FILE SYSTEM CACHING прошел быстрее FILE SYSTEM CACHING на 10%
Повторил раз 20-ть. С таким же результатом.

На исходном хосте опять повторил тест. Все так же в 2,5-3 раза хуже с NO FILE SYSTEM CACHING
(без блочного буферпула)

Проверил наcтройки vmo, ioo, параметры файловых систем на обоих хостах, настройки кэширования лунов на стородже - все одинаковое.

"Где собака зарыта" - непонятно :(
Куда дальше копать - тоже.

Еще любопытно, что запрос по таблице созданной в обычном DMS-пространстве с теми же параметрами работает на 50% медленнее, чем в случае с automatic storage.
...
Рейтинг: 0 / 0
30.11.2010, 14:13
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36986089
db2test
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db2test
Гость
CamperИзвиняюсь, что вмешиваюсь.
Как я понимаю Вы используете AIX в качестве операционной системы, это так?
На уровне ОС настраивался ли асинхронный ввод-вывод?

Специально c AIO ничего не делал.
В системе 120 aioservers, iostat очередей к AIO не показывает.

А что конкретно там настраивать кроме числа aioserver'ов ?
...
Рейтинг: 0 / 0
30.11.2010, 14:18
| Ответить | Цитировать | Написать  
RAID vs. DB2_PARALLEL_IO
    #36987179
wrap
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wrap
Гость
имхо для начала стоит сравнивать планы запросов и и/о статистику и плясать уже от этих данных.
...
Рейтинг: 0 / 0
30.11.2010, 19:36
| Ответить | Цитировать | Написать  
39 сообщений из 39, показаны все 2 страниц
  все  
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / RAID vs. DB2_PARALLEL_IO
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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