powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Informix [игнор отключен] [закрыт для гостей] / "RAW device" vs "BLOCK device"
66 сообщений из 66, показаны все 3 страниц
"RAW device" vs "BLOCK device"
    #35254246
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
= = = Может быть кому-то будет интересно. = = =

Провел серию экспериментов по тестированию скорости работы Информикса
на RAW- и BLOCK- устройствах.

Код: plaintext
1.
 Цель и методика: 
--------------------
Исследовать влияние на скорость выполнения тестового задания 2х факторов:
1) дбспейсы лежат на блочных или RAW устройствах;
(В первом случае в качестве пространств данных используются LVM-тома на
неформатированном разделе диска. Во втором - с помощью команды ОС raw
создаются RAW-устройства, "смотрящие" на те же LVM-тома. В качестве дбспейсов
используются симлинки на них [RAW-устройства].)
2) переменная onconfig'a DIRECT_IO равна 0 или 1 ( # Use direct I/O for chunks (Yes = 1, No = 0)).

Для этого было выполнено 4 одинаковых тестовых задания для всех комбинаций пп.1,2.

Каждый тест по сути представлял собой некую "эмуляцию" вгрузки БД с помощью
утилиты dbimport.
А именно:
Имелись данные, выгруженные из рабочей БД на другом сервере (под IDS 7.31,
выгрузка производилась оригинальным скриптом, использующим в своей работе
утилиты HPL, dbschema).
Затем, другим скриптом, производилась их вгрузка.
Объем вгружаемых данных (в выгруженном состоянии): ~21Gb.

Никакие другие процессы в системе во время проведения экспериментов сколь-нибудь
значительной нагрузки на процессор и I/O-подсистему не оказывали.


Код: plaintext
1.
 Условия эксперимента: 
---------------------

Код: 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.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
 1 ) Софт
   1 . 1 ) IBM Informix Dynamic Server Version  11 . 10 .FC2TL -- On-Line -- 3265680 Kbytes
   1 . 2 ) Debian GNU/Linux  4 . 0  (Etch),  64 -bit

 2 ) Железо
   2 . 1 ) под все дбспейсы Информикса выделен RAID- 10  из 4шт. SATA HDD 
       (контроллер "LSI MegaRAID SAS 84016E")
   2 . 2 ) CPU:  1  x (Intel(R) Xeon(R) CPU X5365 @  3 .00GHz), 4х-ядерный
   2 . 3 ) RAM: 8Gb

 3 ) Настройки ОС
   3 . 1 ) дисковое пространство под все дбспейсы Информикса организовано в виде 
       логических томов LVM2 на неформатированном дисковом массиве (см. п. 2 . 1 )
   3 . 2 ) ядро версии  2 . 6 . 23 . 16 

 4 ) Настройки Информикса
   4 . 1 ) onconfig
      4 . 1 . 1 ) BUFFERPOOL      size=2K,buffers= 1000000 ,lrus= 128 ,lru_min_dirty= 94 . 500000 ,lru_max_dirty= 95 . 000000 
            CKPTINTVL        60 
            (значения "накручены" для исключения срабатывания LRU-writes, ибо это замедляет тест в разы)
      4 . 1 . 2 ) PHYSFILE         6291000          # Physical log file size (Kbytes)
            LOGFILES         50               # Number of logical log files
            LOGSIZE          100000           # Logical log size (Kbytes)
            MULTIPROCESSOR   1                #  0  for single-processor,  1  for multi-processor
            NUMCPUVPS        3                # Number of user (cpu) vps
            NUMAIOVPS        1      	# Используется KAIO
            PHYSBUFF         256              # Physical log buffer size (Kbytes)
            LOGBUFF          256              # Logical log buffer size (Kbytes)
            CLEANERS         10               # Number of buffer cleaner processes
            SHMVIRTSIZE      786432 
            RA_PAGES         64               # Number of pages to attempt to read ahead
            RA_THRESHOLD     48               # Number of pages left before next group
            BTSCANNER       num= 1 ,priority=low,threshold= 50000 ,rangesize= 10000 

   4 . 2 ) onstat -d (неважное удалил)

	Dbspaces
	number nchunks  pgsize   flags    owner    name
	 1        1          2048      N  B     informix rootdbs
	 2        1          2048      N  B     informix phys_dbs
	 3        1          2048      N  B     informix log_dbs
	 4        1          2048      N TB     informix temp_dbs
	 5        7          2048      N  B     informix data_dbs
	  5  active,  2047  maximum
	
	Chunks
	chunk/dbs size     
	 1        1    750000    
	 2        2    3145700   
	 3        3    4134000   
	 4        4    4134000   
	 5        5    8268000   
	 6        5    8268000   
	 7        5    8268000   
	 8        5    8268000   
	 9        5    8268000   
	 10       5    8268000   
	 11       5    8268000   

   4 . 3 ) plconfig.std настроен на макс. производительность HPL методом предварительных 
       последовательных испытаний при разных значениях параметров

 5 ) блочные и RAW-устройства (для примера - "одно из ..."):
   
   # ls -l /dev/raw/raw00 /dev/mapper/informix00-ifx00
   brw-rw---- 1 informix informix 252,  0 Apr 10 15:48 /dev/mapper/informix00-ifx00
   crw-rw---- 1 informix informix 162,  1 Apr  9 13:38 /dev/raw/raw00

   # raw -q /dev/raw/raw00
   /dev/raw/raw1:  bound to major  252 , minor  0 


Код: plaintext
1.
 Процедура проведения: 
---------------------

Всю процедуру вгрузки можно условно разбить на 3 этапа (выполняются без паузы в скрипте):
1) "HPL-load of data" - создание БД без логирования, создание таблиц и последовательная
вгрузка данных в таблицы с помощью HPL;
2) "Creating indexes, constraints, etc." - создание индексов, констрейнтов, SP, вьюх,
триггеров и т.п. Короче - все остальное :)
3) "UPDATE STATISTICS" - последовательность команд для начального сбора статистики
по вгруженным данным
Код: plaintext
1.
2.
3.
4.
  SET PDQPRIORITY 100;
  UPDATE STATISTICS LOW for TABLE;
  SET PDQPRIORITY 0;
  UPDATE STATISTICS for PROCEDURE;

Результаты эксперимента представлены во вложенном XLS-файле .

