ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / "RAW device" vs "BLOCK device"
16 сообщений из 66, страница 3 из 3
  3  все
"RAW device" vs "BLOCK device"
    #35256317
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
vasilisКак это рандомные ?
index_range_scan - это чтение группы подряд лежащих индексных страниц с ключами (чтение диапазона значений ключа, тот же битвин). И для этого (чтения диапазона) даже не нужно подниматься на верхний уровень после каждой листьевой страницы - у них есть ссылки на следующую страницу своего уровня.
Другое дело, что диапазоны могут быть разными, в том числе и маленькими, и вполне помещаться на одну или две страницы и для этого RA не понадобится. Но для большого диапазона (или индексов с большими ключами, а значит большим количеством страниц) это будет очень даже полезно. Вот тут и должен помочь прогноз оптимизатора по количеству возвращаемых строк.Позапускал селекты
select pk where pk = (ra не используется),
Код: plaintext
1.
2.
ixda-RA    idx-RA     da-RA      RA-pgsused lchwaits  
0          0          0          0          0

pk between (используется).
Код: plaintext
1.
ixda-RA    idx-RA     da-RA      RA-pgsused lchwaits  
3          0          0          3          0
...
Рейтинг: 0 / 0
15.04.2008, 14:38
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35256390
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
vasilis
Я НЕ "думаю разница очень сильно сократится" в данном тесте при использовании каких бы то ни было параметров RA (хотя всегда стараюсь его использовать по максимуму :)


Я думаю что она достаточно сильно сократится, так как при данном окружении
ИМХО процессор успевает пересортировать данные быстрее чем производится чтение с диска.


В случае с блочными устройствами мы уже имеем упреждающее чтение в буфере ядра.
Я не вижу никаких других факторов при проведении тестирования, которые могли бы дать такую разницу в производительности.
Когда мы исключаем этот буфер при работе с RAW мы конфигурации ставим в неравные условия.
Эту неравность нужно компенсировать за счет упреждающего чтения в БД.

В конечном итоге это не только компенсация, а и оптимизация, так как informix гораздо лучше
знает когда лучше использовать упреждающее чтение чем ядро.

На время постройки индексов рекомендую попробовать :
RA_PAGES 64
RA_THRESHOLD 32
Для чистоты эксперемента в обеих конфигурациях как RAW & BLOCK.
...
Рейтинг: 0 / 0
15.04.2008, 14:59
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35256408
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
onstat- vasilis
onstat-Фрагментированы ли таблицы?
вроде нет, но для блочных устройств было то же самое - не забывайте, тест проводился именно для сравнения ("RAW device" vs "BLOCK device"), а не для поиска оптимального времени загрузки.
Я правильно говорю, svat2 ? :)

Правильно то оно правильно, вот только нет никакого толку от эксперемента,
когда значения погрешности превосходит значения измеряемой величины.
Прежде чем сравнивать производительность BLOCK vs RAW нужно оценить
уровень погрешностей.
Абсолютная величина и причины недозагрузки процессора(на постройке индекса)
вносит гораздо большее влияние на производительность(погрешность) чем разница в производительности BLOCK vs RAW.
В иделале постройку индекса нужно сравнивать при нагрузке процессоров ~100%.
Тогда разница во времени будет показательна.
По этой причине и возник вопрос.
Что то разговор зашел в сторону, но мне все же кажется, что вы уже начала путать причину и следствие.
Для наглядности пример (очень условный :)
Сравнивают кто быстрее - велосипедист или мотоциклист по трем разным отрезкам дороги.
В итоге вы хотите, чтобы время пути сравнивалось только в том случае, когда физическая нагрузка велосипедиста и мотоциклиста были одинаковые, а она просто не может быть одинаковой при всех прочих равных параметрах.
Тест то ведь был (при всей его условности и неправильных, на мой взляд, некоторых параметрах) ОДИНАКОВЫМ для BLOCK и RAW.
...
Рейтинг: 0 / 0
15.04.2008, 15:03
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35256455
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
onstat- vasilis
Я НЕ "думаю разница очень сильно сократится" в данном тесте при использовании каких бы то ни было параметров RA (хотя всегда стараюсь его использовать по максимуму :)

