Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
= = = Может быть кому-то будет интересно. = = = Провел серию экспериментов по тестированию скорости работы Информикса на RAW- и BLOCK- устройствах. Код: plaintext 1. 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. Код: plaintext 1. Всю процедуру вгрузки можно условно разбить на 3 этапа (выполняются без паузы в скрипте): 1) "HPL-load of data" - создание БД без логирования, создание таблиц и последовательная вгрузка данных в таблицы с помощью HPL; 2) "Creating indexes, constraints, etc." - создание индексов, констрейнтов, SP, вьюх, триггеров и т.п. Короче - все остальное :) 3) "UPDATE STATISTICS" - последовательность команд для начального сбора статистики по вгруженным данным Код: plaintext 1. 2. 3. 4. Результаты эксперимента представлены во вложенном XLS-файле . *** Мучаюсь вопросом: доп. кеширование обращения Информикса к диску средствами ОС - все таки "зло" (согласно мануалу и явно более длинным чекпойнтам в моем тесте) . Или же все-таки - "добро" - исходя из общей производительности? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 17:37 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2 Мучаюсь вопросом: доп. кеширование обращения Информикса к диску средствами ОС - все таки "зло" (согласно мануалу и явно более длинным чекпойнтам в моем тесте) . Или же все-таки - "добро" - исходя из общей производительности? :) Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс. Если полезная работа вашей системы заключается в update statistics, то безусловно вам следует использовать блокдевайс , в ином случае нужны другие тесты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 18:01 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
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 при блочных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 18:22 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс. Не совсем понял суть реплики. Точнее - совсем не понял. :) Но на всякий пожарный поспешу уточнить, что максимально длинные чекпойнты наблюдались на этапе "HPL-load of data", который по длительности примерно сопоставим для всех тестов. Журавлев Денис Если полезная работа вашей системы заключается в update statistics, то безусловно вам следует использовать блокдевайс , в ином случае нужны другие тесты. Не спорю и на истину в последней инстанции не претендую :). ЗЫ. за пример "других тестов" скажу спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 18:25 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2 3) Настройки ОС 3.1) дисковое пространство под все дбспейсы Информикса организовано в виде логических томов LVM2 на неформатированном дисковом массиве (см. п.2.1) 3.2) ядро версии 2.6.23.16 ядро с hugetlb ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 18:36 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис 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. Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 19:19 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис svat2 3) Настройки ОС 3.1) дисковое пространство под все дбспейсы Информикса организовано в виде логических томов LVM2 на неформатированном дисковом массиве (см. п.2.1) 3.2) ядро версии 2.6.23.16 ядро с hugetlb ? Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 19:24 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2 Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ. На системах DSS, OLAP где идет постоянное полное сканирование или заливка блоков подряд вы получили предсказуемый результат. Вы бы получили такой же прирост в производительности при последовательном чтении-записи файла на диск с включенным и отключенным кешем ФС. Для наглядности попробуйте второй тест по индесному поиску и update записей. Чем больше уклон системы в cторону OLTP, тем лучше себя покажут настоящие raw. У меня на старых ядрах 2.2.Х и жестком OLTP и блочных девайсах informix непредсказуемо падал вплоть до обращения по нулевому указателю, или десятками минут находился в в ступоре syscpy>=95% idle=0, после перевода на RAW начал летать месяцами без посадки будто-бы все заменили, хотя на самомом деле я только перемапил ссылки с блочных девайсов на raw. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 20:03 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
автор 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 я это не тестировал( системные вызовы теже), У кого будет возможность обратите внимание, думаю где то в доке об этом тоже должно быть написано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 20:18 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
onstat- На системах DSS, OLAP где идет постоянное полное сканирование или заливка блоков подряд вы получили предсказуемый результат. Вы бы получили такой же прирост в производительности при последовательном чтении-записи файла на диск с включенным и отключенным кешем ФС. Какой из Ваших слов следует сделать вывод? Что в моем случае сконфигурированные 2Гб буферов Информикса функцию кеширования "выполняют из рук вон плохо" / "вообще не для того предназначены" / "их недостаточно" / "стратегия кеширования неподходящая" (раз доп. кеширование средствами ОС в разы ускоряет, к примеру, те же операции создания индексов/констрейнтов)? Уже говорилось, что чистых "OLTP" или "DSS"-систем не существует. Т.е. любую систему можно описать, как на Х% - OLTP и на Y% - DSS (где X + Y = 100) Отсюда вопрос: При каком примерно соотношении X к Y можно ожидать эффект от RAW-устройств? onstat- Для наглядности попробуйте второй тест по индесному поиску и update записей. Подумаю над этим. Какую методику порекомендуете применить и каков результат следует ожидать по Вашему мнению? onstat- У меня на старых ядрах 2.2.Х ... "згадала баба, як дівкою була..." (с) :) ... у меня тоже 7.31 с ядром 2.4.х на блочных по году почти летали... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 21:17 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
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-файле Да, результаты в любом случае впечатлили. Не ожидал такой разницы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 21:33 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
onstat- Если у Вас дефалтовые настройки ФС( блок 4 К) и размер страницы БД 2к Linux не откроет файлы в режиме Direct_IO. Соотвественно ИМХО Informix не сможет использовать DIRECT_IO на ФС. Нужно согласовывать размер блока БД и размер блока ФС. Мы говорим о дбспейсах на "подготовленных" устройствах (файлы на ФС) или все-таки продолжаем обсуждать тестовую конфигурацию, где дбспейсы расположены на LVM-томах? Там нет никакой ФС и, соотв. само понятие по идее неприменимо... ЗЫ. Де-факто тесты показали, что действительно, опция DIRECT_IO видимого действия не оказывает, что и хотелось проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 21:34 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2 Журавлев Денис Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс. Не совсем понял суть реплики. Точнее - совсем не понял. :) "Аналогично" (С) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 21:35 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2 Журавлев Денис buffers=1000000 2G - получается буфер информикса в тестах с рау, и ~8G при блочных. Именно. В системе - 8G RAM. "Простаивают" из них ~5. Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ. А что мешает использовать всю доступную память под буферный пул Информикса ? У вас же 64-разрядная версия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 21:38 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 21:39 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2ЗЫ. Де-факто тесты показали, что действительно, опция DIRECT_IO видимого действия не оказывает, что и хотелось проверить. Что довольно таки странно, не правда ли ? Мне кажется (но доки не читал), что при включенном KAIO это уже и так включено... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 21:43 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
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Да, результаты в любом случае впечатлили. Не ожидал такой разницы... Слюший, я сам нэ ажыдал, да?! (с) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2008, 21:56 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Руководство администратора IBM Informix Dynamic ServerВ системах UNIX вы можете повысить производительность буферизованных файлов, используемых для чанков пространств базы данных, за счет использования прямого ввода-вывода. ... Прямой ввод-вывод позволяет обойти буферы файловой системы, благодаря чему обеспечивается более высокая эффективность чтения и записи диска. Прямой ввод-вывод можно задать при помощи параметра конфигурации DIRECT_IO. Если файловая система поддерживает прямой ввод-вывод для размера страниц, используемого для чанка пространства баз данных, и вы используете прямой ввод-вывод, производительность обработки в случае буферизованных файлов может приблизиться к производительности небуферизованных устройств, используемых для чанков пространств базы данных. ... Как повысить производительность пространств базы данных на основе буферизованных файлов за счет использования прямого ввода-вывода: 1. Убедитесь, что у вас используется прямой ввод-вывод и файловая система поддерживает прямой ввод-вывод для размера страниц, используемого для чанка пространства баз данных. 2. Включите прямой ввод-вывод, задав для параметра конфигурации DIRECT_IO значение 1. В связи с вышесказанным, так как Вы в тесте не использовали cooked файлы ФС, DIRECT_IO не должно было оказать никакого влияния, что собственно и показали тесты. С уважением, Виктор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 01:14 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2отвечаю: 1) см. "для исключения срабатывания LRU-writes". На самом деле, когда включается LRU, сброс буфферов "захлебывается": чекпойнты - до 20 минут длительностью, общая производительность страдает в результате. вобще-то должно быть наоборот, и чекпоинты у вас должны быть неблокирующими. svat2 В системе - 8G RAM. "Простаивают" из них ~5. Я лично для себя по результатам тестов делаю вывод, что их лучше ИСПОЛЬЗОВАТЬ.Так отдайте их информиксу, увеличте буферс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 09:57 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
onstat- Если у Вас дефалтовые настройки ФС( блок 4 К) и размер страницы БД 2к Linux не откроет файлы в режиме Direct_IO. ты это о чем? Про mkfs -b block-size? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 10:00 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис onstat- Если у Вас дефалтовые настройки ФС( блок 4 К) и размер страницы БД 2к Linux не откроет файлы в режиме Direct_IO. ты это о чем? Про mkfs -b block-size? Да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 10:10 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
vasilis svat2 Журавлев Денис Чекпоинт длиннее т.к. время меньше работы теста меньше, это не плюс. Не совсем понял суть реплики. Точнее - совсем не понял. :) "Аналогично" (С) :)Представьте субд делает миллион инсертов за 10 десять минут, затем следует чекпоинт 5 сек., или за 20 мин и следует чекпоинт 3 сек., lru работали "в два раза дольше", т.е. чистить надо было меньше. Покажите online.log, вы настроили размер логического и физического лога как советует информикс, для максимальной эффективности при новых чекпоинтах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 10:10 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
sysmaster Вот что сказано в доке. Код: plaintext Денис правильный вопрос задал. Даже если файловая система поддерживает, Direct-IO возможен только в случае если размер блока ФС меньше либо равен и кратен размеру страницы БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 10:27 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
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 записей . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 11:00 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
onstat-Когда производится индексный поиск, база с помощью упреждающего чтения читает индексное дерево в буфера. нонсенс. Мы читаем одну страницу (корневую), далее смотрим что у нее внутри решаем пойти налево, читаем страницу вообще из другого гигабайта, тут не может быть упреждающего чтения, оно только мешает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 11:19 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис onstat-Когда производится индексный поиск, база с помощью упреждающего чтения читает индексное дерево в буфера. нонсенс. Мы читаем одну страницу (корневую), далее смотрим что у нее внутри решаем пойти налево, читаем страницу вообще из другого гигабайта, тут не может быть упреждающего чтения, оно только мешает. То что для индексов используется упреждающее чтение написано в доке, я когдато уже цитировал . Хотя могут быть случаи когда оно и не используется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 11:29 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис 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 результаты: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 11:46 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
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 увидеть для всех вариантов особенно на постройке индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 11:57 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Код: 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. А вазелин еще надо заслужить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:18 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
onstat- В предыдущем тесте попробуйте поиграться с параметрами упреждающего чтения Informix при использовании RAW , думаю разница очень сильно сократится, може быть даже вы получите выигрыш на RAW если на предыдущих тестах процессор был достаточно сильно нагружен( больше70-80 %). Вот данные загрузки системы/процессора/РЕЙДов по последнему тесту: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:18 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис вы настроили размер логического и физического лога как советует информикс, для максимальной эффективности при новых чекпоинтах? А как советует информикс ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:20 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:29 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2 Покажите-ка # rpm -qa libaio libaio-0.3.104-3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:33 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2 onstat- В предыдущем тесте попробуйте поиграться с параметрами упреждающего чтения Informix при использовании RAW , думаю разница очень сильно сократится, може быть даже вы получите выигрыш на RAW если на предыдущих тестах процессор был достаточно сильно нагружен( больше70-80 %). Вот данные загрузки системы/процессора/РЕЙДов по последнему тесту: На посторойке индексов слишком низкая нагрузка на CPU, думаю общее время постройки можно сократить в десятки раз если таблицы фрагментированы. Если не фрагментированы прирост раза в 1,5 -2 получить тоже можно. Сколько процов? Фрагментированы ли таблицы? Настраивался ли PDQ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:34 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
onstat- Журавлев Денис onstat-Когда производится индексный поиск, база с помощью упреждающего чтения читает индексное дерево в буфера. нонсенс. Мы читаем одну страницу (корневую), далее смотрим что у нее внутри решаем пойти налево, читаем страницу вообще из другого гигабайта, тут не может быть упреждающего чтения, оно только мешает. То что для индексов используется упреждающее чтение написано в доке, я когдато уже цитировал . Хотя могут быть случаи когда оно и не используется. Господа, вы оба правы :) RA используется при чтении группы листьевых страниц индекса, когда нужно прочитать ключ "от и до". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:39 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
vasilisГоспода, вы оба правы :) RA используется при чтении группы листьевых страниц индекса, когда нужно прочитать ключ "от и до".ключ? индекс ты хотел сказать. В терминах офтопа index_range_scan VS index_fast_full_scan Таким образом прав я в случае oltp должны быть index_range_scan и никакого ra не будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:42 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис 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 ... Денис, если не трудно, теперь своими словами сформулируй - что ты хотел показать (доказать) этими данными ? Или кому что доказывал ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:43 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Покажите 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. Код: plaintext 1. 2. 3. 4. 5. 6. Можно цитату/ссылку/страницу мануала, где можно ознакомиться с теми советами, которые имеются ввиду? Я учитывал на всякий случай только рекомендацию делать размер физ.лога как минимут 110% от общего объема BUFFERS. Размер же лога транзакций брался с потолка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:47 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
vasilisДенис, если не трудно, теперь своими словами сформулируй - что ты хотел показать (доказать) этими данными ? Или кому что доказывал ? Я слабо разбираюсь в программировании таких вещей. И я считал что в случае (DIRECT_IO 1) я увижу pwrite64 с флагом O_DIRECT. Но оказалось что там совсем другой системный вызов (io_submit). Я искренне удивлен, и буду разбираться что происходит, сюда я это написал как информация к размышлению ну например для onstat-. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:48 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис vasilisГоспода, вы оба правы :) RA используется при чтении группы листьевых страниц индекса, когда нужно прочитать ключ "от и до".ключ? индекс ты хотел сказать. В терминах офтопа index_range_scan VS index_fast_full_scan Таким образом прав я в случае oltp должны быть index_range_scan и никакого ra не будет А почему при index_range_scan не может быть RA ? В чем принципиальная разница ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:49 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
vasilisА почему при index_range_scan не может быть RA ? В чем принципиальная разница ?может, только зачем? читаются рандомные страницы, RA будет безполезен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:52 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис vasilisДенис, если не трудно, теперь своими словами сформулируй - что ты хотел показать (доказать) этими данными ? Или кому что доказывал ? Я слабо разбираюсь в программировании таких вещей. И я считал что в случае (DIRECT_IO 1) я увижу pwrite64 с флагом O_DIRECT. Но оказалось что там совсем другой системный вызов (io_submit). Я искренне удивлен, и буду разбираться что происходит, сюда я это написал как информация к размышлению ну например для onstat-. Спасибо. Теперь я перестал чувствовать себя... идиотом :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:55 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2 Можно цитату/ссылку/страницу мануала, где можно ознакомиться с теми советами, которые имеются ввиду? Я учитывал на всякий случай только рекомендацию делать размер физ.лога как минимут 110% от общего объема BUFFERS. Размер же лога транзакций брался с потолка. Читаете online.log при старте IBM Informix Dynamic Server Started. В аттаче старта нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 12:57 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис vasilisА почему при index_range_scan не может быть RA ? В чем принципиальная разница ?может, только зачем? читаются рандомные страницы, RA будет безполезен. Как это рандомные ? index_range_scan - это чтение группы подряд лежащих индексных страниц с ключами (чтение диапазона значений ключа, тот же битвин). И для этого (чтения диапазона) даже не нужно подниматься на верхний уровень после каждой листьевой страницы - у них есть ссылки на следующую страницу своего уровня. Другое дело, что диапазоны могут быть разными, в том числе и маленькими, и вполне помещаться на одну или две страницы и для этого RA не понадобится. Но для большого диапазона (или индексов с большими ключами, а значит большим количеством страниц) это будет очень даже полезно. Вот тут и должен помочь прогноз оптимизатора по количеству возвращаемых строк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 13:04 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Покажите-ка # rpm -qa libaio libaio-0.3.104-3 Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 13:05 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис vasilisДенис, если не трудно, теперь своими словами сформулируй - что ты хотел показать (доказать) этими данными ? Или кому что доказывал ? Я слабо разбираюсь в программировании таких вещей. И я считал что в случае (DIRECT_IO 1) я увижу pwrite64 с флагом O_DIRECT. Но оказалось что там совсем другой системный вызов (io_submit). Я искренне удивлен, и буду разбираться что происходит, сюда я это написал как информация к размышлению ну например для onstat-. Спасибо, это действительно полезная информация. Мне тоже в этом нужно еще разбираться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 13:06 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 13:25 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
vasilis onstat-Фрагментированы ли таблицы? вроде нет, но для блочных устройств было то же самое - не забывайте, тест проводился именно для сравнения ("RAW device" vs "BLOCK device"), а не для поиска оптимального времени загрузки. Я правильно говорю, svat2 ? :) Правильно то оно правильно, вот только нет никакого толку от эксперемента, когда значения погрешности превосходит значения измеряемой величины. Прежде чем сравнивать производительность BLOCK vs RAW нужно оценить уровень погрешностей. Абсолютная величина и причины недозагрузки процессора(на постройке индекса) вносит гораздо большее влияние на производительность(погрешность) чем разница в производительности BLOCK vs RAW. В иделале постройку индекса нужно сравнивать при нагрузке процессоров ~100%. Тогда разница во времени будет показательна. По этой причине и возник вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 13:48 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
onstat- Сколько процов? Фрагментированы ли таблицы? Настраивался ли PDQ? 1) Проц 1, 4х-ядерный (я указывал выше) 2) дайте запрос, данные которого Вас интересуют по этому поводу 3) кроме нижеуказанного, ничего не делалось Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 14:27 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Читаете 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 14:34 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
vasilisКак это рандомные ? index_range_scan - это чтение группы подряд лежащих индексных страниц с ключами (чтение диапазона значений ключа, тот же битвин). И для этого (чтения диапазона) даже не нужно подниматься на верхний уровень после каждой листьевой страницы - у них есть ссылки на следующую страницу своего уровня. Другое дело, что диапазоны могут быть разными, в том числе и маленькими, и вполне помещаться на одну или две страницы и для этого RA не понадобится. Но для большого диапазона (или индексов с большими ключами, а значит большим количеством страниц) это будет очень даже полезно. Вот тут и должен помочь прогноз оптимизатора по количеству возвращаемых строк.Позапускал селекты select pk where pk = (ra не используется), Код: plaintext 1. 2. pk between (используется). Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 14:38 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
vasilis Я НЕ "думаю разница очень сильно сократится" в данном тесте при использовании каких бы то ни было параметров RA (хотя всегда стараюсь его использовать по максимуму :) Я думаю что она достаточно сильно сократится, так как при данном окружении ИМХО процессор успевает пересортировать данные быстрее чем производится чтение с диска. В случае с блочными устройствами мы уже имеем упреждающее чтение в буфере ядра. Я не вижу никаких других факторов при проведении тестирования, которые могли бы дать такую разницу в производительности. Когда мы исключаем этот буфер при работе с RAW мы конфигурации ставим в неравные условия. Эту неравность нужно компенсировать за счет упреждающего чтения в БД. В конечном итоге это не только компенсация, а и оптимизация, так как informix гораздо лучше знает когда лучше использовать упреждающее чтение чем ядро. На время постройки индексов рекомендую попробовать : RA_PAGES 64 RA_THRESHOLD 32 Для чистоты эксперемента в обеих конфигурациях как RAW & BLOCK. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 14:59 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
onstat- vasilis onstat-Фрагментированы ли таблицы? вроде нет, но для блочных устройств было то же самое - не забывайте, тест проводился именно для сравнения ("RAW device" vs "BLOCK device"), а не для поиска оптимального времени загрузки. Я правильно говорю, svat2 ? :) Правильно то оно правильно, вот только нет никакого толку от эксперемента, когда значения погрешности превосходит значения измеряемой величины. Прежде чем сравнивать производительность BLOCK vs RAW нужно оценить уровень погрешностей. Абсолютная величина и причины недозагрузки процессора(на постройке индекса) вносит гораздо большее влияние на производительность(погрешность) чем разница в производительности BLOCK vs RAW. В иделале постройку индекса нужно сравнивать при нагрузке процессоров ~100%. Тогда разница во времени будет показательна. По этой причине и возник вопрос. Что то разговор зашел в сторону, но мне все же кажется, что вы уже начала путать причину и следствие. Для наглядности пример (очень условный :) Сравнивают кто быстрее - велосипедист или мотоциклист по трем разным отрезкам дороги. В итоге вы хотите, чтобы время пути сравнивалось только в том случае, когда физическая нагрузка велосипедиста и мотоциклиста были одинаковые, а она просто не может быть одинаковой при всех прочих равных параметрах. Тест то ведь был (при всей его условности и неправильных, на мой взляд, некоторых параметрах) ОДИНАКОВЫМ для BLOCK и RAW. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 15:03 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
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 и так хорошо использовался. Все, что вы говорите про упреждающее чтение, правильно, но уже было сделано и использовалось в тесте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 15:15 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис vasilisКак это рандомные ? index_range_scan - это чтение группы подряд лежащих индексных страниц с ключами (чтение диапазона значений ключа, тот же битвин). И для этого (чтения диапазона) даже не нужно подниматься на верхний уровень после каждой листьевой страницы - у них есть ссылки на следующую страницу своего уровня. Другое дело, что диапазоны могут быть разными, в том числе и маленькими, и вполне помещаться на одну или две страницы и для этого RA не понадобится. Но для большого диапазона (или индексов с большими ключами, а значит большим количеством страниц) это будет очень даже полезно. Вот тут и должен помочь прогноз оптимизатора по количеству возвращаемых строк.Позапускал селекты select pk where pk = (ra не используется), Код: plaintext 1. 2. Код: plaintext 1. Ну, дык, что и требовалось :) Спасибо, что не поленился проверить. Правда, меня смущает, почему ixda-RA только 3 страницы. Даже по умолчанию должно быть 4. Значит этот механизм еще более интеллектуальней, чем мы думаем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 15:17 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
svat2 onstat- Сколько процов? Фрагментированы ли таблицы? Настраивался ли PDQ? 1) Проц 1, 4х-ядерный (я указывал выше) 2) дайте запрос, данные которого Вас интересуют по этому поводу 3) кроме нижеуказанного, ничего не делалось Код: plaintext 1. 2. 3. в переменные окружения 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 15:26 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
vasilis Вы невнимательны. Еще в первом посте было указано, что RA_PAGES 64 # Number of pages to attempt to read ahead RA_THRESHOLD 48 # Number of pages left before next group и именно поэтому я и говорил, что изменение этого параметра сильно не поможет, т.к. RA и так хорошо использовался. Все, что вы говорите про упреждающее чтение, правильно, но уже было сделано и использовалось в тесте. Согласен, недосмотрел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 15:32 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
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-устройствам. Согласен и сделаю это. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 17:30 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
С блочным устройством вызовы такие: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2008, 18:06 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 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. Имеем: $ onstat - IBM Informix Dynamic Server Version 11.10.FC2TL -- On-Line -- Up 00:10:51 -- 7479248 Kbytes Результаты внес в табличку: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2008, 16:40 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
... и нагрузки за период последних 2х тестов: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2008, 16:41 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Ну что же, сократили время построения индексов более, чем на 2 часа (30%), т.ч. можно сказать, что своего добились :) т.е. показали, что при соответствующих условиях RAW-устройства проявляют себя немного лучше, чем вначале, но разница все равно остается колоссальная, именно для ЭТОГО теста. P.S. Кстати, ранее я советовал не только NUMCPUVPS=4, а и сделать одинаковый с ним PSORT_NPROCS=4, т.е. количество потоков сортировки м.б. равным числу усл.процов. "RAW device" vs "BLOCK device" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2008, 18:34 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
vasilisНу что же, сократили время построения индексов более, чем на 2 часа (30%), т.ч. можно сказать, что своего добились :) т.е. показали, что при соответствующих условиях RAW-устройства проявляют себя немного лучше, чем вначале, но разница все равно остается колоссальная, именно для ЭТОГО теста. P.S. Кстати, ранее я советовал не только NUMCPUVPS=4, а и сделать одинаковый с ним PSORT_NPROCS=4, т.е. количество потоков сортировки м.б. равным числу усл.процов. "RAW device" vs "BLOCK device" ИМХО дополнительное ядро на сортировке производительности не добавит, по нагрузке на процессоры видно что даже 3 ядра не загружены. Мне интересно из за чего такая разница в обьеме дискового ввода вывода. ИМХО дополнительная буферизация гдето всетаки имеется в случае с блочными устройствами именно она и есть причиной такой разницы в производительности. Если под informix отдать 6 Гб на блочных устройствах ИМХО производительность упадет. 2 svat2 У Вас случаем не завалялся рузультат onstat -D по результатам каждого из трех этапов для всех тестов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2008, 20:06 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
onstat- Если под informix отдать 6 Гб на блочных устройствах ИМХО производительность упадет. Вы невнимательны. Под Информикс в последних тестах УЖЕ было выделено ~7,5 Gb. Хотя и операционной системе осталось ~500 Mb для своих нужд (в т.ч. и буферизации). onstat- 2 svat2 У Вас случаем не завалялся рузультат onstat -D по результатам каждого из трех этапов для всех тестов. Сейчас выполняю еще цикл тестов с PSORT_NPROCS=4 и поэтапной регистрацией "onstat -D". О результатах сообщу позже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2008, 12:07 |
|
||
|
"RAW device" vs "BLOCK device"
|
|||
|---|---|---|---|
|
#18+
Выполнил еще цикл тестов с предыдущим конфигом и с PSORT_NPROCS=4 (было =3). Результаты см. в прикрепленном файле. ЗЫ. поэтапный "onstat -D" для обоих тестов см. в следующем сообщении... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2008, 14:47 |
|
||
|
|

start [/forum/topic.php?all=1&fid=44&tid=1608122]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
118ms |
get tp. blocked users: |
2ms |
| others: | 250ms |
| total: | 459ms |

| 0 / 0 |
