Оптимизация раида под 1С SQL - как?

Конфигурирование, планирование RAID систем, возможности, технологии, теория. Qlogic, LSI Logic, Adaptec ...

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
OMSHa
Junior member
Сообщения: 10
Зарегистрирован: 03 июл 2003, 17:47
Откуда: SPB

Оптимизация раида под 1С SQL - как?

Сообщение OMSHa » 19 дек 2003, 14:58

Есть 3 раида - первое зеркало под систему/свап, второе зеркало под файл транзакций SQL, третий Раид5 под собственно базу. Контроллер позволяет конфигурировать каждый раид по следующим параметрам:
1.-Запись: Write Trhu/Write Back
2.-Чтение: Read Ahead/Normal/Adaptive Read Ahead
3.- Кеширование: Direct I/O / Caching I/O
С точки зрения увеличения производительности 1С SQL, как лучше сконфигурировать каждый раид? Сам раид называется LSI MegaRaid SCSI 320-1. Заранее спасибо за любой совет!

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 19 дек 2003, 16:29

Я бы немного не так сделал: если винты с БД "быстренько" вытаскивать при случае не надо ;) , то - на все винты сделал бы RAID 10. Этот массив, соответственно, побил бы на тома - под ОС, базу, лог.
Просто - на запись такой конфиг весьма пошустрее будет.
Теперь о параметрах массива:
На MegaRAID 320-1 по умолчанию нет BBU (если только Вы не заказывали его отдельно), поэтому включение WriteBack(отложенная запись), вообще говоря, небезопасно: при отказе питания могут быть проблемы...
Особенно учитывая, что ОС вообще ничего о режиме кэширования (да и о самом его факте) "не знает" ;) .
Остальное:
Read Ahead: опережающее чтение. Контроллер в качестве единицы чтения/записи данных использует страйп (stripe), и в этом режиме при запросе на чтение читается заданный страйп и дополнительно - в кэш - еще один, последовательно за ним. Это режим наиболее эффективен при нагрузке на чтение, особенно линейной, но при случайном чтении может вызвать некоторое понижение производительности (лишние чтения+кэш-миссы).
Normal: без опережающего чтения.
Adaptive: Если на считанный страйп происходит кэш-хит, то читаются сразу еще два страйпа подряд, если кэш-мисс, то опережающего чтения не происходит. Самый эффективный режим для работы с SQL-серверами, использующими единый файл БД (т.е. не как в MySQL, например - когда все таблицы, индексы, служебная информация лежат отдельными файлами). Большого прироста ожидать, правда, не стоит.
3. Кэширование:
при Direct I/O вся инфа, понятно, пролетает "мимо" кэша. Наиболее эффективен этот режим на линейных нагрузках.
при Caching I/O вся инфа сначала вкачивается в кэш, оттуда - при WB - на запись и на чтение, соответственно. Этот режим эффективнее всего на random ("вразброс") записи/чтении, но есть и свои минусы: при тяжелой линейной нагрузке может притормозить работу дисковой п/с - пойдет большое количество кэш-миссов, соответственно очистка кэша чтения+сброс (flush) кэша записи при WB и перезагрузка их.
Соответственно, для 1С рекомендую использовать: WriteBack (очень желательно наличие BBU), Adaptive Read-Ahead, Cached I/O.

OMSHa
Junior member
Сообщения: 10
Зарегистрирован: 03 июл 2003, 17:47
Откуда: SPB

Сообщение OMSHa » 19 дек 2003, 16:41

Спасибо!

Аватара пользователя
Oleg Mandryko
Advanced member
Сообщения: 167
Зарегистрирован: 21 фев 2003, 14:28
Откуда: Ростов-на-Дону

Сообщение Oleg Mandryko » 18 янв 2004, 17:07

А что лучше сделать (опять же для subj) - мать Intel SDS2 (2*U160 на борту) + LSI 320-1. 1 винт на 1 onboard канал под систему, 1 винт на 2-й канал под лог а на LSI - 5 винтов (в корзине) в RAID 1+0 ? Или скажем лог кинуть на зеркало (не HotSwap) вторым массивом на тот же LSI? Или же повесить на LSI 3 массива: зеркала под систему и лог и 1+0 под базу??? Что будет быстрее? BBU к райду брать бум, надо определиться с количеством винтов. Полноценных (стримерных) бэкапов нет, но планируется приобретение сей железки (правда неизвестно как скоро), образ системы снят Ghost'om, SQL бэкапится.

S&L
Advanced member
Сообщения: 113
Зарегистрирован: 30 ноя 2003, 13:06

Сообщение S&L » 18 янв 2004, 22:34