Я думаю что она достаточно сильно сократится, так как при данном окружении
ИМХО процессор успевает пересортировать данные быстрее чем производится чтение с диска.
В случае с блочными устройствами мы уже имеем упреждающее чтение в буфере ядра.
Я не вижу никаких других факторов при проведении тестирования, которые могли бы дать такую разницу в производительности.
Если бы RA давал прирост в 2-3 раза, то его бы и так включили по-умолчанию.
Никогда он такого не даст, т.к. упреждающее чтение есть еще и в контроллере диска/рейда.

onstat-Когда мы исключаем этот буфер при работе с RAW мы конфигурации ставим в неравные условия.
Эту неравность нужно компенсировать за счет упреждающего чтения в БД.
На время постройки индексов рекомендую попробовать :
RA_PAGES 64
RA_THRESHOLD 32
Для чистоты эксперемента в обеих конфигурациях как RAW & BLOCK.
Вы невнимательны. Еще в первом посте было указано, что
RA_PAGES 64 # Number of pages to attempt to read ahead
RA_THRESHOLD 48 # Number of pages left before next group
и именно поэтому я и говорил, что изменение этого параметра сильно не поможет, т.к. RA и так хорошо использовался. Все, что вы говорите про упреждающее чтение, правильно, но уже было сделано и использовалось в тесте.
...
Рейтинг: 0 / 0
15.04.2008, 15:15
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35256462
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
Журавлев Денис vasilisКак это рандомные ?
index_range_scan - это чтение группы подряд лежащих индексных страниц с ключами (чтение диапазона значений ключа, тот же битвин). И для этого (чтения диапазона) даже не нужно подниматься на верхний уровень после каждой листьевой страницы - у них есть ссылки на следующую страницу своего уровня.
Другое дело, что диапазоны могут быть разными, в том числе и маленькими, и вполне помещаться на одну или две страницы и для этого RA не понадобится. Но для большого диапазона (или индексов с большими ключами, а значит большим количеством страниц) это будет очень даже полезно. Вот тут и должен помочь прогноз оптимизатора по количеству возвращаемых строк.Позапускал селекты
select pk where pk = (ra не используется),
Код: plaintext
1.
2.
ixda-RA    idx-RA     da-RA      RA-pgsused lchwaits  
0          0          0          0          0
pk between (используется).
Код: plaintext
1.
ixda-RA    idx-RA     da-RA      RA-pgsused lchwaits  
3          0          0          3          0

Ну, дык, что и требовалось :)
Спасибо, что не поленился проверить.
Правда, меня смущает, почему ixda-RA только 3 страницы. Даже по умолчанию должно быть 4.
Значит этот механизм еще более интеллектуальней, чем мы думаем.
...
Рейтинг: 0 / 0
15.04.2008, 15:17
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35256500
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
svat2 onstat-
Сколько процов?
Фрагментированы ли таблицы?
Настраивался ли PDQ?

1) Проц 1, 4х-ядерный (я указывал выше)
2) дайте запрос, данные которого Вас интересуют по этому поводу
3) кроме нижеуказанного, ничего не делалось
Код: plaintext
1.
2.
3.
$ onstat -c | grep -i pdq
MAX_PDQPRIORITY   90    # Maximum allowed pdqpriority
DS_NONPDQ_QUERY_MEM 128         # Non PDQ query memory (Kbytes)


в переменные окружения
PSORT_NPROCS=3

в онконфиг
MULTIPROCESSOR 1
NUMCPUVPS 3

SHMVIRTSIZE 640000
RA_PAGES 64
RA_THRESHOLD 32
DS_TOTAL_MEMORY 512000

в сессии:
set pdqpriority 100;

Нагрузка на процессоры должна подняться минимум до 25% ( одно ядро будет загруженно полностью сортировкой).

Остальное в зависимости от фрагментации, по ссылке на FAQ, которую привел vasilis
...
Рейтинг: 0 / 0
15.04.2008, 15:26
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35256530
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
vasilis

Вы невнимательны. Еще в первом посте было указано, что
RA_PAGES 64 # Number of pages to attempt to read ahead
RA_THRESHOLD 48 # Number of pages left before next group
и именно поэтому я и говорил, что изменение этого параметра сильно не поможет, т.к. RA и так хорошо использовался. Все, что вы говорите про упреждающее чтение, правильно, но уже было сделано и использовалось в тесте.