***
Мучаюсь вопросом: доп. кеширование обращения Информикса к диску средствами ОС -
все таки "зло" (согласно мануалу и явно более длинным чекпойнтам в моем тесте) .
Или же все-таки - "добро" - исходя из общей производительности? :)
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254324
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2
Мучаюсь вопросом: доп. кеширование обращения Информикса к диску средствами ОС -
все таки "зло" (согласно мануалу и явно более длинным чекпойнтам в моем тесте) .
Или же все-таки - "добро" - исходя из общей производительности? :)
Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс.
Если полезная работа вашей системы заключается в update statistics, то безусловно вам следует использовать блокдевайс , в ином случае нужны другие тесты.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254359
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2 4.1.1) BUFFERPOOL size=2K,buffers=1000000,lrus=128,lru_min_dirty=94.500000,lru_max_dirty=95.000000
CKPTINTVL 60
(значения "накручены" для исключения срабатывания LRU-writes, ибо это замедляет тест в разы)

зачем???? уменьшили бы размер базы, если дождаться не можете.

buffers=1000000
2G - получается буфер информикса в тестах с рау, и ~8G при блочных.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254365
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Журавлев Денис
Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс.


Не совсем понял суть реплики. Точнее - совсем не понял. :)
Но на всякий пожарный поспешу уточнить, что максимально длинные чекпойнты наблюдались
на этапе "HPL-load of data", который по длительности примерно сопоставим для всех тестов.


Журавлев Денис

Если полезная работа вашей системы заключается в update statistics, то безусловно вам следует использовать блокдевайс , в ином случае нужны другие тесты.

Не спорю и на истину в последней инстанции не претендую :).
ЗЫ. за пример "других тестов" скажу спасибо
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254386
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2

3) Настройки ОС
3.1) дисковое пространство под все дбспейсы Информикса организовано в виде
логических томов LVM2 на неформатированном дисковом массиве (см. п.2.1)
3.2) ядро версии 2.6.23.16

ядро с hugetlb ?
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254462
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Журавлев Денис svat2 4.1.1) BUFFERPOOL size=2K,buffers=1000000,lrus=128,lru_min_dirty=94.500000,lru_max_dirty=95.000000
CKPTINTVL 60
(значения "накручены" для исключения срабатывания LRU-writes, ибо это замедляет тест в разы)

зачем???? уменьшили бы размер базы, если дождаться не можете.


отвечаю:
1) см. "для исключения срабатывания LRU-writes". На самом деле, когда включается LRU, сброс буфферов "захлебывается": чекпойнты - до 20 минут длительностью, общая производительность страдает в результате.
2) уменьшать базу - значит получить бОльшее влияние кэширования данных. ИМХО, это "портит" результаты 2-го и 3-го этапов.
3) при меньшем объеме данных разница во времени между тестами могла быть ненаглядной, т.е. попадать в область "погрешности измерений"
4) да и вообще - влом было. :)

Журавлев Денис
buffers=1000000
2G - получается буфер информикса в тестах с рау, и ~8G при блочных.

Именно.
В системе - 8G RAM. "Простаивают" из них ~5. Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254469
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Журавлев Денис svat2

3) Настройки ОС
3.1) дисковое пространство под все дбспейсы Информикса организовано в виде
логических томов LVM2 на неформатированном дисковом массиве (см. п.2.1)
3.2) ядро версии 2.6.23.16

ядро с hugetlb ?

Код: plaintext
1.
2.
3.
4.
$ cat /usr/src/linux/.config | grep -i tlb
CONFIG_SWIOTLB=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254533
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2
Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ.

На системах DSS, OLAP где идет постоянное полное сканирование
или заливка блоков подряд вы получили предсказуемый результат.
Вы бы получили такой же прирост в производительности при последовательном чтении-записи файла на диск с включенным и отключенным кешем ФС.

Для наглядности попробуйте второй тест по индесному поиску
и update записей.

Чем больше уклон системы в cторону OLTP, тем лучше себя покажут настоящие raw.

У меня на старых ядрах 2.2.Х и жестком OLTP и блочных девайсах informix
непредсказуемо падал вплоть до обращения по нулевому указателю,
или десятками минут находился в в ступоре syscpy>=95% idle=0,
после перевода на RAW начал летать месяцами без посадки будто-бы все заменили,
хотя на самомом деле я только перемапил ссылки с блочных девайсов на raw.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254554
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор
2) переменная onconfig'a DIRECT_IO равна 0 или 1 ( # Use direct I/O for chunks (Yes = 1, No = 0)).


Хочу обратить внимание на еще одни момент который я познал работая уже над OpenDSA.

Если у Вас дефалтовые настройки ФС( блок 4 К) и размер страницы БД 2к
Linux не откроет файлы в режиме Direct_IO.

Соотвественно ИМХО Informix не сможет использовать DIRECT_IO на ФС.
Нужно согласовывать размер блока БД и размер блока ФС.

Непосредственно с Informix я это не тестировал( системные вызовы теже),
У кого будет возможность обратите внимание, думаю где то в доке об этом
тоже должно быть написано.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254621
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
onstat-
На системах DSS, OLAP где идет постоянное полное сканирование
или заливка блоков подряд вы получили предсказуемый результат.
Вы бы получили такой же прирост в производительности при последовательном чтении-записи файла на диск с включенным и отключенным кешем ФС.

Какой из Ваших слов следует сделать вывод? Что в моем случае сконфигурированные 2Гб
буферов Информикса функцию кеширования "выполняют из рук вон плохо" / "вообще не
для того предназначены" / "их недостаточно" / "стратегия кеширования неподходящая" (раз доп.
кеширование средствами ОС в разы ускоряет, к примеру, те же операции создания индексов/констрейнтов)?

Уже говорилось, что чистых "OLTP" или "DSS"-систем не существует. Т.е. любую систему
можно описать, как на Х% - OLTP и на Y% - DSS (где X + Y = 100)
Отсюда вопрос:
При каком примерно соотношении X к Y можно ожидать эффект от RAW-устройств?


onstat-
Для наглядности попробуйте второй тест по индесному поиску
и update записей.


Подумаю над этим.
Какую методику порекомендуете применить и каков результат следует ожидать по
Вашему мнению?

onstat-
У меня на старых ядрах 2.2.Х ...

