SQL.RU
 client/server technologies
 Главная | Документация | Статьи | Книги | Форум | Блоги | Опросы | Гостевая | Рассылка | Работа | Поиск | FAQ |

Сравнение производительности множества баз и экземпляров

ПУБЛИКАЦИИ  

По материалам статьи Man Xiong: Microsoft SQL Server 2000 Scalability Project-Server Consolidation. Microsoft SQL 2000 Technical Articles - Апрель 2002

Из этой статьи Вы узнаете о рекомендованных сценариях консолидации серверов баз данных, когда на одном хосте размещается много баз с относительно небольшим количеством пользователей для каждой из них. Эффективность рекомендаций проверялась на реальном финансовом приложении "PACE", разработанным подразделением Microsoft bCentral.
Статья относится к следующим версиям:

    Microsoft ® SQL Server ™ 2000 Enterprise Edition
    Microsoft Windows® 2000 Datacenter™ Server

Краткий обзор

Эта статья - плод совместных усилий Microsoft и Dell, и она призвана продемонстрировать масштабируемость Microsoft SQL Server 2000, который запускался на восьмипроцессорной серверной SMP платформе Dell. Такой сервер способен поддержать централизованную работу большого числа пользователей с тысячами баз данных, а также предоставляет возможность масштабирования за счёт добавления процессоров, памяти и дисков. Цель этой статьи состоит в том, чтобы продемонстрировать подход к успешному масштабированию возрастающей рабочей нагрузки на одном сервере, за счёт использования множества экземпляров и показать, как меняется число транзакций в минуту (TPM) на различных конфигурациях.
Ниже представлен список преимуществ, которые достигаются за счёт использования множества экземпляров на одном сервере:

  • Возможность поддержки более высокой рабочей нагрузки на одном сервере.

  • Повышение гибкости при реализации выставляемых пользователями требований к качеству и характеристикам сервисов (Service Level Agreements).

  • Возможность разнести базы данных с разными требованиями к производительности.

  • Возможность разнести базы данных с разными требованиями к резервированию и с разными моделями резервирования.

  • Возможность разнести базы данных с разными требованиями к безопасности.

  • Возможность разнести базы данных с разными схемами управления изменениями, с разными операционными требованиями и требованиями к обслуживанию.

Настоящее исследование показало, что:

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

  • Установка привязки процессоров вручную и использование множества экземпляров приводит к увеличению поддерживаемой рабочей нагрузки на 80 процентов в сравнении с установкой по умолчанию.

  • Разнесение журналов транзакций и файлов баз данных на разные устройства увеличивает рабочую нагрузку на 10 процентов.

  • Лучшие результаты достигаются, когда сервер выделен только для обслуживания SQL Server.

[В начало]

Приложение "PACE"

Приложение "PACE" предназначено для учета и финансового управления в небольших компаниях, и обеспечивает поддержку финансовых, банковских, платежных и товарных операций. Чтобы предлагать каждому клиенту безопасный контроль объектов учета и надежный многопользовательский доступ, приложение использует большое число маленьких финансовых баз данных на одном сервере, одна база данных для каждого клиента. Это способствует более гранулированному управлению безопасностью, резервированием, управлению изменениями и операционному обслуживанию. Приложение имеет больше 200 хранимых процедур в каждой базе данных, которые поддерживают работу Веб - служб.
Такой нетрадиционный дизайн выдвигает особые требования к сопровождению системы и настройки производительности SQL Server. Самое важное требование - это объем памяти, требуемый для поддержки большого количества хранимых процедур, умноженный на число баз данных. SQL Server использует виртуальное пространство памяти для компиляции планов исполнения каждой процедуры в каждой базе данных, после чего, план сохраняется в кэше процедур. Для "PACE" число планов исполнения, кэшируемых для 500 баз данных, равно 200*500 (100000 объектов в кэше). Чем больше у "PACE" число баз данных, тем больше нужен кэш процедур у сервера. Когда планов исполнения больше, чем может вместить кэш процедур, происходят перекомпиляции, которые могут снизить производительность обслуживания запросов. Традиционные методы, такие как параметризация хранимых процедур, не решают проблему.
В таких случаях, может потребоваться очень профессиональный тюнинг конфигурации, что бы увеличить размер эффективного пространства памяти для кэша процедур. В некоторых случаях, удаётся найти решение за счёт более эффективного использования процессоров, эксплуатируя параллелизм, а также за счёт оптимизации размещения дисков и выбора модели резервирования.