Согласен, недосмотрел.
...
Рейтинг: 0 / 0
15.04.2008, 15:32
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35256938
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svat2
Гость
vasilis
Думаю, что на постройке индексов можно сильно сократить время, если использовать FAQ
http://www.sql.ru/faq/faq_topic.aspx?fid=858
В данном случае нужно распараллелить сортировки, а для этого добавить несколько tempdbs (еще 3), увеличить SHMVIRTSIZE (а для 11-й версии есть даже спецпараметр для сортировок), установить PDQPRIORITY и PSORT_NPROCS=4. Кстати, еще сделать CPUVP=4 (по кол-ву ядер)


Согласно рекомендациям по вышеприведенной ссылке (по возможности) изменю настройки и проведу тест еще раз к завтрашнему утру.

vasilis
тест проводился именно для сравнения ("RAW device" vs "BLOCK device"), а не для поиска оптимального времени загрузки.
Я правильно говорю, svat2 ? :)


Да, правильно. Т.к. в тесте менялся по сути только 1 важный параметр при равных остальных условиях.
Теперь же я вижу, что есть у комьюнити желание "модифицировать" условия теста таким образом, чтобы "дать RAW-устройствам себя показать". Поскольку есть подозрения, что изначально, возможно, эти условия способствовали BLOCK-устройствам. Согласен и сделаю это.
...
Рейтинг: 0 / 0
15.04.2008, 17:30
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35257079
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
С блочным устройством вызовы такие:

Код: 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.
> onstat -d
44f6d950 1      1      0          51200      14683                 PO-B  /dev/mapper/system-datadbs

> ll /dev/mapper/system-datadbs
brw-rw----  1 informix informix 253, 3 2008-04-15 17:15 /dev/mapper/system-datadbs

> onstat -c|grep -i _io
DIRECT_IO       1       # Use direct I/O for chunks (Yes = 1, No = 0)
# strace -p 4880 -p 4885 -p 4887 -p 4888 -p 4889 -p 4890 -p 4891  -f 2>&1|grep io_
[pid  4880] io_submit(1077178368, 1, {...}) = 1
[pid  4880] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  4880] io_submit(1077178368, 1, {...}) = 1
[pid  4880] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  4880] io_submit(1077178368, 1, {...}) = 1
[pid  4880] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  4880] io_submit(1077178368, 1, {...}) = 1
[pid  4880] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  4880] io_submit(1077178368, 1, {...}) = 1
[pid  4880] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  4880] io_submit(1077178368, 1, {...}) = 1
[pid  4880] io_submit(1077178368, 1, {...}) = 1
[pid  4880] io_submit(1077178368, 1, {...}) = 1
[pid  4880] io_submit(1077178368, 1, {...}) = 1
[pid  4880] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 4


> onstat -c|grep -i _io
DIRECT_IO       0       # Use direct I/O for chunks (Yes = 1, No = 0)
# strace -p 5018 -p 5029 -p 5031 -p 5032 -p 5033 -p 5034 -p 5035  -f 2>&1|grep io_
[pid  5018] io_submit(1077178368, 1, {...}) = 1
[pid  5018] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  5018] io_submit(1077178368, 1, {...}) = 1
[pid  5018] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  5018] io_submit(1077178368, 1, {...}) = 1
[pid  5018] io_submit(1077178368, 1, {...}) = 1
[pid  5018] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 2
...
Рейтинг: 0 / 0
15.04.2008, 18:06
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35259643
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svat2
Гость
Код: plaintext
1.
ПОПРАВКА к описанию теста:
--------------------------
Ошибся в описании. Создание индексов на самом деле производится на 1-м этапе теста
("HPL-load of data"), при создании таблиц, до заливки данных. Т.е. заливка данных
уже происходит в таблицы, на которые "навешены" индексы.
Второй же этап ("Creating indexes, constraints, etc.") поэтому я переименовал
в "Creating constraints, etc."

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Внесенные изменения в настройки:
--------------------------------
1) onconfig
     SHMVIRTSIZE     5000000     # ~"75% of available memory" 
     #  ("BUFFERS 25% of available memory")
     BUFFERPOOL      size=2K,buffers=1000000,lrus=128,lru_min_dirty=94.500000,lru_max_dirty=95.000000
     NUMCPUVPS       4		 # рекомендация "vasilis"
     RA_PAGES        64
     RA_THRESHOLD    32          # рекомендация "onstat-"
     DBSPACETEMP     temp_dbs,temp_dbs1,temp_dbs2,temp_dbs3  # все на том же RAID-10, по 8Гб размером
     DS_TOTAL_MEMORY 4500000     # 90% 	от SHMVIRTSIZE
     DS_MAX_SCANS    6
