Управление ресурсами в сжатых эластичных пулах

Применимо к: База данных SQL Azure

Эластичные пулы Базы данных SQL Azure — это экономичное решение для управления множеством баз данных с различным уровнем использования ресурсов. Всем базам данных в эластичном пуле выделяются для совместного использования одни и те же ресурсы (ЦП, память, рабочие потоки, место в хранилище и база данных tempdb). Это происходит при условии, что только подмножество баз данных в пуле будет использовать вычислительные ресурсы в конкретный момент времени. Это допущение позволяет эластичным пулам снижать издержки. Вместо оплаты всех ресурсов, которые потенциально могут понадобиться каждой отдельной базе данных, клиенты платят за гораздо меньший набор ресурсов, совместно используемых всеми базами данных в пуле.

Управление ресурсами

Система должна тщательно контролировать совместное использование ресурсов, чтобы минимизировать эффект "шумного соседа", когда база данных с высоким потреблением ресурсов влияет на другие базы данных в этом же эластичном пуле. База данных SQL Azure достигает этих целей путем внедрения управления ресурсами. В то же время система должна предоставлять достаточно ресурсов для надежной работы функций высокой доступности и аварийного восстановления, резервного копирования, мониторинга, хранилища запросов, автоматической настройки и других.

Основная цель проектирования эластичных пулов — это снижение издержек. Поэтому система позволяет клиентам создавать пулы высокой плотности с максимальным (или близким к этому значению) количеством баз данных, но с умеренным распределением вычислительных ресурсов. По той же причине система не резервирует все потенциально необходимые ресурсы для своих внутренних процессов, но эти ресурсы делятся между внутренними процессами и рабочими нагрузками пользователей.

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

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

• Настройте рабочую нагрузку запросов: сократите потребление ресурсов или распределите его между несколькими базами данных по времени.
• Уменьшите плотность пула: переместите несколько баз данных в другой пул или сделайте их автономными.
• Масштабируйте пул, чтобы получить дополнительные ресурсы.

Дополнительную информацию о реализации последних двух решений см. в разделе Практические рекомендации в этой статье. Снижение конкуренции за ресурсы положительно влияет на рабочие нагрузки пользователей и внутренние процессы, а также позволяет системе поддерживать ожидаемый уровень обслуживания.

Мониторинг потребления ресурсов

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

В Базе данных SQL Azure доступны несколько метрик, которые относятся к этому типу мониторинга. Превышение рекомендованного среднего значения для каждой метрики приводит к конкуренции за ресурсы в пуле. Эту проблему можно решить с помощью одного из действий, описанных ранее.

Чтобы отправить оповещение, когда использование ресурсов пула (ЦП, ввод-вывод данных, ввод-вывод журнала, рабочие потоки и т. д.) превышает пороговое значение, создайте оповещения для базы данных Azure SQL с помощью портала Azure или используйте командлет PowerShell Add-AzMetricAlertRulev2. При мониторинге гибких пулов также можно создавать оповещения для отдельных баз данных в пуле, если это необходимо в вашем сценарии.

Кроме этих метрик, для Базы данных SQL Azure доступно представление, которое возвращает фактические ограничения управления ресурсами. Также можно использовать дополнительные представления, которые возвращают статистику использования ресурсов на уровне пула и на уровне группы рабочей нагрузки.

Эти представления позволяют отслеживать использование ресурсов и устранять проблемы с конкуренцией за них практически в реальном времени. Пользовательская рабочая нагрузка на первичной реплике и вторичной реплике для чтения, включая геореплики, классифицируется в пул ресурсов SloSharedPool1 и группу рабочей нагрузки UserPrimaryGroup.DBId[N], где N — это значение идентификатора базы данных.

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

Практические рекомендации

Сохраните достаточный запас ресурсов. При возникновении конфликтов ресурсов и снижения производительности может потребоваться перемещение некоторых баз данных из затронутого эластичного пула или масштабирование пула, как отмечалось ранее. Но для выполнения этих действий требуются дополнительные вычислительные ресурсы. Для пулов уровня "Премиум" и "Критически важный для бизнеса" нужно будет перенести все данные для перемещаемых баз данных. Если же пул масштабируется, перенос потребуется для всех баз данных эластичного пула. Передача данных — это длительная и ресурсоемкая операция. Если пул уже находится в условиях существенной нехватки ресурсов, сами действия по устранению рисков будут еще больше снижать производительность. В крайних случаях может быть невозможно решить проблему с ресурсами с помощью перемещения базы данных или увеличения масштаба пула, так как необходимые ресурсы недоступны. В этом случае временное сокращение рабочей нагрузки запросов в затронутом эластичном пуле может быть единственным решением.

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

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

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

Создавайте новые базы данных в пуле для карантина. Существует определенный риск, когда новые базы данных создаются часто, например при работе приложений, которые используют модель "один клиент на базу данных". Новая база данных, помещенная в существующий эластичный пул, может потреблять значительное количество ресурсов и влиять на другие базы данных и внутренние процессы в пуле. Чтобы снизить этот риск, создайте отдельный пул для карантина с достаточным запасом ресурсов. Используйте этот пул для новых баз данных с еще неизвестными моделями потребления ресурсов. Оставьте базу данных в этом пуле на один бизнес-цикл, например неделю или месяц, чтобы понять, как она потребляет ресурсы. После этого ее можно переместить в пул с емкостью, достаточной для размещения такой дополнительной нагрузки.

Отслеживайте используемое и выделенное пространство. Если выделенное пространство пула (общий размер всех файлов базы данных в хранилище для всех баз данных в пуле) достигает максимального размера пула, могут возникнуть ошибки нехватки места. Если выделенное пространство имеет тенденцию к увеличению и приближается к максимальному размеру пула, для устранения рисков можно выполнить указанные ниже действия.

• Переместите некоторые базы данных из пула, чтобы уменьшить общее выделенное пространство.
• Управление пространством файлов в базах данных для уменьшения пустого выделенного пространства в файлах.
• Масштабирование пула до цели службы с большим максимальным размером пула.

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

• Переместите некоторые базы данных из пула, чтобы сократить общее используемое пространство.
• Перемещение (архив) данных за пределы базы данных или удаление больше не нужных данных.
• Реализуйте сжатие данных.
• Масштабирование пула до цели службы с большим максимальным размером пула.

Избегайте серверов с чрезмерной плотностью. База данных SQL Azure поддерживает до 5000 баз данных на сервер. Клиенты, использующие эластичные пулы с тысячами баз данных, могут рассмотреть возможность размещения нескольких эластичных пулов на одном сервере с общим количеством баз данных до поддерживаемого ограничения. Но серверы с тысячами баз данных создают проблемы при эксплуатации. Будут выполняться медленнее операции, для которых требуется перебор всех баз данных на сервере, например для просмотра баз данных на портале. Ошибки при эксплуатации, например неправильная модификация правил брандмауэра или имен для входа на уровне сервера, повлияют на большее количество баз данных. При случайном удалении сервера потребуется помощь службы поддержки Майкрософт, чтобы восстановить базы данных на этом сервере. Это приведет к длительному отключению всех затронутых баз данных.

Ограничьте количество баз данных на одном сервере, чтобы оно было меньше, чем максимально поддерживаемое. Для большинства сценариев оптимальным будет использование до 1000–2000 баз данных на один сервер. Чтобы снизить вероятность случайного удаления сервера, настройте блокировку удаления для сервера или его группы ресурсов.

Примеры

Просмотр параметров емкости отдельных баз данных

В динамическом административном представлении sys.dm_user_db_resource_governance можно просмотреть фактические параметры конфигурации и емкости, используемые управлением ресурсами в текущей базе данных или эластичном пуле. Дополнительные сведения см. в sys.dm_user_db_resource_governance.

Запустите этот запрос в любой базе данных в эластичном пуле. Все базы данных в пуле имеют одинаковые параметры управления ресурсами.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Мониторинг общего потребления ресурсов эластичного пула

Используйте представление каталога системы sys.elastic_pool_resource_stats для отслеживания потребления ресурсов всем пулом. Дополнительные сведения см. в sys.elastic_pool_resource_stats.

Этот пример запроса для просмотра последних 10 минут следует выполнить в базе данных master логического сервера Azure SQL, содержащего нужный эластичный пул.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Мониторинг использования отдельных ресурсов базы данных

Используйте динамическое административное представление sys.dm_db_resource_stats для отслеживания потребления ресурсов отдельными базами данных. Дополнительные сведения см. в sys.dm_db_resource_stats. Каждые 15 секунд создается запись, даже если в базе данных не выполняется никаких действий. Хранятся данные за период длительность около одного часа.

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

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Для более длительного хранения с меньшей частотой можно использовать следующий запрос к sys.resource_stats, запустив его в базе данных master логического сервера Azure SQL. Дополнительные сведения см. в sys.resource_stats (База данных SQL Azure). Каждые пять минут создается одна запись, а данные хранятся за период длительность две недели.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Мониторинг использования памяти

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

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Мониторинг использования пространства журнала tempdb

Этот запрос возвращает текущее значение метрики tempdb_log_used_percent, которое показывает использование журнала транзакций в tempdb относительно его максимально допустимого размера. Его можно выполнить в любой базе данных эластичного пула.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Связанный контент

• Эластичные пулы помогают управлять и масштабировать несколько баз данных в Базе данных SQL Azure
• Мониторинг и настройка
• Мониторинг и настройка производительности в Базе данных SQL Azure и Управляемом экземпляре SQL Azure