[В начало]

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

Когда число баз данных и результирующая рабочая нагрузка достигает некоторого уровня, группировка баз данных в нескольких экземплярах SQL Server оказывается хорошей практикой, поскольку это ведёт к снижению вытеснения памяти. Хорошая производительность достигается за счёт увеличения памяти для кэша процедур каждого экземпляра, а также обеспечивается лучшая операционная изоляция и безопасность.
Проведённые нами испытания показывают, что использование нескольких экземпляров позволяет разместить на сервере больше баз данных с сохранением приемлемого уровня производительности каждой базы.
На Рисунке 1 показана деградация производительности одного экземпляра, когда число баз данных "PACE" увеличивается от 500 до 4000. Также на рисунке показана кривая производительности, когда по 500 баз данных были размещены в отдельных экземплярах. Нагрузка создаваемая 8 экземплярами была близка к максимальной, хотя с 16 экземплярами система все еще демонстрировала приемлемую производительность.


Рисунок 1. Зависимость производительность от общего числа баз данных "PACE"

На Рисунке 2 изображён график пропускной способности из расчёта на одну базу данных, уменьшение которой наблюдается, когда увеличивается число баз данных (а также число клиентских подключений). Когда число баз данных равняется 500 на экземпляр, пропускная способность у обоих графиков равная, но для модели с множеством экземпляров она начинает уменьшается по достижении 16 экземпляров, из-за ограниченного этим числом числа процессоров.


Рисунок 2. Зависимость пропускной способности отдельной базы данных от числа баз данных "PACE"

Деградация производительности для многих тысяч баз данных "PACE" на одном экземпляре

SQL Server 2000 может использовать для кэша процедур до 2 гигабайт виртуальной памяти (или 3 гигабайта, если файле boot.ini указан ключ /3GBi). Когда число баз данных одного экземпляра увеличивается от 500 до 1000, виртуальной памяти для кэша процедуры становится недостаточно, что не позволяет держать весь объём планов исполнения запросов в памяти. Некоторые планы исполнения будут в целях высвобождения памяти изыматься из кэша, и этим будет создаваться место для планов других хранимых процедур. Вследствие этого изъятия планов, хранимые процедуры должны быть перекомпилированы при их вызове, что в определённой степени может негативно сказываться на производительности.

[В начало]

Использование нескольких экземпляров снижает вытеснение памяти

Как показано на Рисунке 3, когда физическая память превышает 4 гигабайта, размещение баз данных в нескольких экземплярах позволяет задействовать для кэша процедур больше памяти (каждый экземпляр имеет своё собственное виртуальное адресное пространство и кэш процедур).
Когда число баз данных "PACE" на одном экземпляре увеличивается до несколько тысяч, огромное число объектов базы данных потребляет для кэша процедур такой большой объём памяти, что от этого начинает страдать производительность. Кэш процедур будет сокращаться, что спровоцирует перекомпиляции. Поэтому, мы рекомендуем использовать множество экземпляров.


Рисунок 3. Эффективная память для кэша процедур на разных конфигурациях

[В начало]

Другие условия, в которых полезно множество экземпляров

Ключевым моментом того, является ли использование нескольких экземпляров выгодным с точки зрения производительность - является итоговый объем памяти, необходимый для всех планов исполнения. Этот объем определяется средним размером планов исполнения, числом хранимых процедур в базах данных и числом баз данных. Необходимость использования нескольких экземпляров может возникнуть и при использовании не очень большого числа баз данных, если в них много больших процедур, или эти процедуры очень сложные.