"згадала баба, як дівкою була..." (с) :)
... у меня тоже 7.31 с ядром 2.4.х на блочных по году почти летали...
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254638
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2= = = Может быть кому-то будет интересно. = = =
Провел серию экспериментов по тестированию скорости работы Информикса
на RAW- и BLOCK- устройствах.
Спасибо за информацию.
Эксперименты жизнь нас многих заставляет делать, вот только потом систематизировать, описать и, главное, представить на суд решаются не многие.
А ведь такого рода чужой опыт может сэкономить другим часы (дни) или просто показать чужие ошибки или дать пищу для размышлений и толкнуть на новые опыты.
svat2Каждый тест по сути представлял собой некую "эмуляцию" вгрузки БД
Признаюсь, не сразу понял слово "вгрузки" :) Как то раньше не встречал.
Есть нормальное русское слово "загрузка" (и есть "выгрузка").

svat2Объем вгружаемых данных (в выгруженном состоянии): ~21Gb.
снимаю шляпу перед такими объемами тестирования.
Хотя вызывает сомнения - зачем тратить столько времени (по 6-12 часов). Мне кажется, что и на объемах на порядок меньше можно сделать те же выводы просто уменьшив размер буферного пула.
Зато за "сэкономленное" время можно провести и другие интересные тесты.

svat2
size=2K,buffers=1000000,lrus=128,lru_min_dirty=94.500000,lru_max_dirty=95.000000
CKPTINTVL 60
PHYSFILE 6291000 # Physical log file size (Kbytes)
(значения "накручены" для исключения срабатывания LRU-writes, ибо это замедляет тест в разы)
Но такие нежизненные "накрутки" лишают тестирование, во многом, и практического смысла.
Мне это очень напомнило знаменитого "сферического коня в вакууме", сорри.
Непонятно, куда потом результаты "приспособить", в чем их полезность ?
Кстати, мне еще кажется что "накрутки" полезны только на первом этапе (загрузки данных), а вот для построения индексов и US они более вредны, чем полезны (IMHO).
svat2Результаты эксперимента представлены во вложенном XLS-файле
Да, результаты в любом случае впечатлили. Не ожидал такой разницы...
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254640
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
onstat-
Если у Вас дефалтовые настройки ФС( блок 4 К) и размер страницы БД 2к
Linux не откроет файлы в режиме Direct_IO.

Соотвественно ИМХО Informix не сможет использовать DIRECT_IO на ФС.
Нужно согласовывать размер блока БД и размер блока ФС.


Мы говорим о дбспейсах на "подготовленных" устройствах (файлы на ФС) или все-таки продолжаем обсуждать тестовую конфигурацию, где дбспейсы расположены на LVM-томах? Там нет никакой ФС и, соотв. само понятие по идее неприменимо...
ЗЫ. Де-факто тесты показали, что действительно, опция DIRECT_IO видимого действия не оказывает, что и хотелось проверить.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254641
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2 Журавлев Денис
Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс.
Не совсем понял суть реплики. Точнее - совсем не понял. :)
"Аналогично" (С) :)
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254643
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2 Журавлев Денис
buffers=1000000
2G - получается буфер информикса в тестах с рау, и ~8G при блочных.
Именно.
В системе - 8G RAM. "Простаивают" из них ~5. Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ.
А что мешает использовать всю доступную память под буферный пул Информикса ?
У вас же 64-разрядная версия.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254644
Фотография sysmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat- автор
2) переменная onconfig'a DIRECT_IO равна 0 или 1 ( # Use direct I/O for chunks (Yes = 1, No = 0)).


Если у Вас дефалтовые настройки ФС( блок 4 К) и размер страницы БД 2к
Linux не откроет файлы в режиме Direct_IO.

Соотвественно ИМХО Informix не сможет использовать DIRECT_IO на ФС.
Нужно согласовывать размер блока БД и размер блока ФС.

Непосредственно с Informix я это не тестировал( системные вызовы теже),
У кого будет возможность обратите внимание, думаю где то в доке об этом
тоже должно быть написано.

Вот что сказано в доке.
Код: plaintext
Прямой ввод-вывод можно задать при помощи нового параметра конфигурации DIRECT_IO. Если файловая система поддерживает прямой ввод-вывод для размера страниц, используемого для чанка пространства базы данных,
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254653
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2ЗЫ. Де-факто тесты показали, что действительно, опция DIRECT_IO видимого действия не оказывает, что и хотелось проверить.
Что довольно таки странно, не правда ли ?
Мне кажется (но доки не читал), что при включенном KAIO это уже и так включено...
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254663
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vasilis
Спасибо за информацию.
А ведь такого рода чужой опыт может сэкономить другим часы (дни) или просто показать чужие ошибки или дать пищу для размышлений и толкнуть на новые опыты.

потому и опубликовал :)
Глядишь, кому-то поможет, а кто-то и к истине подтолкнет, высказав свое мнение...


vasilis
Признаюсь, не сразу понял слово "вгрузки" :) Как то раньше не встречал.
Есть нормальное русское слово "загрузка" (и есть "выгрузка").


сори, уж привык именно к такому сленгу. Не было правильных гуру-учителей :)


vasilis svat2Объем вгружаемых данных (в выгруженном состоянии): ~21Gb.
... зачем тратить столько времени (по 6-12 часов)...

Уже ответил Денису. См. выше.


vasilis svat2
size=2K,buffers=1000000,lrus=128,lru_min_dirty=94.500000,lru_max_dirty=95.000000
CKPTINTVL 60
PHYSFILE 6291000 # Physical log file size (Kbytes)
(значения "накручены" для исключения срабатывания LRU-writes, ибо это замедляет тест в разы)
Но такие нежизненные "накрутки" лишают тестирование, во многом, и практического смысла.
Мне это очень напомнило знаменитого "сферического коня в вакууме", сорри.
Непонятно, куда потом результаты "приспособить", в чем их полезность ?

Полезность в том, чтобы ЗНАТЬ, что на этапе лавинообразной ЗАгрузки данных (HPL это делает с успехом) ВЫГОДНЕЕ с точки зрения скорости загрузки не допускать срабатывания LRU.
Думаю, это знание - тоже суть опыт и польза в таких случаях.
ЗЫ. Да, "накрутки нежизненные". Но и характер нагрузки - соответствующий...

vasilis
Кстати, мне еще кажется что "накрутки" полезны только на первом этапе (загрузки данных), а вот для построения индексов и US они более вредны, чем полезны (IMHO).

