ReSQL.ru
     
powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / Плохая производительность дисковой подсистемы на сервере под Informix.
25 сообщений из 90, страница 3 из 4
  3  все
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189314
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
a_shatsЖуравлев Денис
Намек про 8 мне какбы не интересен, потому что активных пользователей в единицу времени у меня обычно 1%. Т.е. 8 потоков для меня эмулируют работу 800 пользователей.
А, ну тогда понятно. Но и в этом случае есть замечания: Informix вряд ли работает по одному блоку размером в 2 КБ, подозреваю, что как все - блоками побольше и burst'ами по несколько блоков за раз.
Информикс под линуксом как раз работает с блоком 2кб (по умолчанию). И в oltp системах в 90% случаев нужен один 2кб блок. И работает он асинхронно, поэтому обычно число io потоков = числу cpu.
...
Рейтинг: 0 / 0
10.09.2009, 16:49
| Ответить | Цитировать | Написать  
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189358
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел. С
Гость
a_shatssvat2,

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

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

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

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

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

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

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

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

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

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


Да

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


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

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

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

Чиво-о-о ? (с)
Особенно порадовало про софтовый RAID на LVM.
Очень рекомендую уточнить, чем нынешние контроллеры отличаются от тех, что применялись 10 лет назад. А именно тогда были описаны и обоснованы Вами процитированные тезисы.
...
Рейтинг: 0 / 0
10.09.2009, 20:02
| Ответить | Цитировать | Написать  
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36189807
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
10.09.2009, 20:51
| Ответить | Цитировать | Написать  
Плохая производительность дисковой подсистемы на сервере под 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
11.09.2009, 10:20
| Ответить | Цитировать | Написать  
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36190370
Павел. С
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел. С
Гость
Получается, что на случайной записи результат одинаковый
Проглядел, результат на случайной записи совсем разный.
На последовательностной записи одинаковый. Здесь, похоже, именно кэш контроллера играет роль.
...
Рейтинг: 0 / 0
11.09.2009, 10:25
| Ответить | Цитировать | Написать  
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36190741
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
onstat-,

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

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

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

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

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

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

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


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


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

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

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


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

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

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

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

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

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

onstat-Согласен что не факт, но моя практика показывает , что это так для всего оборудования проходившего через мои руки.
Не верите не надо.
Я не буду выпрыгивать из штанов что бы это доказать для какого то конкретного железа.
Я ж не писал, что оно вообще никогда не помогает. Пример навскидку: имеем 2 порта HBA, двухконтроллерный внешний RAID, отдаем тома с разными типами нагрузки чрез разные контроллеры (даже если тома расположены на одном массиве, хотя тут эффект ниже) - и имеем весьма заметную разницу в производительности.
Но: в случае с одним контроллером - даже если и поможет, то мало, а может и ухудшить производительность.
...
Рейтинг: 0 / 0
14.09.2009, 14:29
| Ответить | Цитировать | Написать  
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194478
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
14.09.2009, 15:45
| Ответить | Цитировать | Написать  
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194590
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_shats
Участник
onstat-
Давайте попросим Павел. С
средствами ОС равномерно размазать тестируемый файл на 12хRAID 1.
И повторить тест ( особенно на запись) и сравним.
А давайте.
Павел С., можно Вас попросить попробовать такой вариант, если сервер еще не в работе ?
С условиями тестирования, описанными мной выше.

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

Нет проблем. Выложу результаты в следующем посте.
...
Рейтинг: 0 / 0
14.09.2009, 17:00
| Ответить | Цитировать | Написать  
Плохая производительность дисковой подсистемы на сервере под Informix.
    #36194901
atlas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
atlas
Гость
Похожая история.
Имеем два одинаковых сервера с HDR репликацией. OC SUSE SLES 10. СУБД Informix 10.00. Было замечено в процессе тестирования, что на первичном сервере архив 0 уровня делается 300сек , на вторичном - 30сек. Смотрим журналы RAID контроллера на основном сервере, видим сообщение - "устройство BBU - батарея разряжена или отсутствует, отменяю режим WRITE BACK". Меняем BBU - архив идет 30сек на обоих серверах.
...
Рейтинг: 0 / 0
14.09.2009, 17:48
| Ответить | Цитировать | Написать  
25 сообщений из 90, страница 3 из 4
  3  все
Форумы / Informix [игнор отключен] [закрыт для гостей] / Плохая производительность дисковой подсистемы на сервере под Informix.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/moderation_log.php?user_name=gluconat_ca]:
 0ms
get settings:
 11ms
get forum list:
 13ms
get settings:
 12ms
get forum list:
 17ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 104ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 72ms
get tp. blocked users:
 1ms
others: 764ms
total:  1013ms
созд. / загр.: 1013ms
x
x
Закрыть


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