[В начало]

Конфигурация памяти нескольких экземпляров

Чтобы получить хорошую производительность множества экземпляров, достаточно только определить разумный размер минимальной памяти сервера, оставив другие настройки памяти без изменений, как они приняты по умолчанию. Резервируя минимальный размер используемой серверами памяти в 1 гигабайт для каждого экземпляра, и сохраняя для максимального размера памяти серверов динамическое распределение памяти, мы наблюдали 25-процентный выигрыш в производительности. Производительность была так же хороша как и при использовании оптимизированного статического распределения памяти, когда исключались затраты на постоянную калибровку памяти. При использовании этого метода нужно иметь хорошее представление о том, как могут воздействовать на распределение памяти другие приложения, исполняемые на этом же сервере. Другие приложения, конкурирующие за память, как правило, тоже воздействуют на динамическое распределение памяти. По этой причине, Microsoft рекомендует выделять для SQL Server отдельный сервер.
Другим преимуществом выделения системы с SQL Server является то, что в этом случае снижаются затраты на конфигурацию поддержки различной рабочей нагрузки на каждом из экземпляров, т.к. не требуется проводить специальные испытания и настройки для определения оптимальной конфигурации памяти. Практика выделения системы с SQL Server приводит к уменьшению необходимости перезапуска сервисов для того, что бы вступили в силу изменённые в процессе тестирования настройки памяти, которые необходимы для определения критериев достижения оптимальной производительности, когда рабочая нагрузка не одинакова у разных экземпляров.

[В начало]

Простая конфигурация памяти повышает производительность

Изменение только значений минимального размера используемой сервером памяти у всех экземпляров даёт такую же производительность, как и полностью статическое её распределение. Т.о. то время, которое могло бы понадобиться для определения оптимальных статических границ распределения памяти экземпляров может быть существенно сокращено.
Наши испытания охватывали 8 конфигураций с 16-тью экземплярами, и использовали как статические, так и динамические параметры распределения памяти. Это позволило определить, какая конфигурация показывает лучшую производительность. Все базы данных имели одинаковую рабочую нагрузку, т.к. каждый экземпляр имел одно и то же число баз данных.
Однако, в конфигурации с 16-тью экземплярами, при использовании статических настроек памяти, производительность была на 25 процентов лучше, чем при использовании полностью динамического распределения.
Для конфигурации с 16 экземплярами, и резервированием для каждого экземпляра 1 гигабайта в качестве минимального размера используемой сервером памяти, и при сохранении максимального размера используемой памяти в динамической настройке, мы наблюдали ту же самую производительность, как и при использовании оптимального статического распределения памяти.

[В начало]

Почему желательна такая конфигурация памяти

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

[В начало]

Привязка процессоров

Наши исследования показали, что ручное закрепление процессоров за отдельными экземплярами SQL Server с помощью affinity mask может повысить производительность на 80 процентов. Лучшие результаты были получены, когда экземпляры SQL Server не использовали процессоры совместно с другими прикладными процессами сервера.

[В начало]

Повышение производительности с помощью привязки процессоров

Испытания проводились на конфигурации с 8 экземплярами по 500 баз данных в каждом, и с оптимальной для них конфигурацией памяти. Рабочая нагрузка экземпляров была одинаковой. Привязка к каждому из имеющихся 8 экземпляров по одному из 8 процессоров дала 80-процентное улучшение производительности по сравнению с заданной по умолчанию установкой привязки процессоров.

[В начало]

Почему использование привязки процессоров может повысить производительность

По умолчанию, каждый поток экземпляра SQL Server планируется на следующий доступный процессор. Задание параметра affinity mask позволяет ограничить использование экземпляром только указанного в маске подмножества процессоров, и гарантирует, что каждый его поток всегда будет использовать не замаскированные процессоры, даже после перезагрузки. Такая мера позволяет снизить паразитные листания (свопинг) в рамках этого потока в многопроцессорной системе, и увеличивает cache hit ratio кэша второго уровня. Однако, использовать ручную привязку процессоров нужно с осторожностью, т.к. не одинаковая рабочая нагрузка на разных процессорах не может балансироваться динамически.
При использовании множества экземпляров на одном многопроцессорном сервере, привязка процессоров к определенным экземплярам позволяет сократить число активных потоков процессоров и уменьшить число переключений контекста, что и приводит к более оптимальному использованию кэша второго уровня.

[В начало]

Размещение по дискам

Для обеспечения возможности полного восстановления баз данных, файлы журналов транзакций никогда не должны помещаться на то же самое устройство, что и файлы баз данных. Кроме того, разнесение на физически разные диски журналов и баз данных повышает производительность.
Во время наших исследований было определено, что разнесение журналов из файлов данных на физически разные диски дало 10-процентное увеличение производительности по сравнению с их размещением на одном и том же томе.
Испытания проводились на конфигурации с 8 экземплярами по 500 баз данных в каждом, для которых были оптимизированы конфигурации памяти и привязки процессоров, и использовались две разные схемы размещения файлов на дисках, как это показано на Рисунке 4:

  • Сценарий 1: Файлы баз данных, журналы (включая файлы журналов транзакций tempdb), и файлы баз tempdb каждого экземпляра, размещались на одном дисковом массиве.

  • Сценарий 2: Файлы баз данных, журналы (включая файлы журналов транзакций tempdb), и файлы баз tempdb каждого экземпляра размещались на трех разных дисковых массивах.

Отделение файлов журналов от файлов баз данных на физически разные диски дает 10-процентное увеличение производительности.


Рисунок 4. Размещение по дискам

[В начало]

Почему вынесение журналов на физически отдельные диски улучшает производительность

Практика размещения журналов на других дисках распространена потому, что это позволяет изолировать последовательный ввод-вывод (характерный для журналов) от случайного (характерного для файлов баз данных). Это правило всё ещё работает и для сотен журналов, которые присутствовали в наших испытаниях. Выигрыш от большего числа шпинделей у многодискового тома получается меньше, чем выигрыш от разделения случайного и последовательного ввода вывода.

[В начало]

Модели резервирования

Наши исследования показали, что обслуживание рабочей нагрузки при использовании полной модели резервирования (full recovery model) может позволить достигнуть 90-процентной производительности от показателей для модели: bulk-logged recovery model (исключающей полное журналирование операций массового копирования). Это говорит о том, что имеет смысл все-таки использовать полную модель резервирования, что позволит обеспечить большую гибкость при восстановлении, и при этом не потерять много в производительности.

[В начало]

Полная модель резервирования даёт хорошую производительность

Чтобы исследовать воздействие разных моделей резервирования на производительность рабочей нагрузки, испытания проводились на конфигурации с 8 экземплярами по 500 баз данных в каждом, для которых были оптимизированы конфигурации памяти и привязки процессоров, и использовались две разные модели резервирования: full и bulk-logged. При измерениях рабочей нагрузки на модели bulk-logged было выявлено 10 процентное улучшение производительности по сравнению с полной моделью резервирования.

[В начало]

Дополнительные соображения

Microsoft рекомендует использовать полную модель резервирования для любых промышленных OLTP систем, это позволит обеспечить должную защиту данных. Bulk-logged recovery model может использоваться временно, при выполнении продолжительных операций, таких как создание индексов или массовая загрузка данных. Производительность массовых операций повышается, но за счет увеличения риска потери данных. Для получения подробной информации, обратитесь к соответствующим разделам SQL Server Books Online.

[В начало]

Перевод: Александра Гладченко  2005г.

Rambler's Top100 Рейтинг@Mail.ru  Administrator: Обратная связь 
Copyright: SQL.Ru 2000-2013