Да, "накрутки" делались исключительно для 1-го этапа. Просто для остальных этапов они уже не менялись, дабы не усложнять процедуру тестирования (не вносить элемент ручного вмешательства в настройки по ходу теста).
А в чем их "вредность" на этапах 2 и 3? Хотелось бы знать...
ЗЫ. я не описал, но на 2м и 3м этапе длина чекпойнтов не превышала 1 сек. В основном - 0.

vasilisДа, результаты в любом случае впечатлили. Не ожидал такой разницы...

Слюший, я сам нэ ажыдал, да?! (с) :)
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35254824
victor16
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Руководство администратора IBM Informix Dynamic ServerВ системах UNIX вы можете повысить производительность буферизованных файлов, используемых для чанков пространств базы данных, за счет использования прямого ввода-вывода.
... Прямой ввод-вывод позволяет обойти буферы файловой системы, благодаря чему обеспечивается более высокая эффективность чтения и записи диска. Прямой ввод-вывод можно задать при помощи параметра конфигурации DIRECT_IO. Если файловая система поддерживает прямой ввод-вывод для размера страниц, используемого для чанка пространства баз данных, и вы используете прямой ввод-вывод, производительность обработки в случае буферизованных файлов может приблизиться к производительности небуферизованных устройств, используемых для чанков пространств базы данных.
... Как повысить производительность пространств базы данных на основе буферизованных файлов за счет использования прямого ввода-вывода: 1. Убедитесь, что у вас используется прямой ввод-вывод и файловая система поддерживает прямой ввод-вывод для размера страниц, используемого для чанка пространства баз данных. 2. Включите прямой ввод-вывод, задав для параметра конфигурации DIRECT_IO значение 1.

В связи с вышесказанным, так как Вы в тесте не использовали cooked файлы ФС,
DIRECT_IO не должно было оказать никакого влияния, что собственно и показали тесты.

С уважением,
Виктор
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255086
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2отвечаю:
1) см. "для исключения срабатывания LRU-writes". На самом деле, когда включается LRU, сброс буфферов "захлебывается": чекпойнты - до 20 минут длительностью, общая производительность страдает в результате.
вобще-то должно быть наоборот, и чекпоинты у вас должны быть неблокирующими.


svat2
В системе - 8G RAM. "Простаивают" из них ~5. Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ.Так отдайте их информиксу, увеличте буферс.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255093
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-
Если у Вас дефалтовые настройки ФС( блок 4 К) и размер страницы БД 2к
Linux не откроет файлы в режиме Direct_IO. ты это о чем? Про mkfs -b block-size?
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255121
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис onstat-
Если у Вас дефалтовые настройки ФС( блок 4 К) и размер страницы БД 2к
Linux не откроет файлы в режиме Direct_IO. ты это о чем? Про mkfs -b block-size?

Да.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255126
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilis svat2 Журавлев Денис
Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс.
Не совсем понял суть реплики. Точнее - совсем не понял. :)
"Аналогично" (С) :)Представьте субд делает миллион инсертов за 10 десять минут, затем следует чекпоинт 5 сек., или за 20 мин и следует чекпоинт 3 сек., lru работали "в два раза дольше", т.е. чистить надо было меньше.

Покажите online.log, вы настроили размер логического и физического лога как советует информикс, для максимальной эффективности при новых чекпоинтах?
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255195
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sysmaster

Вот что сказано в доке.
Код: plaintext
Прямой ввод-вывод можно задать при помощи нового параметра конфигурации DIRECT_IO. Если файловая система поддерживает прямой ввод-вывод для размера страниц, используемого для чанка пространства базы данных,


Денис правильный вопрос задал.
Даже если файловая система поддерживает,
Direct-IO возможен только в случае если размер блока ФС меньше либо равен и кратен размеру страницы БД.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255323
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2 onstat-
На системах DSS, OLAP где идет постоянное полное сканирование
или заливка блоков подряд вы получили предсказуемый результат.
Вы бы получили такой же прирост в производительности при последовательном чтении-записи файла на диск с включенным и отключенным кешем ФС.

Какой из Ваших слов следует сделать вывод? Что в моем случае сконфигурированные 2Гб
буферов Информикса функцию кеширования "выполняют из рук вон плохо" / "вообще не
для того предназначены" / "их недостаточно" / "стратегия кеширования неподходящая" (раз доп.
кеширование средствами ОС в разы ускоряет, к примеру, те же операции создания индексов/констрейнтов)?

Уже говорилось, что чистых "OLTP" или "DSS"-систем не существует. Т.е. любую систему
можно описать, как на Х% - OLTP и на Y% - DSS (где X + Y = 100)
Отсюда вопрос:
При каком примерно соотношении X к Y можно ожидать эффект от RAW-устройств?


Рассказываю логику работы, или откуда берутся тормоза.

Когда производится индексный поиск, база с помощью упреждающего чтения
читает индексное дерево в буфера.
Дальше по rowid вычисляется страница с записью и чтение производится блоками по одной странице. Блочное устройство буферизируется в памяти ядра, и ядро пытается произвести упреждающее чтение. То есть вместе с нужным блоком в буфер ядра попадет еще один или несколько последовательно лежащих блоков ( сколько их попадет зависит от параметров ядра которых я не знаю). Вероятность использования этих блоков базой очень низка, и они будут
через некоторое время вытеснены из кеша ядра так и не быв использованными, но пустая
работа по их чтению уже была произведена.
Еще одни момент, касающийся не только OLTP, когда Informix читает данные из настояшего
RAW используется режим DMA и данные попадают в память Informix с минимальным использованием
CPU. В случае же блочного устройства DMA использутся для доставки данных в буферы ядра, а в
память Informix из буфера ядра они попадают через регистры процессора.

В предыдущем тесте попробуйте поиграться с параметрами упреждающего чтения Informix при использовании RAW , думаю разница очень сильно сократится, може быть даже вы получите
выигрыш на RAW если на предыдущих тестах процессор был достаточно сильно нагружен( больше70-80 %).



svat2
onstat-
Для наглядности попробуйте второй тест по индесному поиску
и update записей.


Подумаю над этим.
Какую методику порекомендуете применить и каков результат следует ожидать по
Вашему мнению?



Результат будет зависеть от конфигурации ОС, параметров ядра отвечающих за упреждающее чтение из блочного устройства.