2) параметры окружения
     PDQPRIORITY=100
     PSORT_NPROCS=3
     # PSORT_DBTEMP не устанавливал за неимением "нескольких физических дисков"
3) в сессии, выполняющие этапы 1 и 2 добавлено
     SET PDQPRIORITY 100;

Имеем:
$ onstat -
IBM Informix Dynamic Server Version 11.10.FC2TL -- On-Line -- Up 00:10:51 -- 7479248 Kbytes

Результаты внес в табличку:
...
Рейтинг: 0 / 0
16.04.2008, 16:40
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35259647
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svat2
Гость
... и нагрузки за период последних 2х тестов:
...
Рейтинг: 0 / 0
16.04.2008, 16:41
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35262907
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
Ну что же, сократили время построения индексов более, чем на 2 часа (30%), т.ч. можно сказать, что своего добились :)
т.е. показали, что при соответствующих условиях RAW-устройства проявляют себя немного лучше, чем вначале, но разница все равно остается колоссальная, именно для ЭТОГО теста.

P.S. Кстати, ранее я советовал не только NUMCPUVPS=4, а и сделать одинаковый с ним PSORT_NPROCS=4, т.е. количество потоков сортировки м.б. равным числу усл.процов.
"RAW device" vs "BLOCK device"
...
Рейтинг: 0 / 0
17.04.2008, 18:34
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35263039
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
vasilisНу что же, сократили время построения индексов более, чем на 2 часа (30%), т.ч. можно сказать, что своего добились :)
т.е. показали, что при соответствующих условиях RAW-устройства проявляют себя немного лучше, чем вначале, но разница все равно остается колоссальная, именно для ЭТОГО теста.

P.S. Кстати, ранее я советовал не только NUMCPUVPS=4, а и сделать одинаковый с ним PSORT_NPROCS=4, т.е. количество потоков сортировки м.б. равным числу усл.процов.
"RAW device" vs "BLOCK device"

ИМХО дополнительное ядро на сортировке производительности не добавит, по нагрузке на процессоры видно что даже 3 ядра не загружены.

Мне интересно из за чего такая разница в обьеме дискового ввода вывода.

ИМХО дополнительная буферизация гдето всетаки имеется в случае с блочными устройствами
именно она и есть причиной такой разницы в производительности.

Если под informix отдать 6 Гб на блочных устройствах ИМХО производительность упадет.


2 svat2 У Вас случаем не завалялся рузультат onstat -D по результатам каждого из трех
этапов для всех тестов.
...
Рейтинг: 0 / 0
17.04.2008, 20:06
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35264105
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svat2
Гость
onstat- Если под informix отдать 6 Гб на блочных устройствах ИМХО производительность упадет.


Вы невнимательны. Под Информикс в последних тестах УЖЕ было выделено ~7,5 Gb. Хотя и операционной системе осталось ~500 Mb для своих нужд (в т.ч. и буферизации).


onstat-
2 svat2 У Вас случаем не завалялся рузультат onstat -D по результатам каждого из трех
этапов для всех тестов.

Сейчас выполняю еще цикл тестов с PSORT_NPROCS=4 и поэтапной регистрацией "onstat -D". О результатах сообщу позже.
...
Рейтинг: 0 / 0
18.04.2008, 12:07
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35266950
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svat2
Гость
Выполнил еще цикл тестов с предыдущим конфигом и с PSORT_NPROCS=4 (было =3).
Результаты см. в прикрепленном файле.
ЗЫ. поэтапный "onstat -D" для обоих тестов см. в следующем сообщении...
...
Рейтинг: 0 / 0
20.04.2008, 14:47
| Ответить | Цитировать | Написать  
"RAW device" vs "BLOCK device"
    #35266955
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svat2
Гость
Вот "onstat -D" по результатам каждого из трех этапов для обоих тестов.
...
Рейтинг: 0 / 0
20.04.2008, 14:55
| Ответить | Цитировать | Написать  
16 сообщений из 66, страница 3 из 3
  3  все
Форумы / Informix [игнор отключен] [закрыт для гостей] / "RAW device" vs "BLOCK device"
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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