Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
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(*) не надо строить огромный курсор и передавать ещё более огромный результат клиенту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2010, 09:54 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
Yo.!а не может быть проблемы с мультиблочным чтением (scattered read) ? на сколько я знаю через кеш файловой системы мультиблочно читать не возможно принципиально т.к. это фича железяки. значит при FILESYSTEM_CACHING мультиблочно не мог бы читать, а с NO_FILESYSTEM_CACHING у вас явно разрыв не тот который должено было бы дать мультиблочное чтение.Не можете привести ссылку, где вы это прочитали? scattered read - это readv , которому всё равно, с каким флагом открыт файл. Да и Код: plaintext 1. Ну, вроде на win ещё оно может использоваться только если файл открыт c O_DIRECT (или как он там у них называется - прямое чтение в обход файлового кэша), но при чём здесь "фича железяки"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2010, 10:08 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2010, 12:35 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
предыдущее сообщение чего-то покарежилось, дублирую: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2010, 12:37 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinАбсолютно некорректно сравнивать скорости работы count(*) и *, так как в последнем случае делается гораздо больше работы, ведь в случае count(*) не надо строить огромный курсор и передавать ещё более огромный результат клиенту. Марк, большое спасибо за explain :) А каким образом можно увеличить скорость фетча ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2010, 13:20 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
db2testА каким образом можно увеличить скорость фетча ? select * from ... FOR READ ONLY и тут читать: Specifying row blocking to reduce overhead Т.е. в зависимости от типа соединения делать побольше aslheapsz или rqrioblk. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2010, 18:43 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
Развернул базу с тестовой таблицей на 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'е получается быстрее ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2010, 16:48 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
Mark Barinstein select * from ... FOR READ ONLY и тут читать: Specifying row blocking to reduce overhead Т.е. в зависимости от типа соединения делать побольше aslheapsz или rqrioblk. Спасибо. Правда никого эффекта не произошло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2010, 16:51 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
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 и разными процентами блочности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2010, 14:19 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinНу, можно ещё с block based bufferpool поиграться. Проведите тесты с размером блока в extentsize и разными процентами блочности. Спасибо, помогло. Намотаю на ус :) При BLOCKSIZE=EXTENTSIZE и размере block area в 10% от размера буферпула результаты сравнялись. При этом, чем меньше BLOCKSIZE относительно EXTENTSIZE, тем хуже время выполнения запроса. Компрессия таблицы также сравнивает результат с FILESYSTEM CACHING и блочным БП. Т.е кролики это не только ценный мех компрессия не только уменьшает объем БД (у меня таблицы жмутся в 4-5 раз), но и значительно улучшает перфоманс запросов с sequential I/O. Но в любом случае получить результат лучше, чем у FILESYSTEM CACHING, не получилось :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2010, 14:05 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
Извиняюсь, что вмешиваюсь. Как я понимаю Вы используете AIX в качестве операционной системы, это так? На уровне ОС настраивался ли асинхронный ввод-вывод? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2010, 17:03 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
Провел тест еще раз, но уже на другом хосте (тоже 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2010, 14:13 |
|
||
|
RAID vs. DB2_PARALLEL_IO
|
|||
|---|---|---|---|
|
#18+
CamperИзвиняюсь, что вмешиваюсь. Как я понимаю Вы используете AIX в качестве операционной системы, это так? На уровне ОС настраивался ли асинхронный ввод-вывод? Специально c AIO ничего не делал. В системе 120 aioservers, iostat очередей к AIO не показывает. А что конкретно там настраивать кроме числа aioserver'ов ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2010, 14:18 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=36880752&tid=1602477]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
65ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
2ms |
| others: | 297ms |
| total: | 447ms |

| 0 / 0 |