Привет, ну во-первых, раид-10 из четного числа дисков делается,
из нечетного - это вроде раид 1е называется. Я бы делал систему
и лог на зеркале на встроенном контроллере, а базу на
LSI в раид-10, а оставшийся диск в горячий резерв.
Ну а г-н Шац в который раз странные советы дает, ну ладно
про оракла, так и про sql, а вроде бы казалось спец по нему.
Даже сами мелкомягкие советуют разносить логи и базу, это оракулы
предлагают сваливать все в раиде-10, ну что с них взять?
--
SL

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 19 янв 2004, 12:50

S&L
Уф... Аналогичное обсуждение (как раз такого разбиения) было на iXBT. Вкратце, мои утверждения (кои пока что тестами не опровергнуты ;) ) :
1. Рекомендации SQL-разработчиков давались тогда, когда аппаратно WriteBack применялся редко (BBU не было либо были экзотикой), объемы кэша были малы (до 32 Мб), производительность массивов была, хм, сильно другая ;)
2. Операции с логом столь малы, что в WB просто съедаются кэшем контроллера. С другой стороны, вынесение лога на отдельное зеркало просто отнимает у основного массива столь нужные ему IOps.
3. При тяжелой работе (это еще один из аргументов за отделение логов) в нынешних контроллерах упор идет уже не в шину или винты (особенно, когда их много ;) ) - а в считалку (процессор) контроллера и его кэш.
Это все имхо, конечно.
И уж тем более, совмещать ОС с логом ну никак не стоит - это вообще убивает преимущества вынесения логов на отдельный массив.
На отдельный том - да, можно, но - больше в силу того, что под SQL выгоднее сделать блок ФС размером 8 Кб(размер страницы БД), под лог - 2 или 4 Кб (2 Кб - размер страницы лога).

S&L
Advanced member
Сообщения: 113
Зарегистрирован: 30 ноя 2003, 13:06

Сообщение S&L » 19 янв 2004, 22:19

Привет, так о чем речь - об этом конкретном случае или о
каких-то супер-пупер массивах с сотнями дисков и гигами кэша.
И где результаты тестов?
Если все так прекрасно, и в лог почти ничего не пишется,
значит, измнений нет, база только читается, так зачем раид-10,
пускай раид-5 будет. Тем более что все производители бьют
в барабан, что суперусовершенствовали оный.
Насчсет совмещение лога и системы - я согласен, нехорошо,
но выбирают меньшее зло, чем там система особо с диском
занимается, ну не подкачкой же.
--
SL

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 20 янв 2004, 12:08

S&L
Вкратце:
RAID 10 на 6 винтов WB ON - Total 1200 IOps

RAID 10 на 4 винта WB ON+
RAID1 на 2 винта WB ON - Total 850 IOps

RAID 10 на 4 винта WB ON+
RAID 1 на 2 винта WB OFF - Total 710 IOps

Условия, конфиг и прочее - здесь
Если можете предложить реальный метод создания нагрузки, более соответствующий задаче, чем описанный - пишите. Тестовый стенд работает, проверим.
Один из плюсов вынесения лога на отдельный массив в том как бы и состоит, чтобы отделить однородную(последовательная запись) нагрузку от неоднородной (чтение и запись со случайным доступом).
Оттого совмещение его с ОС (а если там окажется еще и DC - стало быть WB файлового кэша ОС будет отключен) этот плюс убьет как класс.

Аватара пользователя
Oleg Mandryko
Advanced member
Сообщения: 167
Зарегистрирован: 21 фев 2003, 14:28
Откуда: Ростов-на-Дону

Сообщение Oleg Mandryko » 20 янв 2004, 13:50

S&L
раид-10 из четного числа дисков делается
Ну это понятно :) Имеется в виду 10 + HotSpare
Т.е. резюме: в данной ситуации разводим систему и лог по встроенным каналам (на них к сожалению не поддерживается аппаратный RAID - а программный IMHO изврат): по 1 диску на канал. Базу в RAID 10 на LSI. Так?

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 20 янв 2004, 13:57

Я лично не вижу особой проблемы при совмещении логов и ОС. Главное - отделить логи от самой базы из соображений надежности. Если накроется массив с базой, то можно будет поднять ее из бэкапа и накатить изменения по логам. А если накроется диск с логами при живой базе - да и пес с ним. (Правда в базах я не спец - если вру, не пинайте больно. Зато хорошо понимаю в работе дисковых систем и их надежности :))
Нагрузка же при записи логов действительно невелика - просто у нее характер линейный и соответственно она для диска проблемы не представляет. Зато представит проблему, если добавится к хаотичной нагрузке самой базы при расположении на том же томе. Но тут обменное соотношение - при ограниченом числе дисков придется под логи отнимать винты от базы, что может свести эффект к нулю. Так что тока эксперимент надо делать.
С Шацем мы уже вопрос обсуждали и не пришли к общему знаменателю - понятно, что только на рабочей нагрузке это можно увидеть.

Ответить

Вернуться в «Массивы - RAID технологии.»