powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Informix [игнор отключен] [закрыт для гостей] / Плохая производительность дисковой подсистемы на сервере под Informix.
90 сообщений из 90, показаны все 4 страниц
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36185982
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день!

Решили переносить БД на новый сервер. Меняется практически все: версия IDS, OS, железо.
Перед тем как этим заниматься решил проверить, насколько новое железо шустрее. Был удивлен:
на новом сервере производительность дисковой подсистемы на синтетических бенчмарках ниже, чем на старом. Не могу понять причину... Буду рад, если здесь помогут.
Вопрос больше к системщикам, чем к DBA, но, думаю, найдутся люди, которым интересно )) Все-таки сервер делается для Информикса.

Сервер раз
Код: plaintext
1.
2.
3.
4.
5.
CPU - 2 шт. 4 ядра Xeon 2.33
RAM - 2 GB
OS - Win2003 под IA32
тестируемый контроллер - внутренний, PCI-E 8x, 256 MB кеша (50/50).
физ. диски - 2х SAS 10k RPM 72 GB. Внутри сервера. Кеш дисков выключен.
тестируемый диск - собран из 2х физ. дисков в RAID 1. ОС видит 1 диск. Кеширование в Windows выключено.

Сервер два
Код: plaintext
1.
2.
3.
4.
5.
6.
CPU - 2 шт. 2 ядра Xeon 2.66
RAM - 8 GB
OS - Linux RH 5. под x64.
тестируемый контроллер - внутренний, PCI-X 133 64 bit, 256 MB кеша (50/50).
физ. диски - 24х SAS 15k RPM 72 GB. Внешние. Кеш дисков выключен.
тестируемый диск - собран из 24х физ. дисков в RAID 10. ОС видит 1 диск. Файловой системы нет.

На обоих серверах последние стабильные драйвера и прошивки контроллеров и дисков.

Бенчмарк
Тестировал iometer'ом. Заставлял его в несколько (8) потоков читать с тестируемого диска данные блоками по 2Кб. Случайно. Размер "области" для случайного чтения 10 GB. На первом сервере "область" - это файл на диске. Во втором - просто блочное устройство. Все потоки за чтением обращаются к одной и той же "области".
Тест гонял по 10 минут на каждом сервере. Получил результат:
Код: plaintext
1.
сервер раз - 610 IO per sec
сервер два - 450 IO per sec

Внимание, вопрос: почему диск из 12ти зеркал оказался быстрее, чем диск из одного зеркала?!?!? Причем физ. диски во втором случае сами по себе быстрее.

У меня есть несколько предположений, но все они кажутся мне маловероятными:
1) я что-то криво настроил )))
2) у меня сбоит железо.
3) Linux работает с этим железом не так как надо
4) мой бенчмарк не подходит для сравнения производительности дисков на разных ОС.
5) Я чего-то не понимаю, и количество дисков в массиве (2 против 24) не должно влиять на общую производительность системы при рандомном чтении в несколько потоков.

Кстати, предполагаю, что из-за размера страницы Информикса в 4 КB, на Win2003 я получу значительно б о льшую скорость работы самой БД (IO в секунду столько же, а МБ в секунду в 2 раза больше). Я не ошибаюсь?

П.С. Делал еще один бенчмарк на сервере три. Там тоже Win2003 и NAS из 12 дисков в RAID 10. Там получил 1200 IO per sec.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186021
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С
5) Я чего-то не понимаю, и количество дисков в массиве (2 против 24) не должно влиять на общую производительность системы при рандомном чтении в несколько потоков.
с точностью до наоборот.
1-й поток читает с диска 1 (и замирает 10мс seek)
2-й поток в это же время с диска 4 seek 10мс
3-й ждет диск 1 стоит в очереди
4-й поток читает диск 2
и т.д.

Размер блока в информиксе я думаю стоит ставить 16кб, т.к. все современные контроллеры оптимизируют на огромные размеры в сотни кб.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186039
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кол-во потоков в асинхронном режиме не принципиально. Т.е. мы контроллеру кидаем команды читай, читай, читай, читай, читай, пиши, читай, читай, читай, контроллер асинхронно отвечает готово пользуйся, готово пользуйся,готово пользуйся,готово пользуйся,
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186060
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сервер раз - 610 IO per sec
сервер два - 450 IO per sec
разницы конечный пользователь не заметит. Т.к. io на 99% кеширован.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186131
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Павел. С5) Я чего-то не понимаю, и количество дисков в массиве (2 против 24) не должно влиять на общую производительность системы при рандомном чтении в несколько потоков.
Журавлев Денисс точностью до наоборот.
Денис, поясните, пожалуйста, какое из моих утверждений "с точностью до наоборот" ) Никак не могу сориентироваться.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186225
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторпочему диск из 12ти зеркал оказался быстрее, чем диск из одного зеркала?!?!?
Потому что так и должно быть

автор5) Я чего-то не понимаю, и количество дисков в массиве (2 против 24) не должно влиять на общую производительность системы при рандомном чтении в несколько потоков.
должно.


больше дисков -> больше иопсов. Пока не упремся в ограничения контроллера или нагружающей системы.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186247
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С
Код: plaintext
1.
сервер раз - 610 IO per sec
сервер два - 450 IO per sec

Внимание, вопрос: почему диск из 12ти зеркал оказался быстрее, чем диск из одного зеркала?!?!? Причем физ. диски во втором случае сами по себе быстрее.

У меня есть несколько предположений, но все они кажутся мне маловероятными:
1) я что-то криво настроил )))
2) у меня сбоит железо.
3) Linux работает с этим железом не так как надо
4) мой бенчмарк не подходит для сравнения производительности дисков на разных ОС.
5) Я чего-то не понимаю, и количество дисков в массиве (2 против 24) не должно влиять на общую производительность системы при рандомном чтении в несколько потоков.

Кстати, предполагаю, что из-за размера страницы Информикса в 4 КB, на Win2003 я получу значительно б о льшую скорость работы самой БД (IO в секунду столько же, а МБ в секунду в 2 раза больше). Я не ошибаюсь?

П.С. Делал еще один бенчмарк на сервере три. Там тоже Win2003 и NAS из 12 дисков в RAID 10. Там получил 1200 IO per sec.

Outstanding I/Os сколько ?
Или Вы 1 поток операций чтения 2К блоками мерили ? :)
Ну, Вы поняли
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186250
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С,

И вдогонку: iometer под Линукс - было много сообщений о глюках и кривости измерений.
Используйте iozone - но тщательно смотрите и выбирайте параметры тестирования.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186254
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Проведите тест на файлике 100мб (чтобы влез в кеш контроллера) и блоках 2кб. -- узнаете максимум пролезающий сквозь контроллер, шину pcie и iometer.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186270
Фотография Andron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. СДобрый день!

...

Кстати, предполагаю, что из-за размера страницы Информикса в 4 КB, на Win2003 я получу значительно б о льшую скорость работы самой БД (IO в секунду столько же, а МБ в секунду в 2 раза больше). Я не ошибаюсь?


Размер страницы в dbspace в Linux (как и в Windows) можно менять начиная с 10 версии информикса. А если используется LVM то в нем все равно чтение будет идти блоками (сразу по несколько страниц) а не страницами.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186279
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andron
Размер страницы в dbspace в Linux (как и в Windows) можно менять начиная с 10 версии информикса. А если используется LVM то в нем все равно чтение будет идти блоками (сразу по несколько страниц) а не страницами.
с чего вдруг? надо 2кб, lvm прочитает 2кб
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186285
Фотография Andron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мне наш админ AIX сказал что блоками :)
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186332
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев ДенисПроведите тест на файлике 100мб (чтобы влез в кеш контроллера) и блоках 2кб. -- узнаете максимум пролезающий сквозь контроллер, шину pcie и iometer.

Это можно и так посмотреть - тут
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186338
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ЯВнимание, вопрос: почему диск из 12ти зеркал оказался быстрее, чем диск из одного зеркала?!?!?

Вот тут я круто описАлся... Вопрос звучит так:

почему диск из 12ти зеркал оказался медленнее , чем диск из одного зеркала?!?!?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186379
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Журавлев Денис
больше дисков -> больше иопсов. Пока не упремся в ограничения контроллера или нагружающей системы.

Я топик как раз создал, т.к. это правило у меня не выполняется.

На первом сервере мало дисков - много иопсов
На втором сервере много дисков - мало иопсов. Причем здесь диске шустрее.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186387
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
a_shats
Outstanding I/Os сколько ?
Или Вы 1 поток операций чтения 2К блоками мерили ? :)
Ну, Вы поняли

Потоков iometer'а 8. На всех бенчмарках.
Outstanding I/Os 1. Пробовал менять. На значениях 1-100 нет вообще никакой разницы. На значениях от 500 и выше - скорость (IO/s) падает.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186399
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AndronМне наш админ AIX сказал что блоками :)там Read ahead есть, но отключаемый
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186416
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. СЖуравлев Денис
больше дисков -> больше иопсов. Пока не упремся в ограничения контроллера или нагружающей системы.

Я топик как раз создал, т.к. это правило у меня не выполняется.

На первом сервере мало дисков - много иопсов
На втором сервере много дисков - мало иопсов. Причем здесь диске шустрее.для начала попробуйте в линуксе на маленьком размере 50мб, сколько иопсов будет.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186428
Фотография Andron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис,

А если скажем используется какой нибудь RAID, то чтение идет опять же блоками или страницами приложения?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186442
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AndronЖуравлев Денис,

А если скажем используется какой нибудь RAID, то чтение идет опять же блоками или страницами приложения?зависит от контроллера и типа рейда. Я уже сказал что оптимизируют их в строну сотен килобайт, т.е. какая разница что он может или не может считать 2 кб, если он 128 кб читает за тоже время.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186445
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Журавлев ДенисПроведите тест на файлике 100мб (чтобы влез в кеш контроллера) и блоках 2кб. -- узнаете максимум пролезающий сквозь контроллер, шину pcie и iometer.

Провел. Все то же самое (8 потоков, рандомное чтение по 2КБ), только файл 40 МБ.

Код: plaintext
1.
Первый сервер (Win2003, 2 диска) - 57 000 IO/s
Второй сервер (Linux, 24 диска)  - 1 650  IO/s
Причем sar -d на втором сервер дает вот что:
Код: plaintext
1.
2.
02:50:26 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
02:50:28 PM dev105-96   2293.97   9175.88      0.00      4.00      1.11      0.49      0.44    100.55
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186467
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1650 очень мало, что-то не так, или с линуком или с мерялкой

попробуйте для начала перейти на raw
http://oraclepitstop.wordpress.com/2008/02/15/raw-devices-on-rhel-5-or-oel-5/
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186547
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AndronМне наш админ AIX сказал что блоками :)


Попробуйте сравнить
чтение из /dev/lv_name ( блочное)
и из /dev/ r lv_name ( символьное)

разница даст повод задуматься и Вам и админу.


2 Павел. С

Под линухом Вы какое устройство тестирует блочное или символьное ?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186573
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
onstat-

2 Павел. С

Под линухом Вы какое устройство тестирует блочное или символьное ?

Блочное.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186589
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис

попробуйте для начала перейти на raw
http://oraclepitstop.wordpress.com/2008/02/15/raw-devices-on-rhel-5-or-oel-5/


Вот еще один интересный способ через udev.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186600
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С

Блочное.

Обязательно попробуйте raw .
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186665
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Уменьшил размер файла с 40 до 10 МБ.
На линуксе стало
12 200 IO/s для блочного устройства
13 500 IO/s для RAW, сделанного командой raw на то же блочное устройство

40 МБ не влезало в кеш. Буду с этим разбираться.

Но все равно, откуда на win2003 55 000 IO/s, а на Linux только 13 500?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186693
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С
Но все равно, откуда на win2003 55 000 IO/s, а на Linux только 13 500?может кривой драйвер контроллера, а может мерялка неправильно работает. Попробуйте на файлах в линуксе, если иометер научился direct_io


iozone вот умеет.
-I Use VxFS VX_DIRECT, O_DIRECT,or O_DIRECTIO for all file operations
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186844
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С,

Правильнее такую нагрузку создавать при значениях Outstanding I/Os >=100.
Под "потоками IOMeter'а" Вы понимаете Worker'ов ?
И, кстати, с начала теста смотреть показания счетчиков бессмысленно при Ваших значениях кэшей (50/50), дождитесь, пока они устаканятся (минут 3-5 хотя бы).
Второй момент - какие конкретно RAID-контроллеры участвовали в тесте ?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36186886
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
a_shats
Правильнее такую нагрузку создавать при значениях Outstanding I/Os >=100.
. Могу еще раз тесты провести, с нужными значениями Outstanding I/Os.

a_shats
Под "потоками IOMeter'а" Вы понимаете Worker'ов ?
Да.

a_shats
И, кстати, с начала теста смотреть показания счетчиков бессмысленно при Ваших значениях кэшей (50/50), дождитесь, пока они устаканятся (минут 3-5 хотя бы).
Второй момент - какие конкретно RAID-контроллеры участвовали в тесте ?
HP Smart Array P400 для первого сервера на Win2003
HP Smart Array P600 для второго сервера на Linux
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36187002
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-Журавлев Денис

попробуйте для начала перейти на raw
http://oraclepitstop.wordpress.com/2008/02/15/raw-devices-on-rhel-5-or-oel-5/


Вот еще один интересный способ через udev.В той сцылке что я давал для rh5 (это чуть ниже), именно это и написано.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36187042
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С[Могу еще раз тесты провести, с нужными значениями Outstanding I/Os.
Попробуйте. Под линукс еще раз рекомендую iozone , только обратите внимание - нужно, чтобы паттерны нагрузок совпали.

Да.
Воркеры пользуются, когда надо создать разные по паттернам нагрузки на разные тома.

HP Smart Array P400 для первого сервера на Win2003
HP Smart Array P600 для второго сервера на Linux
Гм. Ни для того, ни для другого, ни 2 ни 8 винтов не могут дать столько, сколько не в состоянии будет переварить считалка.
Значит, что-то не так с тестами...
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36187097
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
a_shatsПопробуйте. Под линукс еще раз рекомендую iozone , только обратите внимание - нужно, чтобы паттерны нагрузок совпали.
Следующий пост будет с результатами iozone.

a_shats
Гм. Ни для того, ни для другого, ни 2 ни 8 винтов не могут дать столько, сколько не в состоянии будет переварить считалка.
Значит, что-то не так с тестами...
Да, надо разобраться. Не хочется верить, что система со встроенным P400 и 2мя внутренними винтами работает шустрее отдельно поставленным P600 с 24мя винтами ))
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36187148
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сделал тесты с помощью iozone.
Размер файла 10 Мб, 8 потоков, блок 2к, O_DIRECT включен.
Вот параметры "iozone -l 8 -u 8 -s 10M -r 2k -O -I O_DIRECT"

Win2003 c 2мя винтами в RAID1:

Код: 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.
	File size set to 10240 KB
	Record Size 2 KB
	OPS Mode. Output is in operations per second.
	Command line used: /cygdrive/c/Program Files/benchmarks/Iozone 3.321/iozone -l 8 -u 8 -s 10M -r 2k -O -I O_DIRECT
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 Kbytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
	Min process = 8 
	Max process = 8 
	Throughput test with 8 processes
	Each process writes a 10240 Kbyte file in 2 Kbyte records

	Children see throughput for  8 initial writers 	=  124680.87 ops/sec
	Parent sees throughput for  8 initial writers 	=   72694.18 ops/sec
	Min throughput per process 			=   14943.40 ops/sec 
	Max throughput per process 			=   16314.83 ops/sec
	Avg throughput per process 			=   15585.11 ops/sec
	Min xfer 					=    4457.00 ops

	Children see throughput for  8 rewriters 	=  122649.01 ops/sec
	Parent sees throughput for  8 rewriters 	=   88468.49 ops/sec
	Min throughput per process 			=   14659.10 ops/sec 
	Max throughput per process 			=   16126.17 ops/sec
	Avg throughput per process 			=   15331.13 ops/sec
	Min xfer 					=    4426.00 ops

	Children see throughput for  8 readers 		=  140932.86 ops/sec
	Parent sees throughput for  8 readers 		=  123466.08 ops/sec
	Min throughput per process 			=   16894.33 ops/sec 
	Max throughput per process 			=   18895.37 ops/sec
	Avg throughput per process 			=   17616.61 ops/sec
	Min xfer 					=    4315.00 ops

	Children see throughput for 8 re-readers 	=  116222.17 ops/sec
	Parent sees throughput for 8 re-readers 	=  103540.91 ops/sec
	Min throughput per process 			=   13740.34 ops/sec 
	Max throughput per process 			=   16001.27 ops/sec
	Avg throughput per process 			=   14527.77 ops/sec
	Min xfer 					=    4182.00 ops

	Children see throughput for 8 reverse readers 	=  117605.42 ops/sec
	Parent sees throughput for 8 reverse readers 	=  106272.50 ops/sec
	Min throughput per process 			=   12537.01 ops/sec 
	Max throughput per process 			=   15741.32 ops/sec
	Avg throughput per process 			=   14700.68 ops/sec
	Min xfer 					=    3883.00 ops

	Children see throughput for 8 stride readers 	=  107917.97 ops/sec
	Parent sees throughput for 8 stride readers 	=   96892.53 ops/sec
	Min throughput per process 			=   13102.49 ops/sec 
	Max throughput per process 			=   14672.53 ops/sec
	Avg throughput per process 			=   13489.75 ops/sec
	Min xfer 					=    4369.00 ops

	Children see throughput for 8 random readers 	=   88586.93 ops/sec
	Parent sees throughput for 8 random readers 	=   83035.27 ops/sec
	Min throughput per process 			=   10635.39 ops/sec 
	Max throughput per process 			=   11502.23 ops/sec
	Avg throughput per process 			=   11073.37 ops/sec
	Min xfer 					=    4569.00 ops

	Children see throughput for 8 mixed workload 	=  104911.75 ops/sec
	Parent sees throughput for 8 mixed workload 	=   75236.79 ops/sec
	Min throughput per process 			=   11942.28 ops/sec 
	Max throughput per process 			=   14285.60 ops/sec
	Avg throughput per process 			=   13113.97 ops/sec
	Min xfer 					=    4094.00 ops

	Children see throughput for 8 random writers 	=   97951.49 ops/sec
	Parent sees throughput for 8 random writers 	=   64343.68 ops/sec
	Min throughput per process 			=   11966.26 ops/sec 
	Max throughput per process 			=   12918.66 ops/sec
	Avg throughput per process 			=   12243.94 ops/sec
	Min xfer 					=    4557.00 ops



iozone test complete.

Linux c 24мя винтами в RAID10:

Код: 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.
90.
91.
92.
93.
94.
	File size set to 10240 KB
	Record Size 2 KB
	OPS Mode. Output is in operations per second.
	O_DIRECT feature enabled
	Command line used: iozone -l 8 -u 8 -s 10M -r 2k -O -I O_DIRECT
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 Kbytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
	Min process = 8 
	Max process = 8 
	Throughput test with 8 processes
	Each process writes a 10240 Kbyte file in 2 Kbyte records

	Children see throughput for  8 initial writers 	=   22462.66 ops/sec
	Parent sees throughput for  8 initial writers 	=   22343.97 ops/sec
	Min throughput per process 			=    2803.40 ops/sec 
	Max throughput per process 			=    2811.01 ops/sec
	Avg throughput per process 			=    2807.83 ops/sec
	Min xfer 					=    5104.00 ops

	Children see throughput for  8 rewriters 	=   25759.26 ops/sec
	Parent sees throughput for  8 rewriters 	=   25661.61 ops/sec
	Min throughput per process 			=    3217.27 ops/sec 
	Max throughput per process 			=    3222.98 ops/sec
	Avg throughput per process 			=    3219.91 ops/sec
	Min xfer 					=    5108.00 ops

	Children see throughput for  8 readers 		=   19055.99 ops/sec
	Parent sees throughput for  8 readers 		=   18531.42 ops/sec
	Min throughput per process 			=       3.38 ops/sec 
	Max throughput per process 			=    5865.11 ops/sec
	Avg throughput per process 			=    2382.00 ops/sec
	Min xfer 					=       3.00 ops

	Children see throughput for 8 re-readers 	=   18787.03 ops/sec
	Parent sees throughput for 8 re-readers 	=   18507.14 ops/sec
	Min throughput per process 			=       2.81 ops/sec 
	Max throughput per process 			=    3721.03 ops/sec
	Avg throughput per process 			=    2348.38 ops/sec
	Min xfer 					=       4.00 ops

	Children see throughput for 8 reverse readers 	=   19026.62 ops/sec
	Parent sees throughput for 8 reverse readers 	=   18076.39 ops/sec
	Min throughput per process 			=       7.19 ops/sec 
	Max throughput per process 			=   18976.25 ops/sec
	Avg throughput per process 			=    2378.33 ops/sec
	Min xfer 					=       2.00 ops

	Children see throughput for 8 stride readers 	=   18194.28 ops/sec
	Parent sees throughput for 8 stride readers 	=   16178.23 ops/sec
	Min throughput per process 			=       7.09 ops/sec 
	Max throughput per process 			=   13617.31 ops/sec
	Avg throughput per process 			=    2274.28 ops/sec
	Min xfer 					=       3.00 ops

	Children see throughput for 8 random readers 	=   18402.16 ops/sec
	Parent sees throughput for 8 random readers 	=   17709.42 ops/sec
	Min throughput per process 			=       7.56 ops/sec 
	Max throughput per process 			=    6577.13 ops/sec
	Avg throughput per process 			=    2300.27 ops/sec
	Min xfer 					=       6.00 ops

	Children see throughput for 8 mixed workload 	=   18554.13 ops/sec
	Parent sees throughput for 8 mixed workload 	=    8489.92 ops/sec
	Min throughput per process 			=      13.96 ops/sec 
	Max throughput per process 			=    7424.88 ops/sec
	Avg throughput per process 			=    2319.27 ops/sec
	Min xfer 					=      10.00 ops

	Children see throughput for 8 random writers 	=   25295.31 ops/sec
	Parent sees throughput for 8 random writers 	=   25198.92 ops/sec
	Min throughput per process 			=    3160.25 ops/sec 
	Max throughput per process 			=    3165.29 ops/sec
	Avg throughput per process 			=    3161.91 ops/sec
	Min xfer 					=    5112.00 ops

	Children see throughput for 8 pwrite writers 	=   22559.64 ops/sec
	Parent sees throughput for 8 pwrite writers 	=   22417.03 ops/sec
	Min throughput per process 			=    2817.89 ops/sec 
	Max throughput per process 			=    2827.33 ops/sec
	Avg throughput per process 			=    2819.95 ops/sec
	Min xfer 					=    5101.00 ops

	Children see throughput for 8 pread readers 	=   18969.20 ops/sec
	Parent sees throughput for 8 pread readers 	=   18555.44 ops/sec
	Min throughput per process 			=    2250.00 ops/sec 
	Max throughput per process 			=    3047.13 ops/sec
	Avg throughput per process 			=    2371.15 ops/sec
	Min xfer 					=    3871.00 ops



iozone test complete.

Стало еще непонятней интересней. Система с 2мя винтами просто чемпион.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36187254
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С,

Вы хотите протестировать, насколько контроллерам пофиг на ту ерунду, которой Вы их пытаетесь нагрузить ?

8 потоков с безумной кучей разнообразных паттернов нагрузок подряд, блоками 2КБайт, объемом меньше кэша - это не тестирование, а непонятно что.

Тестируйте - сотней потоков, конкретными нагрузками (отдельно random read, отдельно random write - за это отвечает параметр -i), объем - от десятка гигабайт и выше.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36187276
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
a_shats
Вы хотите протестировать, насколько контроллерам пофиг на ту ерунду, которой Вы их пытаетесь нагрузить ?
)))
a_shats
8 потоков с безумной кучей разнообразных паттернов нагрузок подряд, блоками 2КБайт, объемом меньше кэша - это не тестирование, а непонятно что.

Тестируйте - сотней потоков, конкретными нагрузками (отдельно random read, отдельно random write - за это отвечает параметр -i), объем - от десятка гигабайт и выше.

На самом деле специально выбрал объем для тестов меньше кэша контроллера, по совету предыдущих комментаторов. Хочется понять, сколько "пролезает" IO/s "от приложения до контроллера" по максимуму.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36187326
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С
На самом деле специально выбрал объем для тестов меньше кэша контроллера, по совету предыдущих комментаторов. Хочется понять, сколько "пролезает" IO/s "от приложения до контроллера" по максимуму.

Вам не по максимум нужно , а по объему будущей базы.
Иначе вы не получите те же цифры в реальной работе.


У меня на сторадж на запись и чтение в рандоме в паралель в сумме пролазит 1.3Gbyte /sec
по максимуму, на операциях в 8 к.
НО в реальной работе я таких цифр не видел никогда.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36187679
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
драйвера карточки hp-шные или те котороые в дистрибутиве были?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36187718
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Журавлев Денисдрайвера карточки hp-шные или те котороые в дистрибутиве были?
Везде HP'шные драйвера. И в Win2003 и в Linux.

В Linux просто установил RPM.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36187785
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. СЖуравлев Денисдрайвера карточки hp-шные или те котороые в дистрибутиве были?
Везде HP'шные драйвера. И в Win2003 и в Linux.

В Linux просто установил RPM.

Ну тогда я не знаю

Children see throughput for 8 readers = 19055.99 ops/sec

19055.99*2/1024=37 мегабайт / сек ?? Чтение из памяти контроллера?

dmesg|tail что-ли покажите, обновитесь, попробуйте opensuse 11.0 с драйверами из дистра.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36188335
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис,

Там все просто - потому что полный микс из нагрузочных тестов.
Часть дергает винты даже если кэша хватает, часть не дергает.
Причем одна за другой идут разнотипные нагрузки, никакая оптимизация кэширования не помогает.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36188746
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shatsЖуравлев Денис,

Там все просто - потому что полный микс из нагрузочных тестов.
Часть дергает винты даже если кэша хватает, часть не дергает.
Причем одна за другой идут разнотипные нагрузки, никакая оптимизация кэширования не помогает.они по очереди идут, я думаю там числа на порядок больше должны быть на чтении маленького файла.

Вот например сервер и дисковый массив 2002 года:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
	Command line used: ./iozone -s 10M -r 2k -O -I -f /testdata/aaa.000
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 Kbytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                            random  random    bkwd  record  stride                                   
              KB  reclen   write rewrite    read    reread    read   write    read rewrite    read   fwrite frewrite   fread  freread
           10240       2    1543    3140   107434   107930   76394     323   90645    3842   82874     1432     2977   90382    91080
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36188794
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис

Вот например сервер и дисковый массив 2002 года:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
	Command line used: ./iozone -s 10M -r 2k -O -I -f /testdata/aaa.000
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 Kbytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                            random  random    bkwd  record  stride                                   
              KB  reclen   write rewrite    read    reread    read   write    read rewrite    read   fwrite frewrite   fread  freread
           10240       2    1543    3140   107434   107930   76394     323   90645    3842   82874     1432     2977   90382    91080

А тут тест вообще в один поток.
И чего Вы таким образом намеревались намерить ? :)
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36188897
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shatsА тут тест вообще в один поток.
И чего Вы таким образом намеревались намерить ? :)ок. я дурак.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
	
	File size set to 10240 KB
	Record Size 2 KB
	OPS Mode. Output is in operations per second.
	VxFS advanced feature SET_CACHE, VX_DIRECT enabled
	Command line used: ./iozone -l 8 -u 8 -s 10M -r 2k -O -I -F /testdata/aaa.000 /testdata/aaa.001
 /testdata/aaa.002 /testdata/aaa.003 /testdata/aaa.004 /testdata/aaa.005 /testdata/aaa.006 /testdata/aaa.007
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 Kbytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
	Min process = 8 
	Max process = 8 
	Throughput test with 8 processes
	Each process writes a 10240 Kbyte file in 2 Kbyte records


	Children see throughput for  8 readers 		=  191811.19 ops/sec
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189049
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис,

И опять не совсем :) Если у Вас на старом сервере, который Вы таким образом тестируете, имеется какой-никакой RAID-контроллер с кэшем - получается ровно та же самая ерунда, что и у автора темы :) Намекаю - у Вас с базой работает 1, 8 или несколько больше пользователей ?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189128
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shatsЖуравлев Денис,

амекаю - у Вас с базой работает 1, 8 или несколько больше пользователей ?


У INFORMIX DS ассинхронные и чтение и запись,
количество пишущих и читающих процессов от количества пользователей не зависит.
Зависть только от параметров .
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189165
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shatsЖуравлев Денис,

И опять не совсем :) Если у Вас на старом сервере, который Вы таким образом тестируете, имеется какой-никакой RAID-контроллер с кэшем - получается ровно та же самая ерунда, что и у автора темы :) Намекаю - у Вас с базой работает 1, 8 или несколько больше пользователей ?я подозреваю что у автора темы такие маленькие числа из проблемы с линуксом, с дровами, etc.

Намек про 8 мне какбы не интересен, потому что активных пользователей в единицу времени у меня обычно 1%. Т.е. 8 потоков для меня эмулируют работу 800 пользователей.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189215
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Павел. С
Сервер раз
Код: plaintext
1.
физ. диски - 2х SAS 10k RPM 72 GB. Внутри сервера. Кеш дисков  выключен. 

Сервер два
Код: plaintext
1.
физ. диски - 24х SAS 15k RPM 72 GB. Внешние. Кеш дисков  выключен. 


Павел. С
Хочется понять, сколько "пролезает" IO/s "от приложения до контроллера" по максимуму.


Если под "кеш дисков" подразумевается кеш RAID-контроллера, то для удовлетворения
понимания из второй цитаты нужно поменять выделенное в первой.
Иначе получаем значение "от приложения до дисков ".
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189230
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
svat2,

Кэш дисков - подразумевается кэш записи на самих винтах, судя по всему.
А поскольку он никакими BBU не страхуется - дОлжно его отключать.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189242
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Журавлев Денис
Намек про 8 мне какбы не интересен, потому что активных пользователей в единицу времени у меня обычно 1%. Т.е. 8 потоков для меня эмулируют работу 800 пользователей.
А, ну тогда понятно. Но и в этом случае есть замечания: Informix вряд ли работает по одному блоку размером в 2 КБ, подозреваю, что как все - блоками побольше и burst'ами по несколько блоков за раз.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189314
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shatsЖуравлев Денис
Намек про 8 мне какбы не интересен, потому что активных пользователей в единицу времени у меня обычно 1%. Т.е. 8 потоков для меня эмулируют работу 800 пользователей.
А, ну тогда понятно. Но и в этом случае есть замечания: Informix вряд ли работает по одному блоку размером в 2 КБ, подозреваю, что как все - блоками побольше и burst'ами по несколько блоков за раз.
Информикс под линуксом как раз работает с блоком 2кб (по умолчанию). И в oltp системах в 90% случаев нужен один 2кб блок. И работает он асинхронно, поэтому обычно число io потоков = числу cpu.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189358
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
a_shatssvat2,

Кэш дисков - подразумевается кэш записи на самих винтах, судя по всему.
А поскольку он никакими BBU не страхуется - дОлжно его отключать.
Все верно. Речь именно о кэше дисков. Он выключен именно по этой причине. Кэш контроллеров включен.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189426
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shats[quot Журавлев Денис]
А, ну тогда понятно. Но и в этом случае есть замечания: Informix вряд ли работает по одному блоку размером в 2 КБ, подозреваю, что как все - блоками побольше и burst'ами по несколько блоков за раз.

Да мультиблочные и чтение и запись присутствуют.
Но мультиблочное чтение и запись гораздо дешевле рандома.

Я вам даже больше скажу, асинхронный алгоритм ввода вывода informix
пытается собрать одноблочные операции ВВ, которые иницированы разными пользовательскими сессиями паралельно , в многоблочные.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189478
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
onstat-
Да мультиблочные и чтение и запись присутствуют.
Но мультиблочное чтение и запись гораздо дешевле рандома.

Я вам даже больше скажу, асинхронный алгоритм ввода вывода informix
пытается собрать одноблочные операции ВВ, которые иницированы разными пользовательскими сессиями паралельно , в многоблочные.

Мультиблочное чтение при RA включается?

Увеличение количества дисков в системе как раз было сделано для того, чтобы повысить скорость рандомных операций.

Но, как показывают тесты,
увеличение количества дисков в массиве увеличивает суммарную скорость операций рандомного чтения только при работе нескольких пользовательских потоков параллельно.
Имеет право на жизнь такое утверждение?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189494
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Павел. СКэш контроллеров включен.

1) режим WriteBack или WriteThrough ?
2) каков размер страйпа ?
3) никакого rebuild массива, случаем, не происходит в момент измерения ?
4) вы не троль?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189528
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
svat2Павел. СКэш контроллеров включен.

1) режим WriteBack или WriteThrough ?
2) каков размер страйпа ?
3) никакого rebuild массива, случаем, не происходит в момент измерения ?
4) вы не троль?

1) WriteBack. Там другого и не включишь. Контроллер с батарейкой.
2) 128 KB
3) нет, все спокойно, все харды на месте. Ничего не происходит.
4) не замечал за собой
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189609
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С
Мультиблочное чтение при RA включается?


Да

Павел. С
Увеличение количества дисков в системе как раз было сделано для того, чтобы повысить скорость рандомных операций.


ИМХО вы создает узкое место на уровне входа в раид в очереди скизи команд.
При правильном разложении данных по 1ым раидам скорость будет выше.
При создании софтверного раида на LVM скорость будет выше.
Контроллер сможет паралелить операции между разными томами , внутри
одного тома могут возникать всякие блокировки при конкуренции операции ВВ.

Павел. С
Но, как показывают тесты,
увеличение количества дисков в массиве увеличивает суммарную скорость операций рандомного чтения только при работе нескольких пользовательских потоков параллельно.
Имеет право на жизнь такое утверждение?

Нужно заставить сервер эффективно использовать PDQ, что бы параллелилась одна сессия.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189754
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-
ИМХО вы создает узкое место на уровне входа в раид в очереди скизи команд.
При правильном разложении данных по 1ым раидам скорость будет выше.
При создании софтверного раида на LVM скорость будет выше.
Контроллер сможет паралелить операции между разными томами , внутри
одного тома могут возникать всякие блокировки при конкуренции операции ВВ.

Чиво-о-о ? (с)
Особенно порадовало про софтовый RAID на LVM.
Очень рекомендую уточнить, чем нынешние контроллеры отличаются от тех, что применялись 10 лет назад. А именно тогда были описаны и обоснованы Вами процитированные тезисы.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189807
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shatsonstat-
ИМХО вы создает узкое место на уровне входа в раид в очереди скизи команд.
При правильном разложении данных по 1ым раидам скорость будет выше.
При создании софтверного раида на LVM скорость будет выше.
Контроллер сможет паралелить операции между разными томами , внутри
одного тома могут возникать всякие блокировки при конкуренции операции ВВ.

Чиво-о-о ? (с)
Особенно порадовало про софтовый RAID на LVM.

Очень рекомендую уточнить, чем нынешние контроллеры отличаются от тех, что применялись 10 лет назад. А именно тогда были описаны и обоснованы Вами процитированные тезисы.



Посмотрите чем отличаются драйверы, и сколько скази команд одновременно можно поставить на ввод вывод на 10 Раид из N дисков и сколько можно поставить на N/2 томов raid1.

Под линуксом смотреть на iostat -x <device> 1 10 смотреть на avgrq-sz avgqu-sz .
и сравниваем результаты тестов.

На софтвертом страйпе из N/2 томов raid1
можно потерять на CPU , но пропихнуть больше скази команд.
Именно команд( IOPS) , а не получить большую скорость ВВ.

На мультиблочном ВВ аппаратный раид будет быстрее , этого я отрицать не буду.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36190355
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Павел. С

Но, как показывают тесты,
увеличение количества дисков в массиве увеличивает суммарную скорость операций рандомного чтения только при работе нескольких пользовательских потоков параллельно.
Имеет право на жизнь такое утверждение?

Кстати, о тестах, если кому интересно.
Взял второй сервер (Linux) и выполнил 2 одинаковых бенчмарка, но на разных дисках ОС.
Код: plaintext
1.
1й диск - собран из 2х  физ. дисков в RAID 1 на внутреннем контроллере P400 с 512 МБ кэша 50/50
2й диск - собран из 24х физ. дисков в RAID 10 на внутреннем контроллере P600 с 256 МБ кэша 50/50
Все физ. диски одинаковые. Бенчмарк - случайная запись, затем случайное чтение в 50 потоков, прямой вв, общий объем 15GB (50 файлов по 300 МB). (iozone -i 0 -i 2 -l 50 -u 50 -s 300M -r 2k -O -I O_DIRECT)
Интересные результаты:
1ый диск из 2х физ. дисков
Код: 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.
        Children see throughput for 50 initial writers  =   19701.97 ops/sec
        Parent sees throughput for 50 initial writers   =   19569.82 ops/sec
        Min throughput per process                      =     391.56 ops/sec
        Max throughput per process                      =     395.96 ops/sec
        Avg throughput per process                      =     394.04 ops/sec
        Min xfer                                        =  151895.00 ops

        Children see throughput for 50 rewriters        =   27385.04 ops/sec
        Parent sees throughput for 50 rewriters         =   27382.88 ops/sec
        Min throughput per process                      =     547.62 ops/sec
        Max throughput per process                      =     550.05 ops/sec
        Avg throughput per process                      =     547.70 ops/sec
        Min xfer                                        =  152920.00 ops

        Children see throughput for 50 random readers   =     810.91 ops/sec
        Parent sees throughput for 50 random readers    =     810.91 ops/sec
        Min throughput per process                      =      16.00 ops/sec
        Max throughput per process                      =      16.42 ops/sec
        Avg throughput per process                      =      16.22 ops/sec
        Min xfer                                        =  149658.00 ops

        Children see throughput for 50 random writers   =     697.43 ops/sec
        Parent sees throughput for 50 random writers    =     692.80 ops/sec
        Min throughput per process                      =      13.94 ops/sec
        Max throughput per process                      =      14.04 ops/sec
        Avg throughput per process                      =      13.95 ops/sec
        Min xfer                                        =  152471.00 ops

2ой диск из 24х физ. дисков

Код: 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.
        Children see throughput for 50 initial writers  =   19164.90 ops/sec
        Parent sees throughput for 50 initial writers   =   19161.55 ops/sec
        Min throughput per process                      =     383.22 ops/sec
        Max throughput per process                      =     383.35 ops/sec
        Avg throughput per process                      =     383.30 ops/sec
        Min xfer                                        =  153547.00 ops

        Children see throughput for 50 rewriters        =   21841.12 ops/sec
        Parent sees throughput for 50 rewriters         =   21839.72 ops/sec
        Min throughput per process                      =     436.80 ops/sec
        Max throughput per process                      =     437.08 ops/sec
        Avg throughput per process                      =     436.82 ops/sec
        Min xfer                                        =  153500.00 ops

        Children see throughput for 50 random readers   =    9402.66 ops/sec
        Parent sees throughput for 50 random readers    =    9402.38 ops/sec
        Min throughput per process                      =     186.62 ops/sec
        Max throughput per process                      =     190.96 ops/sec
        Avg throughput per process                      =     188.05 ops/sec
        Min xfer                                        =  150113.00 ops

        Children see throughput for 50 random writers   =    7945.90 ops/sec
        Parent sees throughput for 50 random writers    =    7938.16 ops/sec
        Min throughput per process                      =     158.90 ops/sec
        Max throughput per process                      =     159.07 ops/sec
        Avg throughput per process                      =     158.92 ops/sec
        Min xfer                                        =  153431.00 ops

Получается, что на случайной записи результат одинаковый, а на случайном чтении массив из 24х дисков выигрывает массиву из 2х дисков в 11.6 раз. Т.е. в 24/2 раза.
Но справедливо это, к сожалению, только для многих потоков. Их большое количество заставляет контроллер вертеть всеми блинами одновременно и с одинаковой пользой. Рост производительности вообще линейный.

Для 1го потока такого различия не должно быть.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36190370
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Получается, что на случайной записи результат одинаковый
Проглядел, результат на случайной записи совсем разный.
На последовательностной записи одинаковый. Здесь, похоже, именно кэш контроллера играет роль.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36190741
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-,

ОС никаким образом не ставит SCSI команды в очередь к дискам на RAID-контроллере.
Это делает интерфейс к винтам, в данном случае - интерфейс RAID-контроллера, о котором ОС ничего не знает и мерить никак не может. И переупорядочивать очередь команд, управляемую им - тоже. Управляет процессом RAID-контроллер, сообразуясь с наличием/отсутствием в кэше нужных блоков и собственной логикой (точнее - логикой фирмвареписателей).
У софтового RAID собственного кэша нет вообще - им служит файловый кэш ОС. Который довольно туп - в силу универсальности. Туп - в плане предвыборки, отложенной записи и оптимизации всех этих дел.
Да, в ряде ОС все это можно частично настроить руками - но если Вы скажете, что знаете об оптимизации ввода-вывода больше, чем инженеры LSI, Adaptec и иже с ними, с наработанным десятилетиями опытом , занимающиеся только этим - позвольте в этом усомниться.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36190748
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. С,

Получается, что на случайной записи результат одинаковый, а на случайном чтении массив из 24х дисков выигрывает массиву из 2х дисков в 11.6 раз. Т.е. в 24/2 раза.
Но справедливо это, к сожалению, только для многих потоков. Их большое количество заставляет контроллер вертеть всеми блинами одновременно и с одинаковой пользой. Рост производительности вообще линейный.

Ну, примерно это я и имел в виду :) Разве что - линейного роста добиться бывает сложно, а иногда - и невозможно, но это, как правило - на бОльшей нагрузке и при бОльшем количестве винтов.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36190810
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shatsonstat-,

ОС никаким образом не ставит SCSI команды в очередь к дискам на RAID-контроллере.
Это делает интерфейс к винтам, в данном случае - интерфейс RAID-контроллера, о котором ОС ничего не знает и мерить никак не может. И переупорядочивать очередь команд, управляемую им - тоже. Управляет процессом RAID-контроллер, сообразуясь с наличием/отсутствием в кэше нужных блоков и собственной логикой (точнее - логикой фирмвареписателей).
У софтового RAID собственного кэша нет вообще - им служит файловый кэш ОС. Который довольно туп - в силу универсальности. Туп - в плане предвыборки, отложенной записи и оптимизации всех этих дел.
Да, в ряде ОС все это можно частично настроить руками - но если Вы скажете, что знаете об оптимизации ввода-вывода больше, чем инженеры LSI, Adaptec и иже с ними, с наработанным десятилетиями опытом , занимающиеся только этим - позвольте в этом усомниться.

До оптимизации ввода вывода контролером дело еще не доходит, потому как
скази команда еще торчит в очереди на ввод вывод в драйвере устройства.

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

Я вам даже больше скажу, если средствами контроллера 10 раид можно
побить на логические тома , а потом соеденить попка в попке в ОС через LVM
То количество IOPs тоже растет по сравнению с использованием
одного большого тома.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36190963
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-
До оптимизации ввода вывода контролером дело еще не доходит, потому как
скази команда еще торчит в очереди на ввод вывод в драйвере устройства.
Ага, так мы о разных вещах говорим.


В узком горлышке драйвера устройства. Когда таких горлышек много ,
очередь паралелится.
А вот тут имеет место недопонимание. Очередь команд в/в ОС не параллелится - а едет к контроллеру, как есть. FIFO, бубёныть. Вот внутри него - да, определяется, какие реально (а не те, что видит ОС) блоки надо читать/писать, на какие винты, и как это переупорядочить оптимизации ради.


Я вам даже больше скажу, если средствами контроллера 10 раид можно
побить на логические тома , а потом соеденить попка в попке в ОС через LVM
То количество IOPs тоже растет по сравнению с использованием
одного большого тома.
А вот это ни разу не факт, может быть даже и наоборот, т.к. зависит от заточки фирмваре контроллера + кучи доп. факторов.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36193967
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-a_shatsЖуравлев Денис,
амекаю - у Вас с базой работает 1, 8 или несколько больше пользователей ?

У INFORMIX DS ассинхронные и чтение и запись,
количество пишущих и читающих процессов от количества пользователей не зависит.
Зависит только от параметров .
Вот-вот, читал подряд и все ждал, когда кто нибудь вспомнит, что тестировать сотни потоков для Информикса не нужно :)
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36193987
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shatsПавел. С,
Вы хотите протестировать, насколько контроллерам пофиг на ту ерунду, которой Вы их пытаетесь нагрузить ?
8 потоков с безумной кучей разнообразных паттернов нагрузок подряд, блоками 2КБайт, объемом меньше кэша - это не тестирование, а непонятно что.
Тестируйте - сотней потоков, конкретными нагрузками (отдельно random read, отдельно random write - за это отвечает параметр -i), объем - от десятка гигабайт и выше.
Про сотни потоков уже сказали. Это не имеет смысла в данном случае.
И все таки, даже на нагрузке "ерунда" почему такие разные результаты ?
Это из-за разных платформ (и, надеюсь, каких то исправимых несуразностей в Линуксе)? Или из-за разных конфигураций тестируемого оборудования ?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194010
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. СУ меня есть несколько предположений, но все они кажутся мне маловероятными:
1) я что-то криво настроил )))
2) у меня сбоит железо.
3) Linux работает с этим железом не так как надо
4) мой бенчмарк не подходит для сравнения производительности дисков на разных ОС.
5) Я чего-то не понимаю, и количество дисков в массиве (2 против 24) не должно влиять на общую производительность системы при рандомном чтении в несколько потоков.

Если вернуться снова к начальным вопросам. заданным топикстартером, может кто то все таки кратко ответить (на данный конкретный случай) или подвести краткие итоги и сделать выводы "для будущих поколений" - я надеюсь поместить в FAQ :)
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194064
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shats
onstat-
В узком горлышке драйвера устройства. Когда таких горлышек много ,
очередь паралелится.
А вот тут имеет место недопонимание. Очередь команд в/в ОС не параллелится - а едет к контроллеру, как есть. FIFO, бубёныть. Вот внутри него - да, определяется, какие реально (а не те, что видит ОС) блоки надо читать/писать, на какие винты, и как это переупорядочить оптимизации ради.


Для каждого девайса в драйвере есть своя очередь.
Потом эти очереди сходятся в одну.
посмотрите iostat -x

a_shats
А вот это ни разу не факт, может быть даже и наоборот, т.к. зависит от заточки фирмваре контроллера + кучи доп. факторов.

Согласен что не факт, но моя практика показывает , что это так для всего оборудования проходившего через мои руки.
Не верите не надо.
Я не буду выпрыгивать из штанов что бы это доказать для какого то конкретного железа.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194091
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilis
Если вернуться снова к начальным вопросам. заданным топикстартером, может кто то все таки кратко ответить (на данный конкретный случай) или подвести краткие итоги и сделать выводы "для будущих поколений" - я надеюсь поместить в FAQ :)

Думаю что смысла писать ФАК по данному конкретному вопросу смысла нет.
Слишком большая энтропия, которую создают разные типы массивов под разными ОС.

Нужно либо сравнивать разные ОС и одинаковые массивы,
либо разные массивы и однаковые ОС.

Тогда и повторяемость будет выше и выше качество ФАК.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194234
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilisПро сотни потоков уже сказали. Это не имеет смысла в данном случае.
В случае Журавлев Денис - да, и он даже написал, почему именно :)
И все таки, даже на нагрузке "ерунда" почему такие разные результаты ?
Это из-за разных платформ (и, надеюсь, каких то исправимых несуразностей в Линуксе)? Или из-за разных конфигураций тестируемого оборудования ?
Именно из-за того, что несуразная методика тестирования. Для понимания: запустите тест 10 раз - можете получить 10 разных результатов на каждой платформе. А так - количество потоков должно соответствовать тому, что на самом деле ожидается от сервиса, объем - тоже примерно такой (и обязательно - значительно больше кэша RAID, иначе его оптимизации перекорежат результаты), тип нагрузки в одном тесте - один конкретный, а не все вообще. Ну и неплохо бы - дать время "на разогрев", т.е. в случае с iozone - запустить тест несколько раз (с одной и той же нагрузкой - обязательно), добиваясь повторяемости результатов.

onstat-Согласен что не факт, но моя практика показывает , что это так для всего оборудования проходившего через мои руки.
Не верите не надо.
Я не буду выпрыгивать из штанов что бы это доказать для какого то конкретного железа.
Я ж не писал, что оно вообще никогда не помогает. Пример навскидку: имеем 2 порта HBA, двухконтроллерный внешний RAID, отдаем тома с разными типами нагрузки чрез разные контроллеры (даже если тома расположены на одном массиве, хотя тут эффект ниже) - и имеем весьма заметную разницу в производительности.
Но: в случае с одним контроллером - даже если и поможет, то мало, а может и ухудшить производительность.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194478
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shats

Но: в случае с одним контроллером - даже если и поможет, то мало, а может и ухудшить производительность.



Давайте попросим Павел. С
средствами ОС равномерно размазать тестируемый файл на 12хRAID 1.
И повторить тест ( особенно на запись) и сравним.

Павел. С
Получается, что на случайной записи результат одинаковый, а на случайном чтении массив из 24х дисков выигрывает массиву из 2х дисков в 11.6 раз. Т.е. в 24/2 раза.
Но справедливо это, к сожалению, только для многих потоков. Их большое количество заставляет контроллер вертеть всеми блинами одновременно и с одинаковой пользой. Рост производительности вообще линейный.



Если сейчаc разницы по записи ( RAID1 vs RAID10) праткически нет, то при размазывании
данных между RAID1 она ИМХО появится.

RAID 10 бьет RAID1 только на чтении за счет большего количества шпинделей.

А при правильном размещении данных суммарная производительность рандомного ВВ
(чтение + запись ) будет практически одинакова.
Если будет преобладать запись то ИМХО
N*RAID1 побьет RAID10 из такого же количества дисков.
Все будет зависеть от качества "размазывания" данных по шпинделям.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194590
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-
Давайте попросим Павел. С
средствами ОС равномерно размазать тестируемый файл на 12хRAID 1.
И повторить тест ( особенно на запись) и сравним.
А давайте.
Павел С., можно Вас попросить попробовать такой вариант, если сервер еще не в работе ?
С условиями тестирования, описанными мной выше.

А при правильном размещении данных суммарная производительность рандомного ВВ
(чтение + запись ) будет практически одинакова.
Если будет преобладать запись то ИМХО
N*RAID1 побьет RAID10 из такого же количества дисков.
Все будет зависеть от качества "размазывания" данных по шпинделям.
Мое имхо - напротив, RAID10 побъет N*RAID1. Еще и потому, что RAID-контроллер всяко лучше сделает RAID0 из N*RAID1 и размажет по винтам блоки с данными :)
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194724
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
a_shatsА давайте.
Павел С., можно Вас попросить попробовать такой вариант, если сервер еще не в работе ?
С условиями тестирования, описанными мной выше.

Нет проблем. Выложу результаты в следующем посте.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194901
atlas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Похожая история.
Имеем два одинаковых сервера с HDR репликацией. OC SUSE SLES 10. СУБД Informix 10.00. Было замечено в процессе тестирования, что на первичном сервере архив 0 уровня делается 300сек , на вторичном - 30сек. Смотрим журналы RAID контроллера на основном сервере, видим сообщение - "устройство BBU - батарея разряжена или отсутствует, отменяю режим WRITE BACK". Меняем BBU - архив идет 30сек на обоих серверах.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36195023
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
onstat-
Давайте попросим Павел. С
средствами ОС равномерно размазать тестируемый файл на 12хRAID 1.
И повторить тест ( особенно на запись) и сравним.


Сделал тест iozone.
Тот же контроллер и те же 24 физ. диска к нему. Собраны 12 RAID 1 по 2 физ. диска в каждом против 1го RAID10 из 24 дисков в предыдущем тесте.

ОС видит 12 томов. На каждом томе создана FS ext3. IOzone работает в 48 потоков (проитив 50 в предыдущем тесте) по 4 потока на каждый том. На каждом томе, соответственно, по 4 файла размером в 300 MB. Суммарный объем данных почти 15 Gb, что много больше объема кеша контроллера. IOzone также работает с O_DIRECT. Не знаю, как еще лучше "размазать" данные.

по sar -d видно, что все 12 дисков ОС нагружены одинаково во время теста.

Результат
1xRAID 10 (12xRAID 1):
Код: plaintext
1.
2.
3.
4.
5.
6.
Children see throughput for 50 initial writers  =   19164.90 (19712.11) ops/sec     +2.9%

Children see throughput for 50 rewriters        =   21841.12 (22410.58) ops/sec     +2.5%

Children see throughput for 50 random readers   =    9402.66 (9483.41)  ops/sec     +0.9%

Children see throughput for 50 random writers   =    7945.90 (7788.19)  ops/sec     -2.0%

Отличия совсем несущественные.
Получается, что и ОС и контроллер достаточно умны, чтобы при надлежащей нагрузке оптимально использовать все доступные диски?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36195118
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. Сonstat-
Давайте попросим Павел. С
средствами ОС равномерно размазать тестируемый файл на 12хRAID 1.
И повторить тест ( особенно на запись) и сравним.


Сделал тест iozone.
Тот же контроллер и те же 24 физ. диска к нему. Собраны 12 RAID 1 по 2 физ. диска в каждом против 1го RAID10 из 24 дисков в предыдущем тесте.

ОС видит 12 томов. На каждом томе создана FS ext3. IOzone работает в 48 потоков (проитив 50 в предыдущем тесте) по 4 потока на каждый том. На каждом томе, соответственно, по 4 файла размером в 300 MB. Суммарный объем данных почти 15 Gb, что много больше объема кеша контроллера. IOzone также работает с O_DIRECT. Не знаю, как еще лучше "размазать" данные.

по sar -d видно, что все 12 дисков ОС нагружены одинаково во время теста.

Результат
1xRAID 10 (12xRAID 1):
Код: plaintext
1.
2.
3.
4.
5.
6.
Children see throughput for 50 initial writers  =   19164.90 (19712.11) ops/sec     +2.9%

Children see throughput for 50 rewriters        =   21841.12 (22410.58) ops/sec     +2.5%

Children see throughput for 50 random readers   =    9402.66 (9483.41)  ops/sec     +0.9%

Children see throughput for 50 random writers   =    7945.90 (7788.19)  ops/sec     -2.0%

Отличия совсем несущественные.
Получается, что и ОС и контроллер достаточно умны, чтобы при надлежащей нагрузке оптимально использовать все доступные диски?

Попробуйте не по 4 , а по 10, 15, 20 на каждый том ?
кто быстрее заткнется 12ХRAID или 1ХRAID10 на суммарном количестве потоков ?

Не знаю как там у izone c асинхронным вводом выводом.

Прошу учесть что

Журавлев Денискол-во потоков в асинхронном режиме не принципиально. Т.е. мы контроллеру кидаем команды читай, читай, читай, читай, читай, пиши, читай, читай, читай, контроллер асинхронно отвечает готово пользуйся, готово пользуйся,готово пользуйся,готово пользуйся,

Informix умеет пользоваться вводом выводом напрямую в режиме асинхронного ВВ.
А умеет ли izone ?
Каждые его процесс может ждать завершение предыдущей команды
прежде чем послать следующую , я просто не в курсе.
Некогда сейчас по инету искать.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36195127
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
onstat-Попробуйте не по 4 , а по 10, 15, 20 на каждый том ?

Завтра утром выложу результаты.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36195883
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
onstat-Попробуйте не по 4 , а по 10, 15, 20 на каждый том ?

Вот результаты для 12xRAID1 и 1xRAID10. Всё тот же контроллер. Все те же 24 физ. диска.
Для RAID 1 создано по 20 файлов на каждом из 12ти томов ОС размером в 300 МB.
Для RAID 10 создано 240 файлов на единственном томе ОС размером в 300 МB.
Тест в 240 потоков. Общий объем файлов 70 GB.

1xRAID 10 (12xRAID 1):
Код: plaintext
1.
2.
3.
4.
5.
6.
Children see throughput for 50 initial writers  =   19045.00 (19227.69) ops/sec 100% (101%)

Children see throughput for 50 rewriters        =   22090.91 (21838.07) ops/sec 100% (99%)

Children see throughput for 50 random readers   =   10891.76 (13194.98) ops/sec 100% (121%)

Children see throughput for 50 random writers   =    7277.56 (7432.71)  ops/sec 100% (102%)

Видно, что на случайном чтении 12xRAID 1 выигрывает у 10ки.


Вот теперь задумался, на чем поднимать БД?
С одной стороны, у 12 RAID1 скорость на последнем тесте больше чем у RAID10.
С другой стороны, такую нагрузку как в бенчмарке (240 потоков, причем весь необходимый IO распределен равномерно между ними) Informix не создаст для моей системы. Да и работать с 10кой проще.
Как считаете?
речь идет о разбивке дисков для данных, индексов и физ. журнала. Логический журнал и временные пр-ва планирую вынести вообще на отдельный контроллер и диски.

Еще есть вариант сделать массив из 24х дисков в RAID10 и побить его на 12 томов. Тогда ОС будет видеть 12 дисков, но каждый из них физически будет размазан по 24 физ. дискам. Будет время - попробую тест сделать.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36196336
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Children see throughput for 50
из предыдущего надо читать как
Children see throughput for 240
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36196381
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я в прошлом горячий сторонник разбиения и выжимания соков из железа. Сейчас считаю, что это все от лукавого. Не стоит овчинка выделки, сейчас возможности железа позволяют уделить больше внимания удобству и простоте администрирования, чем производительности.
При прошлом разбиении мне удалось создать систему, у которой хватило запаса мощности при возросших более, чем на порядок нагрузках, а сейчас благодаря кризису я имею на порядок более мощное железо, на фоне прекратившегося роста нагрузок.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36197068
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сделал еще 1 тест. Нагрузка та же, 240 потоков, общий объем данных 70 GB.
ОС видит 12 томов. Это на уровне контроллера разбитый RAID10 из 24х физ дисков.


Вот результаты:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Children see throughput for 240 initial writers =   19272.91 ops/sec

Children see throughput for 240 rewriters       =   21759.77 ops/sec

Children see throughput for 240 random readers  =    8394.73 ops/sec

Children see throughput for 240 random writers  =    3680.71 ops/sec

Стало еще интересней. Кто-нибудь найдет логическое объяснение результата?
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36197142
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
DaugavaЯ в прошлом горячий сторонник разбиения и выжимания соков из железа. Сейчас считаю, что это все от лукавого. Не стоит овчинка выделки, сейчас возможности железа позволяют уделить больше внимания удобству и простоте администрирования, чем производительности.
При прошлом разбиении мне удалось создать систему, у которой хватило запаса мощности при возросших более, чем на порядок нагрузках, а сейчас благодаря кризису я имею на порядок более мощное железо, на фоне прекратившегося роста нагрузок.
Согласен.
Но все-таки хочется, чтобы железо не стало узким местом в системе. От того как я сейчас разобью диски удобство администрирования не изменится.
Вот яркий пример. Выше результаты для бенчмарка
12ти RAID1 по 2 физ. диска
и
12 томов из RAID10 собранного из 24х физ. дисков.
ОС видит всегда 12 томов. Объем одинаковый. Значит сложность администрирования от разбивки не зависит.
А производительность отличается в 2 раза (правда не на реальной работе, а в бенчмарке):

Код: plaintext
1.
12 томов, каждый том - отдельный RAID 1 из 2х физ.дисков (random r/w ops/sec) 13194 / 7432
12 томов, каждый том - кусок от RAID10 из 24х дисков     (random r/w ops/sec)  8394 / 3680

Итого вопросов только прибавилось.
Как теперь разбивать диски и распределять по ним данные - не понимаю.

Может сделать 12 RAID1 и большие таблицы разбить (partitioning)на части и раскидать по разным дискам?

Вобщем надо топик подытоживать, и закрывать, т.к. уже сильно отошел от темы.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36197607
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DaugavaЯ в прошлом горячий сторонник разбиения и выжимания соков из железа. Сейчас считаю, что это все от лукавого. Не стоит овчинка выделки, сейчас возможности железа позволяют уделить больше внимания удобству и простоте администрирования, чем производительности.
Полностью согласен.
Тем не менее, хочется ведь где то проявить свои знания и мастерство и получить удовольствие, даже если результат и будет не выше 2% :)
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36197758
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. ССделал еще 1 тест. Нагрузка та же, 240 потоков, общий объем данных 70 GB.
ОС видит 12 томов. Это на уровне контроллера разбитый RAID10 из 24х физ дисков.


А как резали тома LVM-ом или контроллером ?

Подозреваю что LVM-ом.

Если LVM-ом попробуйте порезать контроллером , если он дает такую возможность .

При нарезке контроллером я нигде не замечал просадки производительности в 2 раза.

У меня даже растет производительность правда на FC и там 2 контроллера.
На PCI SCSI ( не FC ) , я не пробовал.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36197774
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вечер , похоже устал, не заметил , что резалось контроллером, вопрос снимается.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36197955
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vasilis
Полностью согласен.
Тем не менее, хочется ведь где то проявить свои знания и мастерство и получить удовольствие, даже если результат и будет не выше 2% :)
А знания получить хочется )
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36198678
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел. Сvasilis
Полностью согласен.
Тем не менее, хочется ведь где то проявить свои знания и мастерство и получить удовольствие, даже если результат и будет не выше 2% :)
А знания получить хочется )

Контроллер контроллеру рознь, в любом случае нужно тестировать.
По этому топику я понял, что полностью полагаться на предыдущий опыт работы с другими контроллерами не стоит.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36204566
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-,

Я уж изнамекался на этот счет :)

Павел. С
Резюме: готовы рулить нагрузками вручную, считаете, что лучше решите задачу, чем инженеры -разработчики контроллеров - флаг в руки :) Не готовы - используйте готовые решения, и решайте проблемы производительности числом винтов, а не ручной оптимизацией расположения файлов БД.
...
Рейтинг: 0 / 0
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36212718
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
мое имхо такое:
Париться надо начинать если в конкретной системе есть конкретная проблема и консилиум установил что узкое место дисковая подсистема - никак не раньше.
Для синтетических тестов можно немало времени потерять на подъем производительности на 20%, а на конкретной БД попасть глубокую задницу на каком то специфичном запросе.
...
Рейтинг: 0 / 0
90 сообщений из 90, показаны все 4 страниц
Форумы / Informix [игнор отключен] [закрыт для гостей] / Плохая производительность дисковой подсистемы на сервере под Informix.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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