Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Informix [игнор отключен] [закрыт для гостей] / "RAW device" vs "BLOCK device" / 25 сообщений из 66, страница 1 из 3
  1  все
14.04.2008, 17:37
    #35254246
svat2
svat2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
= = = Может быть кому-то будет интересно. = = =

Провел серию экспериментов по тестированию скорости работы Информикса
на 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
| Ответить | Цитировать | Написать  
14.04.2008, 18:01
    #35254324
Журавлев Денис
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
svat2
Мучаюсь вопросом: доп. кеширование обращения Информикса к диску средствами ОС -
все таки "зло" (согласно мануалу и явно более длинным чекпойнтам в моем тесте) .
Или же все-таки - "добро" - исходя из общей производительности? :)
Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс.
Если полезная работа вашей системы заключается в update statistics, то безусловно вам следует использовать блокдевайс , в ином случае нужны другие тесты.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2008, 18:22
    #35254359
Журавлев Денис
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
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
| Ответить | Цитировать | Написать  
14.04.2008, 18:25
    #35254365
svat2
svat2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
Журавлев Денис
Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс.


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


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

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

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

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

ядро с hugetlb ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2008, 19:19
    #35254462
svat2
svat2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
Журавлев Денис 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
| Ответить | Цитировать | Написать  
14.04.2008, 19:24
    #35254469
svat2
svat2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
Журавлев Денис 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
| Ответить | Цитировать | Написать  
14.04.2008, 20:03
    #35254533
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
svat2
Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ.

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

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

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

У меня на старых ядрах 2.2.Х и жестком OLTP и блочных девайсах informix
непредсказуемо падал вплоть до обращения по нулевому указателю,
или десятками минут находился в в ступоре syscpy>=95% idle=0,
после перевода на RAW начал летать месяцами без посадки будто-бы все заменили,
хотя на самомом деле я только перемапил ссылки с блочных девайсов на raw.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2008, 20:18
    #35254554
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
автор
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
| Ответить | Цитировать | Написать  
14.04.2008, 21:17
    #35254621
svat2
svat2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
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
| Ответить | Цитировать | Написать  
14.04.2008, 21:33
    #35254638
vasilis
vasilis
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
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
| Ответить | Цитировать | Написать  
14.04.2008, 21:34
    #35254640
svat2
svat2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
onstat-
Если у Вас дефалтовые настройки ФС( блок 4 К) и размер страницы БД 2к
Linux не откроет файлы в режиме Direct_IO.

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


Мы говорим о дбспейсах на "подготовленных" устройствах (файлы на ФС) или все-таки продолжаем обсуждать тестовую конфигурацию, где дбспейсы расположены на LVM-томах? Там нет никакой ФС и, соотв. само понятие по идее неприменимо...
ЗЫ. Де-факто тесты показали, что действительно, опция DIRECT_IO видимого действия не оказывает, что и хотелось проверить.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2008, 21:35
    #35254641
vasilis
vasilis
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
svat2 Журавлев Денис
Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс.
Не совсем понял суть реплики. Точнее - совсем не понял. :)
"Аналогично" (С) :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2008, 21:38
    #35254643
vasilis
vasilis
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
svat2 Журавлев Денис
buffers=1000000
2G - получается буфер информикса в тестах с рау, и ~8G при блочных.
Именно.
В системе - 8G RAM. "Простаивают" из них ~5. Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ.
А что мешает использовать всю доступную память под буферный пул Информикса ?
У вас же 64-разрядная версия.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2008, 21:39
    #35254644
sysmaster
sysmaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
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
| Ответить | Цитировать | Написать  
14.04.2008, 21:43
    #35254653
vasilis
vasilis
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
svat2ЗЫ. Де-факто тесты показали, что действительно, опция DIRECT_IO видимого действия не оказывает, что и хотелось проверить.
Что довольно таки странно, не правда ли ?
Мне кажется (но доки не читал), что при включенном KAIO это уже и так включено...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.04.2008, 21:56
    #35254663
svat2
svat2
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
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
| Ответить | Цитировать | Написать  
15.04.2008, 01:14
    #35254824
victor16
victor16
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
Руководство администратора IBM Informix Dynamic ServerВ системах UNIX вы можете повысить производительность буферизованных файлов, используемых для чанков пространств базы данных, за счет использования прямого ввода-вывода.
... Прямой ввод-вывод позволяет обойти буферы файловой системы, благодаря чему обеспечивается более высокая эффективность чтения и записи диска. Прямой ввод-вывод можно задать при помощи параметра конфигурации DIRECT_IO. Если файловая система поддерживает прямой ввод-вывод для размера страниц, используемого для чанка пространства баз данных, и вы используете прямой ввод-вывод, производительность обработки в случае буферизованных файлов может приблизиться к производительности небуферизованных устройств, используемых для чанков пространств базы данных.
... Как повысить производительность пространств базы данных на основе буферизованных файлов за счет использования прямого ввода-вывода: 1. Убедитесь, что у вас используется прямой ввод-вывод и файловая система поддерживает прямой ввод-вывод для размера страниц, используемого для чанка пространства баз данных. 2. Включите прямой ввод-вывод, задав для параметра конфигурации DIRECT_IO значение 1.

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

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


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

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

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

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


Денис правильный вопрос задал.
Даже если файловая система поддерживает,
Direct-IO возможен только в случае если размер блока ФС меньше либо равен и кратен размеру страницы БД.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
15.04.2008, 11:00
    #35255323
onstat-
onstat-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
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
| Ответить | Цитировать | Написать  
15.04.2008, 11:19
    #35255400
Журавлев Денис
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
"RAW device" vs "BLOCK device"
onstat-Когда производится индексный поиск, база с помощью упреждающего чтения
читает индексное дерево в буфера.
нонсенс.
Мы читаем одну страницу (корневую), далее смотрим что у нее внутри решаем пойти налево, читаем страницу вообще из другого гигабайта, тут не может быть упреждающего чтения, оно только мешает.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Informix [игнор отключен] [закрыт для гостей] / "RAW device" vs "BLOCK device" / 25 сообщений из 66, страница 1 из 3
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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