Самая чистая методика это рандомный update записей .
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255400
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-Когда производится индексный поиск, база с помощью упреждающего чтения
читает индексное дерево в буфера.
нонсенс.
Мы читаем одну страницу (корневую), далее смотрим что у нее внутри решаем пойти налево, читаем страницу вообще из другого гигабайта, тут не может быть упреждающего чтения, оно только мешает.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255447
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис onstat-Когда производится индексный поиск, база с помощью упреждающего чтения
читает индексное дерево в буфера.
нонсенс.
Мы читаем одну страницу (корневую), далее смотрим что у нее внутри решаем пойти налево, читаем страницу вообще из другого гигабайта, тут не может быть упреждающего чтения, оно только мешает.

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

Хотя могут быть случаи когда оно и не используется.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255525
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Журавлев Денис
buffers=1000000
2G - получается буфер информикса в тестах с рау, и ~8G при блочных.

Журавлев Денис svat2
В системе - 8G RAM. "Простаивают" из них ~5. Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ.Так отдайте их информиксу, увеличте буферс.

vasilis
А что мешает использовать всю доступную память под буферный пул Информикса ?
У вас же 64-разрядная версия.

Та я только за! :)
Вот, отдал почти всю память под Информикс и выполнил тест на RAW-devices:

$ onstat -c | grep BUFFERPOOL
BUFFERPOOL size=2K,buffers=3000000,lrus=128,lru_min_dirty=94.500000,lru_max_dirty=95.000000

$ onstat -
IBM Informix Dynamic Server Version 11.10.FC2TL -- On-Line -- Up 00:04:53 -- 7737844 Kbytes

результаты:
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255579
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2


Та я только за! :)
Вот, отдал почти всю память под Информикс и выполнил тест на RAW-devices:

$ onstat -c | grep BUFFERPOOL
BUFFERPOOL size=2K,buffers=3000000,lrus=128,lru_min_dirty=94.500000,lru_max_dirty=95.000000

$ onstat -
IBM Informix Dynamic Server Version 11.10.FC2TL -- On-Line -- Up 00:04:53 -- 7737844 Kbytes

результаты:

Крутите упреждающее чтение в Informix и скорость посторйки индексов на raw сильно увеличится,
Также будут использоваться ресурсы процессора для сортировки, которые раньше уходили
на переброску данных между кешами в случае с блочными девайсами .

Еще хорошо бы sar -ud увидеть для всех вариантов особенно на постройке индексов.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255681
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: 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.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
> onstat -c |grep -i direct_io
DIRECT_IO       0       # Use direct I/O for chunks (Yes = 1, No = 0)
informix@nag:~> onstat -g glo

Individual virtual processors:
 vp    pid       class       usercpu   syscpu    total   
 1     2444      cpu         2.52      0.39      2.91    
 2     2445      adm         0.00      0.00      0.00    
 3     2446      lio         0.00      0.00      0.00    
 4     2447      pio         0.00      0.00      0.00    
 5     2448      aio         0.00      0.00      0.00    
 6     2449      msc         0.00      0.00      0.00    
 7     2450      aio         0.00      0.00      0.00    
 8     2451      aio         0.00      0.00      0.00    
 9     2452      aio         0.00      0.00      0.00    
 10    2453      aio         0.00      0.00      0.00    
 11    2454      aio         0.00      0.00      0.00    
                 tot         2.52      0.39      2.91    

# strace -p 2444 -p 2448 -p 2450 -p 2451 -p 2452 -p 2453 -p 2454  -f 2>&1|grep io_
мощно инстертим и в конце onmode -c
стрейс выдает пустоту

# strace -p 2444 -p 2448 -p 2450 -p 2451 -p 2452 -p 2453 -p 2454  -f 2>&1|grep write
мощно инстертим и в конце onmode -c
[pid  2448] pwrite64(256, "\202\231\0\0\1\0i\375\360\0\1\10\330\3d\0\0\0\0\0\0\0\0"..., 2048, 80482304) = 2048
[pid  2448] pwrite64(256, "\203\231\0\0\1\0K\374\272\0\1\10\0\3\24\2\0\0\0\0\0\0\0"..., 2048, 80484352 <unfinished ...>
[pid  2451] pwrite64(256, "I\231\0\0\1\0J\374\0\0\4\10\30\0\344\7\0\0\0\0\0\0\0\0"..., 2048, 80365568 <unfinished ...>
[pid  2450] pwrite64(256, "\202\231\0\0\1\0\204\374\374\0\1\10\10\4\4\0\0\0\0\0\0"..., 2048, 80482304 <unfinished ...>
[pid  2451] <... pwrite64 resumed> )    = 2048
[pid  2448] <... pwrite64 resumed> )    = 2048
[pid  2450] <... pwrite64 resumed> )    = 2048


> onstat -c |grep -i direct_io
DIRECT_IO       1       # Use direct I/O for chunks (Yes = 1, No = 0)
> onstat -g glo
 vp    pid       class       usercpu   syscpu    total   
 1     2559      cpu         2.45      0.43      2.88    
 2     2560      adm         0.00      0.00      0.00    
 3     2561      lio         0.00      0.00      0.00    
 4     2562      pio         0.00      0.00      0.00    
 5     2563      aio         0.00      0.00      0.00    
 6     2564      msc         0.00      0.00      0.00    
 7     2565      aio         0.00      0.00      0.00    
 8     2566      aio         0.00      0.00      0.00    
 9     2567      aio         0.00      0.00      0.00    
 10    2568      aio         0.00      0.00      0.00    
 11    2569      aio         0.00      0.00      0.00    


# strace -p 2559 -p 2563 -p 2565 -p 2566 -p 2567 -p 2568 -p 2569  -f 2>&1|grep write
мощно инстертим и в конце onmode -c
показывает запись в онлайнлог
[pid  2559] write(6, "12:10:36  ", 10)  = 10
[pid  2559] write(6, "Booting Language <spl> from modu"..., 37) = 37

# strace -p 2559 -p 2563 -p 2565 -p 2566 -p 2567 -p 2568 -p 2569  -f 2>&1|grep io_
мощно инстертим и в конце onmode -c
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {}{0, 1000000}) = 0
[pid  2559] io_getevents(1077178368, 1, 100, {}{0, 1000000}) = 0
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 1000000}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 1000000}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 1000000}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 1000000}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {}{0, 1000000}) = 0
[pid  2559] io_getevents(1077178368, 1, 100, {}{0, 1000000}) = 0
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 1000000}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 1000000}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_submit(1077178368, 1, {...}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1
[pid  2559] io_getevents(1077178368, 1, 100, {...}{0, 0}) = 1

Причем работает уже cpu а не aio как в первом случае.
-----------------------------------------------------------------------------------------------------------------------------------------
А вазелин еще надо заслужить.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255684
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
onstat-
В предыдущем тесте попробуйте поиграться с параметрами упреждающего чтения Informix при использовании RAW , думаю разница очень сильно сократится, може быть даже вы получите
выигрыш на RAW если на предыдущих тестах процессор был достаточно сильно нагружен( больше70-80 %).


Вот данные загрузки системы/процессора/РЕЙДов по последнему тесту:
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255693
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис вы настроили размер логического и физического лога как советует информикс, для максимальной эффективности при новых чекпоинтах?
А как советует информикс ?
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255750
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilis Журавлев Денис вы настроили размер логического и физического лога как советует информикс, для максимальной эффективности при новых чекпоинтах?
А как советует информикс ?

Я криво выразился видимо.

online.log
15:34:54 Performance Advisory: Based on the current workload, the logical log space might be too small to
accommodate the time it takes to flush the buffer pool.
15:34:54 Results: The server might block transactions during checkpoints.
15:34:54 Action: If transactions are blocked during the checkpoint, increase the size of the
logical log space to at least 46200 KB.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255773
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2

Покажите-ка
# rpm -qa libaio
libaio-0.3.104-3
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255774
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2 onstat-
В предыдущем тесте попробуйте поиграться с параметрами упреждающего чтения Informix при использовании RAW , думаю разница очень сильно сократится, може быть даже вы получите
выигрыш на RAW если на предыдущих тестах процессор был достаточно сильно нагружен( больше70-80 %).


Вот данные загрузки системы/процессора/РЕЙДов по последнему тесту:

На посторойке индексов слишком низкая нагрузка на CPU, думаю общее время постройки
можно сократить в десятки раз если таблицы фрагментированы.
Если не фрагментированы прирост раза в 1,5 -2 получить тоже можно.

Сколько процов?
Фрагментированы ли таблицы?
Настраивался ли PDQ?
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255805
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat- Журавлев Денис onstat-Когда производится индексный поиск, база с помощью упреждающего чтения читает индексное дерево в буфера.
нонсенс.
Мы читаем одну страницу (корневую), далее смотрим что у нее внутри решаем пойти налево, читаем страницу вообще из другого гигабайта, тут не может быть упреждающего чтения, оно только мешает.
То что для индексов используется упреждающее чтение написано в доке,
я когдато уже цитировал .
Хотя могут быть случаи когда оно и не используется.
Господа, вы оба правы :)
RA используется при чтении группы листьевых страниц индекса, когда нужно прочитать ключ "от и до".
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255828
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilisГоспода, вы оба правы :)
RA используется при чтении группы листьевых страниц индекса, когда нужно прочитать ключ "от и до".ключ? индекс ты хотел сказать.

В терминах офтопа index_range_scan VS index_fast_full_scan

Таким образом прав я в случае oltp должны быть index_range_scan и никакого ra не будет
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255835
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис onstat -c |grep -i direct_io
DIRECT_IO 0 # Use direct I/O for chunks (Yes = 1, No = 0)
informix@nag:~> onstat -g glo
...
# strace -p 2444 -p 2448 -p 2450 -p 2451 -p 2452 -p 2453 -p 2454 -f 2>&1|grep io_
мощно инстертим и в конце onmode -c
стрейс выдает пустоту
# strace -p 2444 -p 2448 -p 2450 -p 2451 -p 2452 -p 2453 -p 2454 -f 2>&1|grep write
мощно инстертим и в конце onmode -c
[pid 2448] pwrite64(256, "\202\231\0\0\1\0i\375\360\0\1\10\330\3d\0\0\0\0\0\0\0\0"..., 2048, 80482304) = 2048
...
> onstat -c |grep -i direct_io
DIRECT_IO 1 # Use direct I/O for chunks (Yes = 1, No = 0)
...
# strace -p 2559 -p 2563 -p 2565 -p 2566 -p 2567 -p 2568 -p 2569 -f 2>&1|grep write
мощно инстертим и в конце onmode -c
показывает запись в онлайнлог
[pid 2559] write(6, "12:10:36 ", 10) = 10
[pid 2559] write(6, "Booting Language <spl> from modu"..., 37) = 37

# strace -p 2559 -p 2563 -p 2565 -p 2566 -p 2567 -p 2568 -p 2569 -f 2>&1|grep io_
мощно инстертим и в конце onmode -c
[pid 2559] io_submit(1077178368, 1, {...}) = 1
[pid 2559] io_getevents(1077178368, 1, 100, {}{0, 1000000}) = 0
...
Денис, если не трудно, теперь своими словами сформулируй - что ты хотел показать (доказать) этими данными ? Или кому что доказывал ?
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255862
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Журавлев Денис
Покажите online.log

Вложил.
Добавлю к этому:

Код: 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.
$ onstat -l | head -20
IBM Informix Dynamic Server Version 11.10.FC2TL -- On-Line -- Up 14:01:32 -- 7737844 Kbytes

Physical Logging
Buffer bufused  bufsize  numpages   numwrits   pages/io
  P-2  0        128      3931584    32507      120.95
      phybegin         physize    phypos     phyused    %used
      2:53             3145500    638203     0          0.00

Logical Logging
Buffer bufused  bufsize  numrecs    numpages   numwrits   recs/pages pages/io
  L-1  0        128      1989109    168977     4374       11.8       38.6
        Subsystem    numrecs    Log Space used
        OLDRSAM      1988196    336565196
        HA           913        32868

address          number   flags    uniqid   begin                size     used    %used
1edb8ae50        4        U-B----  4        3:53                50000    50000   100.00
1edb8aeb8        5        U-B----  5        3:50053             50000    50000   100.00
1edb8af20        6        U-B----  6        3:100053            50000    50000   100.00
1edb8af88        7        U-B----  7        3:150053            50000    50000   100.00
1edb73c50        8        U-B----  8        3:200053            50000    50000   100.00
1edb73cb8        9        U-B----  9        3:250053            50000    50000   100.00
1edb73d20        10       U-B----  10       3:300053            50000    50000   100.00
1edb73d88        11       U-B----  11       3:350053            50000    50000   100.00
1edb73df0        12       U-B----  12       3:400053            50000    50000   100.00
1edb73e58        13       U-B----  13       3:450053            50000    50000   100.00
 1edb73ec0        14       U-B----  14       3:500053            50000    50000   100.00
1edb73f28        15       U-B----  15       3:550053            50000    50000   100.00
1edb73f90        16       U-B----  16       3:600053            50000    50000   100.00 
1ed149278        17       U---C-L  17       3:650053            50000    37703    75.41
1ed1492e0        18       A------  0        3:700053            50000        0     0.00
1ed149348        19       A------  0        3:750053            50000        0     0.00


Код: plaintext
1.
2.
3.
4.
5.
6.
$ cat /var/log/informix/online.log | grep "Complete," | tail -4

21:33:40  Logical Log 13 Complete, timestamp: 0x43a8647e.
 07:36:34  Logical Log 14 Complete, timestamp: 0xaf6fb201.
07:36:50  Logical Log 15 Complete, timestamp: 0xaf7bb462.
08:01:49  Logical Log 16 Complete, timestamp: 0xaf87c129. 
Журавлев Денис вы настроили размер логического и физического лога как советует информикс, для максимальной эффективности при новых чекпоинтах?

Можно цитату/ссылку/страницу мануала, где можно ознакомиться с теми советами, которые имеются ввиду?
Я учитывал на всякий случай только рекомендацию делать размер физ.лога как минимут 110% от общего объема BUFFERS. Размер же лога транзакций брался с потолка.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255868
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilisДенис, если не трудно, теперь своими словами сформулируй - что ты хотел показать (доказать) этими данными ? Или кому что доказывал ?
Я слабо разбираюсь в программировании таких вещей.
И я считал что в случае (DIRECT_IO 1) я увижу pwrite64 с флагом O_DIRECT. Но оказалось что там совсем другой системный вызов (io_submit). Я искренне удивлен, и буду разбираться что происходит, сюда я это написал как информация к размышлению ну например для onstat-.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255873
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис vasilisГоспода, вы оба правы :)
RA используется при чтении группы листьевых страниц индекса, когда нужно прочитать ключ "от и до".ключ? индекс ты хотел сказать.
В терминах офтопа index_range_scan VS index_fast_full_scan
Таким образом прав я в случае oltp должны быть index_range_scan и никакого ra не будет
А почему при index_range_scan не может быть RA ? В чем принципиальная разница ?
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255886
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilisА почему при index_range_scan не может быть RA ? В чем принципиальная разница ?может, только зачем? читаются рандомные страницы, RA будет безполезен.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255899
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис vasilisДенис, если не трудно, теперь своими словами сформулируй - что ты хотел показать (доказать) этими данными ? Или кому что доказывал ?
Я слабо разбираюсь в программировании таких вещей.
И я считал что в случае (DIRECT_IO 1) я увижу pwrite64 с флагом O_DIRECT. Но оказалось что там совсем другой системный вызов (io_submit). Я искренне удивлен, и буду разбираться что происходит, сюда я это написал как информация к размышлению ну например для onstat-.
Спасибо. Теперь я перестал чувствовать себя... идиотом :))
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255906
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2
Можно цитату/ссылку/страницу мануала, где можно ознакомиться с теми советами, которые имеются ввиду?
Я учитывал на всякий случай только рекомендацию делать размер физ.лога как минимут 110% от общего объема BUFFERS. Размер же лога транзакций брался с потолка.
Читаете online.log при старте IBM Informix Dynamic Server Started.
В аттаче старта нет.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255934
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис vasilisА почему при index_range_scan не может быть RA ? В чем принципиальная разница ?может, только зачем? читаются рандомные страницы, RA будет безполезен.
Как это рандомные ?
index_range_scan - это чтение группы подряд лежащих индексных страниц с ключами (чтение диапазона значений ключа, тот же битвин). И для этого (чтения диапазона) даже не нужно подниматься на верхний уровень после каждой листьевой страницы - у них есть ссылки на следующую страницу своего уровня.
Другое дело, что диапазоны могут быть разными, в том числе и маленькими, и вполне помещаться на одну или две страницы и для этого RA не понадобится. Но для большого диапазона (или индексов с большими ключами, а значит большим количеством страниц) это будет очень даже полезно. Вот тут и должен помочь прогноз оптимизатора по количеству возвращаемых строк.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255937
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Журавлев Денис
Покажите-ка
# rpm -qa libaio
libaio-0.3.104-3

Код: plaintext
1.
# dpkg -l | grep libaio
ii  libaio1                           0.3.106-3                            linux kernel aio access library - shared lib
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35255943
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис vasilisДенис, если не трудно, теперь своими словами сформулируй - что ты хотел показать (доказать) этими данными ? Или кому что доказывал ?
Я слабо разбираюсь в программировании таких вещей.
И я считал что в случае (DIRECT_IO 1) я увижу pwrite64 с флагом O_DIRECT. Но оказалось что там совсем другой системный вызов (io_submit). Я искренне удивлен, и буду разбираться что происходит, сюда я это написал как информация к размышлению ну например для onstat-.


Спасибо, это действительно полезная информация.
Мне тоже в этом нужно еще разбираться.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35256009
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-
В предыдущем тесте попробуйте поиграться с параметрами упреждающего чтения Informix при использовании RAW , думаю разница очень сильно сократится, може быть даже вы получите
выигрыш на RAW если на предыдущих тестах процессор был достаточно сильно нагружен( больше70-80 %).
Я НЕ "думаю разница очень сильно сократится" в данном тесте при использовании каких бы то ни было параметров RA (хотя всегда стараюсь его использовать по максимуму :)

onstat-На посторойке индексов слишком низкая нагрузка на CPU, думаю общее время постройки можно сократить в десятки раз если таблицы фрагментированы.
Если не фрагментированы прирост раза в 1,5 -2 получить тоже можно.
Думаю, что на постройке индексов можно сильно сократить время, если использовать FAQ
http://www.sql.ru/faq/faq_topic.aspx?fid=858
В данном случае нужно распараллелить сортировки, а для этого добавить несколько tempdbs (еще 3), увеличить SHMVIRTSIZE (а для 11-й версии есть даже спецпараметр для сортировок), установить PDQPRIORITY и PSORT_NPROCS=4. Кстати, еще сделать CPUVP=4 (по кол-ву ядер)
onstat-Сколько процов?
Один, но 4-х ядерный, если я правильно помню
onstat-Фрагментированы ли таблицы?
вроде нет, но для блочных устройств было то же самое - не забывайте, тест проводился именно для сравнения ("RAW device" vs "BLOCK device"), а не для поиска оптимального времени загрузки.
Я правильно говорю, svat2 ? :)
onstat-Настраивался ли PDQ?
Только для US.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35256088
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilis
onstat-Фрагментированы ли таблицы?
вроде нет, но для блочных устройств было то же самое - не забывайте, тест проводился именно для сравнения ("RAW device" vs "BLOCK device"), а не для поиска оптимального времени загрузки.
Я правильно говорю, svat2 ? :)


Правильно то оно правильно, вот только нет никакого толку от эксперемента,
когда значения погрешности превосходит значения измеряемой величины.

Прежде чем сравнивать производительность BLOCK vs RAW нужно оценить
уровень погрешностей.

Абсолютная величина и причины недозагрузки процессора(на постройке индекса)
вносит гораздо большее влияние на производительность(погрешность) чем разница в производительности BLOCK vs RAW.

В иделале постройку индекса нужно сравнивать при нагрузке процессоров ~100%.
Тогда разница во времени будет показательна.

По этой причине и возник вопрос.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35256271
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)
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35256293
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Журавлев Денис
Читаете online.log при старте IBM Informix Dynamic Server Started.
В аттаче старта нет.

последний старт был с такими "ругательствами":

Код: 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.
Mon Apr 14 21:34:41 2008

21:34:41  Event alarms enabled.  ALARMPROG = '/usr/local/informix/etc/alarmprogram.sh'
21:34:41  Booting Language <c> from module <>
21:34:41  Loading Module <CNULL>
21:34:41  Booting Language <builtin> from module <>
21:34:41  Loading Module <BUILTINNULL>
21:34:45  DR: DRAUTO is 0 (Off)
21:34:45  DR: ENCRYPT_HDR is 0 (HDR encryption Disabled)
21:34:45  Event notification facility epoll enabled.
21:34:45  IBM Informix Dynamic Server Version 11.10.FC2TL Software Serial Number AAA#B000000
21:34:46  IBM Informix Dynamic Server Initialized -- Shared Memory Initialized.
21:34:46  Started 1 btree scanners.
21:34:46  Btree scanner threshold set at 50000.
21:34:46  Btree scanner range scan size set to 10000.
21:34:46  Btree scanner ALICE mode set to 0.
21:34:46  Physical Recovery Started at Page (2:2965167).
21:34:47  Physical Recovery Complete: 0 Pages Examined, 0 Pages Restored.
21:34:47  Logical Recovery Started.
21:34:47  10 recovery worker threads will be started.
21:34:50  Logical Recovery has reached the transaction cleanup phase.
21:34:50  Logical Recovery Complete.
          0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks

21:34:52  Onconfig parameter BUFFERPOOL modified from
size=2K,buffers=3500000,lrus=128,lru_min_dirty=94.500000,lru_max_dirty=95.000000 to
size=2K,buffers=3000000,lrus=128,lru_min_dirty=94.500000,lru_max_dirty=95.000000.
21:34:52  Dataskip is now OFF for all dbspaces
21:34:52  On-Line Mode
21:34:54  SCHAPI: Started dbScheduler thread.
21:34:54  SCHAPI: Started 2 dbWorker threads.
21:35:05  Booting Language <spl> from module <>
21:35:05  Loading Module <SPLNULL>
21:35:52  Checkpoint Completed:  duration was 0 seconds.
21:35:52  Mon Apr 14 - loguniq 14, logpos 0x4929018, timestamp: 0x43afecc1 Interval: 3639
...
Рейтинг: 0 / 0
"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
"RAW device" vs "BLOCK device"
    #35256390
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilis
Я НЕ "думаю разница очень сильно сократится" в данном тесте при использовании каких бы то ни было параметров RA (хотя всегда стараюсь его использовать по максимуму :)


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


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

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

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

Правильно то оно правильно, вот только нет никакого толку от эксперемента,
когда значения погрешности превосходит значения измеряемой величины.
Прежде чем сравнивать производительность BLOCK vs RAW нужно оценить
уровень погрешностей.
Абсолютная величина и причины недозагрузки процессора(на постройке индекса)
вносит гораздо большее влияние на производительность(погрешность) чем разница в производительности BLOCK vs RAW.
В иделале постройку индекса нужно сравнивать при нагрузке процессоров ~100%.
Тогда разница во времени будет показательна.
По этой причине и возник вопрос.
Что то разговор зашел в сторону, но мне все же кажется, что вы уже начала путать причину и следствие.
Для наглядности пример (очень условный :)
Сравнивают кто быстрее - велосипедист или мотоциклист по трем разным отрезкам дороги.
В итоге вы хотите, чтобы время пути сравнивалось только в том случае, когда физическая нагрузка велосипедиста и мотоциклиста были одинаковые, а она просто не может быть одинаковой при всех прочих равных параметрах.
Тест то ведь был (при всей его условности и неправильных, на мой взляд, некоторых параметрах) ОДИНАКОВЫМ для BLOCK и RAW.
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35256455
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
"RAW device" vs "BLOCK device"
    #35256462
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
"RAW device" vs "BLOCK device"
    #35256500
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
"RAW device" vs "BLOCK device"
    #35256530
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
"RAW device" vs "BLOCK device"
    #35256938
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
"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
"RAW device" vs "BLOCK device"
    #35259643
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
"RAW device" vs "BLOCK device"
    #35259647
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
... и нагрузки за период последних 2х тестов:
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35262907
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну что же, сократили время построения индексов более, чем на 2 часа (30%), т.ч. можно сказать, что своего добились :)
т.е. показали, что при соответствующих условиях RAW-устройства проявляют себя немного лучше, чем вначале, но разница все равно остается колоссальная, именно для ЭТОГО теста.

P.S. Кстати, ранее я советовал не только NUMCPUVPS=4, а и сделать одинаковый с ним PSORT_NPROCS=4, т.е. количество потоков сортировки м.б. равным числу усл.процов.
"RAW device" vs "BLOCK device"
...
Рейтинг: 0 / 0
"RAW device" vs "BLOCK device"
    #35263039
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
"RAW device" vs "BLOCK device"
    #35264105
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
onstat- Если под informix отдать 6 Гб на блочных устройствах ИМХО производительность упадет.


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


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

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


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