Трехкратное увеличение активности записи

Оценить
(0 голоса)

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

Оба графика были выполнены по данным, собранным с помощью утилиты iostat.

•             Подходящее количество дисков. Проблемы, связанные с конфигурированием слишком малого количества шпинделей, часто становятся более очевидными в малых БД. Вполне удается с одним диском в 36 Гбайт сконфигурировать достаточный объем для небольшой БД, однако может понадобиться большее количество шпинделей, если значительное число пользователей выполняет многочисленные операции ввода/вывода в БД. Вам необходимо рассмотреть количество IOPS, приходящихся на 1 Гбайт, и кроме того стоимость 1 Гбайт.

При проведении тестирования на Sun мы обычно конфигурировали большое количество дисков для испытаний, причем, со значительно большими объемами, чем необходимо. Однако наше применение не является типичным: мы оперируем моделью, в которой стоимость не является первичным ограничивающим фактором, и системы приближаются к пределу. ТРС-С, программа эталонного тестирования OLTP, предполагает конфигурирование и оценку стоимости существенных дополнительных устройств хранения для роста БД, так что это не реальная стоимость дисков, дополнительно сконфигурированных в период проведения сопоставительных испытаний. В любом случае в конечной ценовой конфигурации нам понадобится самый большой объем.

Для большинства реальных пользователей больших БД (сотни Гбайт) конфигурирование соответствующего количества дисков емкостью 18 и 36 Гбайт для достижения требуемого объема скорее всего будет самой приемлемой отправной точкой. Если бюджет позволяет, то сконфигурируйте на 30% больше дисков, чем это требуется по объему. В конечном итоге это обеспечит некоторое резервное пространство для роста и большей гибкости при размещении данных, что позволит достичь наилучшей производительности.

•             Количество контроллеров. Наш опыт в группе разработки баз данных компании Sun показывает, что пропускная способность контроллера является меньшей проблемой для рабочих нагрузок OLTP, чем DSS. На самом деле можно избежать "узких мест" контроллеров при проведении нашего сопоставительного испытания ТРС-С, даже когда интенсивно используются все диски контроллера. Напротив, проведение испытания ТРС-D на SSA (SPARCstorage Arrays -на массивах SPARCstorage) показывает, что объем контроллера SSA был слегка превышен даже во время большой активности последовательного ввода/вывода (такого, например, как выполнение запроса по сканированию большой таблицы). Практический предел последовательных считываний из SSA составил около 17 Мбайт/сек. Этот предел можно достичь даже с меньшим количеством, чем половина от 30 дисков, поддерживаемых в наименьших SSA.

Хорошей новостью является то, что нынешнее поколение дисковых массивов от компании Sun (продукты диапазона Sun StorEdge) может похвастаться значительным увеличением пропускной способности по сравнению с предыдущим поколением (SPARCstorage Arrays). Нынешние массивы, такие как А5100 и А5200, имеют пропускную способность 90 Мбайт/сек в одном цикле, что в че-тыре-пять раз превосходит аналогичные показатели ранних SPARCstorage Arrays.

Тем не менее, ни один из массивов не обладает пропускной способностью, выдерживающей полную нагрузку на каждый диск в полностью сконфигурированном массиве. Повысить пропускную способность должен подход типа "шотландская клетка": расщепление данных между контроллерами и дисками.

В завершение следует сказать, что не стоит беспокоиться о слишком большом количестве контроллеров при конфигурировании OLTP. При конфигурировании рабочих нагрузок DSS следует использовать массивы А5200, А5100 или ТЗ, если необходим интенсивный ввод/вывод. В случае установки более ранних массивов попытайтесь избавиться от параллельного доступа ко всем дискам массива во время интенсивных последовательных считываний.

Пропускная способность основной платы (шнны). Очень непохоже, что ваше приложение БД будет потреблять всю доступную полосу пропускания шины в нынешних системах Sun. Именно Sun сумела достичь рекордных производительностей при выполнении ТРС-С и TPC-D/TPC-H на ранних серверах Enterprise 6500 и Starfire (Enterprise 10000) без расширения возможностей системной шины.

Как же это возможно, учитывая тот факт, что центральные процессоры продолжают ускоряться, а требования к производительности ввода/вывода продолжают возрастать, увеличивать нагрузку системной шины при обработке? Замысел состоит в том, что каждое новое поколение серверов Sun выпускается со значительно увеличенной пропускной способностью шины. И вновь пропускная способность системной шины была увеличена на серверах Sun Fire. Очевидно, что эта тенденция будет продолжаться.

"Узкие места" ввода/вывода
Какой объем памяти необходим?
Какова ожидаемая скорость расширения системы?
Использование ТРС-С для задания размера реальных серверов OLTP
Использование ТРС-D или ТРС-R для задания размера реальных серверов DSS

Добавить комментарий


Защитный код
Обновить