Случайное чтение и RAID 10 на MegaRAID 320-2x - тормозит

[GrayMagellan]

Сначала опишу оборудование и программное обеспечение.

Железо: сервер SuperMicro 7043P-8R.
Материнская плата: X5DP8-G2.
Процессор: Intel Xeon 2.66 ГГц 2 шт. (HT поддерживает, но толку в нашем случае это никакого не дает - и включали, и выключали)
Оперативная память: 4 Гб (CACHE под Windows больше 1.6 Гб не берет).
Дисковая подсистема IDE: 1 IDE диск, на котором расположена операционная система; 1 DVD-ROM.
Дисковая подсистема SCSI: 1 RAID массив 10-го уровня из 10 дисков под управлением контроллера MegaRAID 320-2x, на котором расположены исполняемые файлы СУБД CACHE и базы данных. Размер баз данных колеблется от 20 до 40 Гб (сервер пока не рабочий, на нем ведется разработка, но потом он станет рабочим).
Параметры RAID контроллера и массива:
Stripe Size: 128 кб.
Write policy: Write Back
Read policy: Read Ahead
Cache policy: Cached I/O
Версия BIOS контроллера: 413Z


Программное обеспечение:
ОС: Windows 2000 AS SP4 + все критические обновления.
СУБД: Cache

Теперь, собственно, проблема, вынудившая обратиться за помощью:
Выполнении некоторого запроса в БД происходит очень медленно. Cache, в принципе, достаточно быстрая СУБД, и нас все устраивало, а тут вдруг такие тормоза! Стали разбираться. Выяснилось, что СУБД выполняет только чтение с массива со средней скоростью 2-4 мб/сек. Нам показалось странным, что на таком мощном RAID массиве скорость чтения при выполнении запроса столь мала! Сначала думали, что это особенности CACHE. Туда обратились за помощью. А потом решили потестить массив iometer. Скачали последнюю версию с интернета и запустили тест со следующими параметрами, примерно соответствующими режиму выполнения запроса:

Блок данных: 8 кб.
Чтение/запись: 100% чтение.
Случайный/последовательный: 100% случайный.
Количество рабочих потоков: 1 Worker.
Объем тестового файла: все свободное пространство на массиве (~40 Гб).
Доступ к диску: 100%.
Количество Outstanding i/o requests: 1
Время выполнения теста: 1 минута.

Так вот, результаты теста нас повергли в шок!!! Количество операций ввода-вывода колеблется около величины 160. Скорость чтения с массива составила ~1.2 мб/сек. А скорость выполнения запроса ~2-4 мб/сек. Т.е., на мой взгляд, хорошо согласуется с заданием теста (наверное, запрос генерирует не 100% случайное чтение, а 70-80%, поэтому и скорость немного выше). Получается, виноват массив? Или контроллер?
Для проверки выполнили обратный тест. Задали 100% последовательное чтение блоками по 128 кб. Результат - 256 мб/сек. Я понимаю, что тут сказывается природа 100% случайного и 100% последовательного чтения. Но, как говорится, кто виноват и что делать, чтобы увеличить скорость случайного чтения. Пробовали играть установками RAID контроллера - влияние они оказывают только на последовательное чтение - скорость колебалась от 230 до 276 мб/сек. А скорость случайного чтения как была, так и осталась на уровне 1.2 мб/сек.

Поскольку CACHE считывает информацию с диска блоками по 8 кб, сегодня провели эксперимент: пересоздали массив на Stripe Size=8 кб, а также при форматировании размер кластера также поставили 8 кб. Опять протестировали iometer`ом и скорость только упала - стала равна 1 мб/сек при случайном чтении блоками по 8 кб и 140 мб/сек при последовательном чтении блоками по 128 кб. Скорость выполнения запроса в CACHE тоже упала на 27%. Что же делать? Как увеличить скорость случайного чтения и почему такой мощный аппарат так "лажает"? И вообще, нормальна ли такая скорость для этого массива. Я тут на форуме читал, что он просто "бронебойный" - что случайное чтение, что последовательное - все равно выдает ~65 мб/сек. Для нас в данном случае это был бы более предпочтительный вариант. И как поднять скорость случайного доступа - это же превалирующий режим работы СУБД.

[gs]

На мой взгляд, у Вас категорически неправильные настройки массива (хотя вообще-то вряд ли будет прирост в разы). Попробуйте DirectIO, Rean Normal/Adaptive, Stripe64k.

Посмотрите перфмоном дисковую очередь под нагрузкой. На самом деле просто непонятно, почему такие маленькие цифры. Даже под одним потоком массив должен бы поболе выдавать. Хотя один рандом поток для СУБД - вещь неестественная и с точки зрения контроллера ненормальная. Правда я не знаток Вашей базы...

[a_shats]

Stripe Size: 128 кб.
Надо было оставить дефолтные 64К
Cache policy: Cached I/O
Поставьте Direct I/O.
Хотя эти вещи настолько затормозить контроллер на самом деле и не могут.

Ну и не забудьте драйвера свежие поставить. А также GAM или PowerConsole - и посмотрите % на rebuild и не делаются ли какие-то background tasks (Fast Init, Rebuid, Check Consistency).

[gs]

Да, действительно, не забудьте вырубить фастинит - он идет очень долго и может сильно тормозить машину.

[GrayMagellan]

1) Что касается параметров настройки RAID контроллера, то мы при тестировании iometer`ом пробовали разные комбинации параметров. Можно считать, что они влияют в основном на линейное чтение большими блоками в степени +/-10%. На 100% случайное чтение маленькими блоками по 8 кб мы никакого влияния не заметили. Как был 1.2 мб/сек, так и остался.

2) Что касается Performance Monitor. Avg. Disk Queue = 0.7 и Current Disk Queue = 0 или 1 в пропорции 50/50. Я расцениваю такие показания как практически полное отсутствие очереди к диску.

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

4) Rebild дефолтный - 30%.

5) Контроллер не выполняет в данный момент никаких фоновых задач - массив был создан и инициализирован руками из BIOS контроллера сегодня утром (я уже говорил выше, что мы поменяли Stripe Size с 128 кб на 8 кб). Кроме всего, опция FastInit выключена в BIOS`е контроллера. Я вообще FastInit`у не доверяю и массивы всегда полностью инициализирую руками.

Может быть, дело в BIOS контроллера или материнской платы? Или он стоит не в том слоте и конфликтует с другими устройствами? Может это влиять таким катастрофическим образом на работу контроллера?

[gs]

Скорее всего это нюансы СУБД. Этот контроллер проверен уже миллион раз - должно быть все нормально.

[GrayMagellan]

Да бог с ней, с СУБД! Тут ведь сам iometer показывает низкие результаты! А вы неоднократно утверждали, что только iometer дает более-менее верные результаты тестирования.

А вы сами не тестировали эти контроллеры или массивы в конфигурации, подобной нашей, iometer`ом с таким тестовым заданием, как у нас - случайное чтение маленькими блоками?

[gs]

В один поток - не проверяли.

[GrayMagellan]

А имеет смысл вернуться с прошивки 413Z на старую прошивку - 413G. Я читал, что вы сами ее используете и не хотите переходить на новые, потому что они глючат?

[GrayMagellan]

Мы выполнили тот же тест iometer`ом на другом сервере SuperMicro. Он ненамного "слабее" первого - там находится SuperMicro X5DMS-6GM, 2 Xeon 2.4 ГГц, 4 Гб ОЗУ и MegaRAID 320-1 с двумя RAID массивами - один RAID 5 из пяти дисков, другой RAID 1 из двух дисков. Результаты практически совпадают с сервером CACHE. Получается, что все MegaRAID контроллеры так медленно работают с предлагаемой нагрузкой?

[exLH]

GrayMagellan
Я Вам больше того скажу. Все виденные мной контроллеры (включая внешние файберные) будут давать схожие показатели на указанном пэттерне Iometer.
Почему Вы решили, что в реальной работе "Количество Outstanding i/o requests: 1"

[GrayMagellan]

Прошу прошения за молчание.

exLH писал:

Почему Вы решили, что в реальной работе "Количество Outstanding i/o requests: 1"

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

Вопрос в процессе консультаций с CACHE возник вот еще какой:

Если Stripe Size=8 кб, и количество дисков в нулевой половине RAID (единичную половину RAID, обеспечивающую зеркалирование, сейчас опустим) равно 5, то количество stripe, как я предполагаю, тоже равно 5. А вот как эти 8 кб делятся по 5 дискам? Тут возможны два варианта: либо Stripe Size - это сумма блоков данных, считываемых с каждого диска-члена массива, либо это размер блока данных с каждого диска-члена массива, и тогда общий размер данных, считываемый с диска, будет составлять 40 кб. Глупо, конечно, задавать этот вопрос, вовсю эксплуатируя RAID массивы, но проясните мне этот вопрос, пожалуйста...

[gs]

Страйп - это размер блока, которым оперирует контроллер при работе с дисками. Максимальный размер. Контроллер может читать-писать и меньше, если нужно, но больше - не может. Т.е. чисто теоретически при малых размерах блока СУБД уменьшение страйпа должно давать прирост. Но на практике может быть с точностью наоборот, т.к. внутренние механизмы работы фирмвари - черный ящик и обычно контроллеры "точатся" именно под дефолтный страйп.

[GrayMagellan]

То, что контроллер не обязательно должен считывать/записывать весь страйп с дисковой подсистемы, я понял. Я не понял другого. Если я задаю Stripe Size = N кб, как контроллер будет делить эти N кб между дисками, входящими в массив RAID 0 из M дисков. Размер (максимальный) блока данных, передаваемый между контроллером и любым диском массива, в таком случае равен N/M кб? Или этот блок данных и есть N  кб, а общий размер данных, считываемый с массива, есть N*M? Вот в чем мой вопрос! Stripe Size - это размер общего блока данных, передаваемый от контроллера операционной системе, или это размер блока данных единичного диска, входящего в массив?

Если CACHE (MS SQL) нужно считать 8 кб с дисковой подсистемы, я думал, что на каждом диске, входящем в массив из M дисков, будет храниться 8кб/M, т.е. в нашем случае 8/5 кб ~= 1,6 кб. Я прав или нет? Тут просто возникли сомнения, которые нужно разрешить.

[gs]

Это максимальный размер блока, передаваемый между диском и контроллером.