Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 RAID vs. DB2_PARALLEL_IO  [new]
db2test
Guest
Добрый день!

Есть тестовая база 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 ?

Спасибо.
27 авг 10, 13:00    [9337064]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4947
Добрый день.

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.
27 авг 10, 14:46    [9338259]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
db2test
Guest
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.
Как-то это ненормально, имхо
27 авг 10, 18:20    [9340089]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4947
Надо бы этот запрос db2batch'ем выполнять.
Смотреть на io статистику по табличному пространству и сравнивать...
27 авг 10, 19:06    [9340252]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
GVF112GVF
Guest
Mark Barinstein
Надо бы этот запрос db2batch'ем выполнять.
Смотреть на io статистику по табличному пространству и сравнивать...


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

С уважением,
Вадим.
27 авг 10, 20:18    [9340562]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2550
Я вряд ли могу сказать полезное по данной конкретной проблеме, но, абстрактно говоря, все эти RAID'ы (кроме первого) мне кажутся опасными с точки зрения настройки производительности.

Вот, full stripe получился в 1024k. А действительно ли выравнены экстенты по этому размеру? (Я не знаю, как устроена jfs2). Это не говоря о том, что, кроме fullscan'а, бывает и random reading. Спокойнее было бы просто сделать 8 зеркал и разместить на них по 8 контейнеров каждого tablespace.
27 авг 10, 20:41    [9340637]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
GVF112GVF
Guest
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

С уважением,
Вадим.
28 авг 10, 09:58    [9342171]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
db2test
Guest
Mark Barinstein
Надо бы этот запрос db2batch'ем выполнять.
Смотреть на io статистику по табличному пространству и сравнивать...


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

Без DB2_PARALLEL_IO :

 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
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 во много раз больше, правда не очень понятно из-за чего.
30 авг 10, 14:33    [9349864]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
db2test
Guest
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. Думается, что это будет многовато :)
30 авг 10, 15:05    [9350173]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4947
db2test
Во втором случае Total elapsed asynchronous read time во много раз больше, правда не очень понятно из-за чего.
Похоже, что массив гораздо хуже обрабатывает параллельные запросы, чем последовательные. Xотя вроде бы должно быть наоборот...
30 авг 10, 18:46    [9352088]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
GVF112GVF
Guest
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, дисковой подсистемы и т.д.

С уважением,
Вадим.
31 авг 10, 00:15    [9352988]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
GVF112GVF
Guest
GVF112GVF
Mark 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.
31 авг 10, 00:23    [9353009]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
db2test
Guest
А ларчик просто открывался (с)

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

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

test_without_DB2_PARALLEL_IO_and_FILESYSTEM_CACHING

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

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

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

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. Понятно, что это все "сферический тест в вакууме" и как оно будет на реальном продакшене с миксом коротких запросов по индексу и периодическими фуллсканами еще "бабушка надвое сказала".
1 сен 10, 13:06    [9363230]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
db2test
Guest
Исследования продолжаются ....
В полученных выше результатах для симуляцмм фуллскана использовал простейший запрос вида

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 в сек.

Где еще можно копнуть, чтоб скорость чтения таблицы простым селектом увеличить ?
28 сен 10, 14:31    [9515024]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
Vladimir Kiselev
Member

Откуда: Жуковский
Сообщений: 209
db2test

В моей системе для диска c базой queue_depth=10 и число запущенных aioserver'ов =120 (судя по ps -elfk | grep aio). В редбуке пишут, что для FC-дисков нужно число шпинделей умножать на 16, т.е. в моем случае 16*16=256=MAX. Думается, что это будет многовато :)

aioservers много не бывает, во всяком случае пишут, что неиспользуемые aioserverы ресурсов не кушают. Если их количества недостаточно, то максимально параллельных запросов будет в Вашем случае 120, а не 256.
Не знаю, поможет ли в Вашем случае, но я пользуюсь nmon для мониторинга (в режиме регистрации, а не в интерактиве), он показывает дисковые нагрузки и т.п. Возможно есть смысл посмотреть.
Буферпулы - это другая история, но они тоже влияют.
29 сен 10, 12:21    [9521603]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
db2test
Guest
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 млн) ?
29 сен 10, 13:49    [9522573]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
mustaccio
Member

Откуда: Москва -> Торонто
Сообщений: 494
db2test
Непонятно почему запрос с группировкой лупит по 300000/сек. строк по таблице, а простой select * from table в 20 раз меньше.


Думаю, что узкое место здесь - вывод результатов запроса на экран (или куда они там выводятся). Я почти уверен, что производительность "export to /dev/null of ixf select * from table" будет работать существенно быстрее.
29 сен 10, 16:03    [9524084]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4947
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.
29 сен 10, 16:41    [9524519]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
db2test
Guest
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)

К сообщению приложен файл (db2top.zip - 94Kb) cкачать
29 сен 10, 17:12    [9524918]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
Yo.!
Guest
а не может быть проблемы с мультиблочным чтением (scattered read) ?
на сколько я знаю через кеш файловой системы мультиблочно читать не возможно принципиально т.к. это фича железяки. значит при FILESYSTEM_CACHING мультиблочно не мог бы читать, а с NO_FILESYSTEM_CACHING у вас явно разрыв не тот который должено было бы дать мультиблочное чтение.
29 сен 10, 17:57    [9525426]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
mustaccio
Member

Откуда: Москва -> Торонто
Сообщений: 494
А вы не пробовали планы запросов смотреть? Так, на всякий случай спрашиваю, наверное, пробовали...

set current explain mode yes
select * from db2inst1.testtab32
set current explain mode no
db2exfmt -d <database name> -1 | more
29 сен 10, 18:33    [9525620]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
GVF112GVF
Guest
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 млн) ?


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

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

С уважением,
Вадим.
29 сен 10, 20:19    [9525941]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
GVF112GVF
Guest
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)


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

С уважением,
Вадим.
29 сен 10, 20:29    [9525977]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
db2test
Guest
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
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
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

Только вот чем поможет время без фетча....
29 сен 10, 22:46    [9526323]     Ответить | Цитировать Сообщить модератору
 Re: RAID vs. DB2_PARALLEL_IO  [new]
db2test
Guest
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 сек).
30 сен 10, 08:51    [9527026]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить