Случайное чтение и RAID 10 на MegaRAID 320-2x - тормозит
Модераторы: Trinity admin`s, Free-lance moderator`s
-
- Power member
- Сообщения: 44
- Зарегистрирован: 12 мар 2004, 14:56
- Откуда: Moscow
Случайное чтение и RAID 10 на MegaRAID 320-2x - тормозит
Сначала опишу оборудование и программное обеспечение.
Железо: сервер 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 мб/сек. Для нас в данном случае это был бы более предпочтительный вариант. И как поднять скорость случайного доступа - это же превалирующий режим работы СУБД.
Железо: сервер 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
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
На мой взгляд, у Вас категорически неправильные настройки массива (хотя вообще-то вряд ли будет прирост в разы). Попробуйте DirectIO, Rean Normal/Adaptive, Stripe64k.
Посмотрите перфмоном дисковую очередь под нагрузкой. На самом деле просто непонятно, почему такие маленькие цифры. Даже под одним потоком массив должен бы поболе выдавать. Хотя один рандом поток для СУБД - вещь неестественная и с точки зрения контроллера ненормальная. Правда я не знаток Вашей базы...
Посмотрите перфмоном дисковую очередь под нагрузкой. На самом деле просто непонятно, почему такие маленькие цифры. Даже под одним потоком массив должен бы поболе выдавать. Хотя один рандом поток для СУБД - вещь неестественная и с точки зрения контроллера ненормальная. Правда я не знаток Вашей базы...
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Stripe Size: 128 кб.
Надо было оставить дефолтные 64К
Cache policy: Cached I/O
Поставьте Direct I/O.
Хотя эти вещи настолько затормозить контроллер на самом деле и не могут.
Ну и не забудьте драйвера свежие поставить. А также GAM или PowerConsole - и посмотрите % на rebuild и не делаются ли какие-то background tasks (Fast Init, Rebuid, Check Consistency).
Надо было оставить дефолтные 64К
Cache policy: Cached I/O
Поставьте Direct I/O.
Хотя эти вещи настолько затормозить контроллер на самом деле и не могут.
Ну и не забудьте драйвера свежие поставить. А также GAM или PowerConsole - и посмотрите % на rebuild и не делаются ли какие-то background tasks (Fast Init, Rebuid, Check Consistency).
-
- Power member
- Сообщения: 44
- Зарегистрирован: 12 мар 2004, 14:56
- Откуда: Moscow
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 контроллера или материнской платы? Или он стоит не в том слоте и конфликтует с другими устройствами? Может это влиять таким катастрофическим образом на работу контроллера?
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 контроллера или материнской платы? Или он стоит не в том слоте и конфликтует с другими устройствами? Может это влиять таким катастрофическим образом на работу контроллера?
-
- Power member
- Сообщения: 44
- Зарегистрирован: 12 мар 2004, 14:56
- Откуда: Moscow
Да бог с ней, с СУБД! Тут ведь сам iometer показывает низкие результаты! А вы неоднократно утверждали, что только iometer дает более-менее верные результаты тестирования.
А вы сами не тестировали эти контроллеры или массивы в конфигурации, подобной нашей, iometer`ом с таким тестовым заданием, как у нас - случайное чтение маленькими блоками?
А вы сами не тестировали эти контроллеры или массивы в конфигурации, подобной нашей, iometer`ом с таким тестовым заданием, как у нас - случайное чтение маленькими блоками?
-
- Power member
- Сообщения: 44
- Зарегистрирован: 12 мар 2004, 14:56
- Откуда: Moscow
-
- Power member
- Сообщения: 44
- Зарегистрирован: 12 мар 2004, 14:56
- Откуда: Moscow
Мы выполнили тот же тест iometer`ом на другом сервере SuperMicro. Он ненамного "слабее" первого - там находится SuperMicro X5DMS-6GM, 2 Xeon 2.4 ГГц, 4 Гб ОЗУ и MegaRAID 320-1 с двумя RAID массивами - один RAID 5 из пяти дисков, другой RAID 1 из двух дисков. Результаты практически совпадают с сервером CACHE. Получается, что все MegaRAID контроллеры так медленно работают с предлагаемой нагрузкой?
-
- Power member
- Сообщения: 44
- Зарегистрирован: 12 мар 2004, 14:56
- Откуда: Moscow
Прошу прошения за молчание.
exLH писал:
Вопрос в процессе консультаций с CACHE возник вот еще какой:
Если Stripe Size=8 кб, и количество дисков в нулевой половине RAID (единичную половину RAID, обеспечивающую зеркалирование, сейчас опустим) равно 5, то количество stripe, как я предполагаю, тоже равно 5. А вот как эти 8 кб делятся по 5 дискам? Тут возможны два варианта: либо Stripe Size - это сумма блоков данных, считываемых с каждого диска-члена массива, либо это размер блока данных с каждого диска-члена массива, и тогда общий размер данных, считываемый с диска, будет составлять 40 кб. Глупо, конечно, задавать этот вопрос, вовсю эксплуатируя RAID массивы, но проясните мне этот вопрос, пожалуйста...
exLH писал:
- ответ на этот вопрос мы только предполагаем - он равен 1, потому что алгоритм чтения CACHE мне неизвестен. Но если бы CACHE читала случайно и при этом объединяла несколько запросов на чтение в одну операцию ввода-вывода, то скорость была бы однозначно выше, т.к. у контроллера появилась бы возможность оптимизировать очередь операций чтения с диска, тем самым уменьшая фактор "случайного" чтения. Еще раз повторю - это мои предположения. Если я не прав, поправьте меня.Почему Вы решили, что в реальной работе "Количество Outstanding i/o requests: 1"
Вопрос в процессе консультаций с CACHE возник вот еще какой:
Если Stripe Size=8 кб, и количество дисков в нулевой половине RAID (единичную половину RAID, обеспечивающую зеркалирование, сейчас опустим) равно 5, то количество stripe, как я предполагаю, тоже равно 5. А вот как эти 8 кб делятся по 5 дискам? Тут возможны два варианта: либо Stripe Size - это сумма блоков данных, считываемых с каждого диска-члена массива, либо это размер блока данных с каждого диска-члена массива, и тогда общий размер данных, считываемый с диска, будет составлять 40 кб. Глупо, конечно, задавать этот вопрос, вовсю эксплуатируя RAID массивы, но проясните мне этот вопрос, пожалуйста...
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Страйп - это размер блока, которым оперирует контроллер при работе с дисками. Максимальный размер. Контроллер может читать-писать и меньше, если нужно, но больше - не может. Т.е. чисто теоретически при малых размерах блока СУБД уменьшение страйпа должно давать прирост. Но на практике может быть с точностью наоборот, т.к. внутренние механизмы работы фирмвари - черный ящик и обычно контроллеры "точатся" именно под дефолтный страйп.
-
- Power member
- Сообщения: 44
- Зарегистрирован: 12 мар 2004, 14:56
- Откуда: Moscow
То, что контроллер не обязательно должен считывать/записывать весь страйп с дисковой подсистемы, я понял. Я не понял другого. Если я задаю 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 кб. Я прав или нет? Тут просто возникли сомнения, которые нужно разрешить.
Если CACHE (MS SQL) нужно считать 8 кб с дисковой подсистемы, я думал, что на каждом диске, входящем в массив из M дисков, будет храниться 8кб/M, т.е. в нашем случае 8/5 кб ~= 1,6 кб. Я прав или нет? Тут просто возникли сомнения, которые нужно разрешить.
Последний раз редактировалось GrayMagellan 21 ноя 2005, 18:23, всего редактировалось 1 раз.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 7 гостей