Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010)

 

Применимо к: SharePoint Foundation 2010, SharePoint Server 2010

Последнее изменение раздела: 2016-11-30

В этой статье описываются планирование и настройка уровня хранилища и базы данных Microsoft SQL Server в среде Microsoft SharePoint Server 2010.

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

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

Перед чтением этой статьи необходимо ознакомиться с общими принципами, изложенными в документе Capacity management and sizing for SharePoint Server 2010.

Процесс проектирования и настройки уровня хранилища и базы данных для продуктов SharePoint 2010

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

  • Определение требований к дисковому пространству и подсистеме ввода-вывода для хранилища и SQL Server

  • Выбор версии и выпуска SQL Server

  • Проектирование архитектуры хранилища на основе требований по емкости и вводу-выводу

  • Оценка требований к памяти

  • Общие сведения о требованиях к топологии сети

  • Настройка конфигурации SQL Server

  • Проверка производительности и надежности хранилища

Определение требований к дисковому пространству и подсистеме ввода-вывода для хранилища и SQL Server

Структура хранилища определяется рядом факторов, связанных с архитектурой SharePoint Server 2010. Наиболее важные факторы — объем контента, используемые функции и приложения-службы, число ферм и требования доступности.

Прежде чем планировать систему хранения, необходимо понять, какие базы данных могут использоваться в SharePoint Server 2010.

Содержание:

  • Базы данных, используемые продуктами SharePoint 2010

  • Общие сведения о SQL Server и IOPS

  • Оценка основных требований по объему хранилища и показателям IOPS

  • Определение требований по объему хранилища и IOPS для приложений-служб

  • Определение потребностей в доступности

Базы данных, используемые продуктами SharePoint 2010

Состав баз данных, установленных для SharePoint Server 2010, зависит от того, какие компоненты используются в текущей среде. В любой среде Продукты SharePoint 2010 используются системные базы данных SQL Server. В этом разделе приводится сводка баз данных, устанавливаемых для SharePoint Server 2010. Дополнительные сведения см. в статьях Типы и описания баз данных (SharePoint Server 2010) и Модели базы данных (https://go.microsoft.com/fwlink/p/?LinkId=187968).

Версия и выпуск продукта Базы данных

SharePoint Foundation 2010

Конфигурация

Контент центра администрирования

Контент (одна или несколько)

Служба сбора данных об использовании и исправности

Служба подключения к бизнес-данным

Служба реестра приложений (как обновление каталога бизнес-данных Microsoft Office SharePoint Server 2007)

Служба параметров подписки (включенная в Windows PowerShell)

Дополнительные базы данных для выпуска SharePoint Server 2010 Standard

Приложение-служба поиска:

  • Администрирование поиска

  • Обход контента (одна или несколько)

  • Свойство (одно или несколько)

Приложение-служба профилей пользователей:

  • Профиль

  • Синхронизация

  • Теги

Приложение-служба Web Analytics

  • Поэтапное развертывание

  • Отчетность

Безопасное хранилище

Состояние

Управляемые метаданные

Word Automation Services

Дополнительные базы данных для выпуска SharePoint Server 2010 Enterprise

PerformancePoint

Дополнительные базы данных для Project Server 2010

Черновики

Опубликованные проекты

Архив

Отчетность

Дополнительная база данных для FAST Search Server

Администрирование поиска

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

  • Microsoft SQL Server 2008 R2 PowerPivot для Microsoft SharePoint 2010 можно использовать в среде SharePoint Server 2010, включающей SQL Server 2008 R2 Enterprise Edition и службы SQL Server Analysis Services. В случае необходимости также запланируйте поддержку базы данных приложения PowerPivot и дополнительную нагрузку на систему. Дополнительные сведения см. в статье Планирование развертывания PowerPivot на ферме SharePoint (https://go.microsoft.com/fwlink/p/?LinkID=186698).

  • В любой среде продуктов SharePoint 2010 можно использовать подключаемый модуль отчетов Microsoft SQL Server 2008 (SSRS). Если он используется, запланируйте поддержку двух баз данных Службы SQL Server 2008 Reporting Services и дополнительную нагрузку, связанную с Службы SQL Server 2008 Reporting Services.

Общие сведения о SQL Server и IOPS

На любом сервере, где размещается SQL Server, крайне важно обеспечить максимально быстрый ответ подсистемы ввода-вывода.

Увеличение числа дисков или массивов и повышение их быстродействия гарантируют достаточное количество операций ввода-вывода в секунду (IOPS) при низкой задержке в обработке доступа и обслуживании очередей на всех дисках.

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

Прежде чем развертывать новую ферму, рекомендуем измерить производительность подсистемы ввода-вывода, используя средство SQLIO для измерения производительности дисковой подсистемы. Дополнительные сведения см. в статье Средство SQLIO для измерения производительности дисковой подсистемы (https://go.microsoft.com/fwlink/p/?LinkID=105586).

Более подробную информацию о том, как анализировать требования по IOPS с точки зрения SQL Server, см. в статье, посвященной анализу характеристик ввода-вывода и определение размеров систем хранения данных для приложений баз данных SQL Server (https://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx).

Оценка основных требований по объему хранилища и показателям IOPS

Емкость хранилища конфигурации и контента и соответствующие показатели IOPS — это главное, что необходимо планировать в каждой среде SharePoint Server 2010.

Хранилище конфигурации и IOPS

Требования к емкости хранилища для баз данных конфигурации и контента центра администрирования не слишком высоки. Рекомендуется выделить 2 ГБ для базы данных конфигурации и 1 ГБ для базы данных контента центра администрирования. Со временем размер базы данных конфигурации может превысить 1 ГБ, но он растет не очень быстро — примерно на 40 МБ для каждых 50 тысяч семейств сайтов.

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

Примечание

Если для повышения доступности базы данных конфигурации требуется использовать зеркальное отображение баз данных SQL Server, необходимо использовать полную модель восстановления.

Требования по IOPS для баз данных конфигурации и контента центра администрирования минимальны.

Хранилище контента и IOPS

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

Дополнительные сведения о методологии общего планирования загрузки см. в статье Capacity management and sizing for SharePoint Server 2010.

Оценка объема хранилища для базы данных контента

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

  1. Подсчитайте предполагаемое количество документов. Оно обозначается в формуле буквой D.

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

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

  2. Оцените средний размер документов, которые будут помещаться в хранилище. Он обозначается в формуле буквой S. Имеет смысл оценивать средние значения для разных типов или групп сайтов. Средние размеры файла для личных сайтов, мультимедийных репозиториев и порталов подразделений могут существенно отличаться друг от друга.

  3. Оцените число элементов списков в среде. Оно обозначается в формуле буквой L.

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

  4. Определите примерное число версий. Оцените, сколько версий в среднем будет иметь документ библиотеки (обычно это значение гораздо меньше максимально допустимого числа версий). Оно обозначается в формуле буквой V.

    Значение V должно быть больше нуля.

  5. Оцените размер баз данных контента по следующей формуле:

    Размер базы данных = ((D × V) × S) + (10 КБ × (L + (V × D)))

    В этой формуле константа 10 КБ представляет примерную оценку объема метаданных, необходимых для SharePoint Server 2010. Если в системе требуется активно использовать метаданные, эту константу можно увеличить.

Например, если по этой формуле оценить объем пространства, необходимого для файлов данных базы данных контента в среде совместной работы с приведенными ниже характеристиками, получится около 105 ГБ.

Входные данные Значение

Число документов (D)

200 000

Из расчета 10 000 пользователей с 20 документами каждый

Средний размер документа (S)

250 КБ

Элементы списков (L)

600 000

Число версий, помимо текущей (V)

2

При максимально допустимом числе версий 10

Размер базы данных = (((200000 x 2)) × 250) + ((10 КБ × (600000 + (200000 x 2))) = 110000000 КБ, или 105 ГБ

Функциональные элементы, влияющие на размер баз данных контента

Использование следующих функциональных элементов SharePoint Server 2010 может существенно повлиять на размер баз данных контента:

  • Корзины   Пока документ не удален окончательно из корзин первого и второго уровней, он занимает место в базе данных контента. Подсчитайте, сколько документов удаляется каждый месяц, чтобы определить, как наличие корзин отражается на размере баз данных контента. Дополнительную информацию см. в статье Настройка параметров корзины (SharePoint Server 2010).

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

    • Оцените число новых записей аудита для сайта и умножьте его на 2 КБ (максимальный размер записи обычно составляет 4 КБ, средний — около 1 КБ).

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

  •  Office Web Apps. Если используется Office Web Apps, объем кэша Office Web Apps может существенно повлиять на размер базы данных контента. По умолчанию объем кэша Office Web Apps устанавливается равным 100 ГБ. Дополнительную информацию о размере кэша Office Web Apps см. в статье Управление кэшем Office Web Apps.

Оценка требований по IOPS для базы данных контента

Требования к показателям IOPS для баз данных контента варьируются в зависимости от используемой среды, размера дискового пространства и числа серверов. В общем случае рекомендуется сравнить прогнозируемую рабочую нагрузку в текущей среде с одним из протестированных нами решений. Подробнее об этом см. в разделе Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010).

Важно!

Тестирование контента, описываемое в этом разделе, еще не завершено. Регулярно возвращайтесь к нему за дополнительной информацией.

Оценка требований к объему хранилища и IOPS для приложений-служб

Оценив требования к объему хранилища и IOPS для контента, необходимо определить аналогичные требования в отношении приложений-служб, используемых в рабочей среде.

Требования к объему хранилища и IOPS для приложений-служб SharePoint Server 2010

Для оценки требований к системе хранения для приложений-служб сначала следует ознакомиться с приложениями-службами и способом их использования. Приложения-службы, доступные в SharePoint Server 2010 и использующие базы данных, указаны в следующей таблице.

Приложение-служба Рекомендации по оценке размера

Поиск

Для поиска требуются три базы данных. Рабочая среда может включать несколько баз данных свойств и обхода контента.

База данных администрирования поиска обычно невелика — достаточно выделить 10 ГБ.

Чтобы оценить требуемое пространство для баз данных свойств и обхода контента, используйте следующие коэффициенты:

  • Обход контента: 0,046 × (суммарный размер баз данных контента)

  • Свойства: 0,015 × (суммарный размер баз данных контента)

Требования к IOPS для поиска достаточно высоки.

  • Для базы данных обхода контента поиск требует от 3500 до 7000 IOPS.

  • Для базы данных свойств поиск требует 2000 IOPS.

Подробную информацию об оценке ресурсов, необходимых для поиска, см. в статье Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010).

Архитектура FAST Search Server 2010 для SharePoint другая. База данных обхода контента имеет те же требования к операциям ввода-вывода за секунду, база данных свойств используется только для поиска людей, есть также дополнительная база данных администрирования поиска. Дополнительные сведения о FAST Search Server 2010 for SharePoint см. в статьях Plan search topology (FAST Search Server 2010 for SharePoint) и Performance and capacity management (FAST Search Server 2010 for SharePoint).

Профиль пользователя

Приложение-служба профилей пользователей связано с тремя базами данных: базой данных профилей, базой данных синхронизации и базой данных тегов.

Чтобы оценить объем хранилища, необходимого для этих баз данных, используйте следующую информацию.

  • Профиль. В среде с параметрами по умолчанию, настроенной на использование Active Directory, для базы данных профилей требуется примерно 1 МБ на каждый профиль.

  • Синхронизация. В среде с параметрами по умолчанию при наличии нескольких групп на одного пользователя для базы данных синхронизации требуется примерно 630 КБ на каждый профиль пользователя. 90% этого пространства займет файл данных.

  • Теги. По умолчанию для базы данных тегов требуется примерно 0,009 МБ на каждый тег, комментарий или оценку. При расчете количества тегов или заметок, с которыми будут работать пользователи, воспользуйтесь следующими сведениями о сайте del.icio.us:

    • Примерно 10% пользователей считаются активными.

    • Активные пользователи создают по 4,5 тега и 1,8 комментариев в месяц.

В настроенной по умолчанию интерактивной среде совместной работы, где насчитывается 160 тыс. профилей пользователей, 5 групп, 79 тыс. тегов, комментариев и оценок (2500 комментариев, 76 000 тегов и 800 оценок), базы данных достигают следующих размеров:

 

Имя базы данных Размер базы данных

Профиль

155 ГБ

Синхронизация

96 ГБ

Теги

0,66 ГБ

Управляемые метаданные

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

Web Analytics

Служба Web Analytics использует две базы данных: базу данных поэтапного развертывания и базу данных отчетности. На их размер влияют многие факторы, включая срок хранения данных, объем ежедневно отслеживаемых данных, число сайтов, семейств сайтов и дочерних сайтов в анализируемом приложении. Подробную информацию об оценке требований к размерам и IOPS см. в статье Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010).

Безопасное хранилище

Размер базы данных приложения-службы Secure Store определяется числом учетных записей в хранилище и числом строк в таблице аудита. Рекомендуется выделить пространство из расчета 5 МБ на каждую тысячу учетных записей. Требования по IOPS минимальны.

Состояние

Приложение-служба состояния использует одну базу данных. Для нее рекомендуется выделить 1 ГБ. Требования по IOPS минимальны.

Служба автоматизации Word

Приложение-служба автоматизации Word использует одну базу данных. Для нее рекомендуется выделить 1 ГБ. Требования по IOPS минимальны.

PerformancePoint

Приложение-служба PerformancePoint использует одну базу данных. Для нее рекомендуется выделить 1 ГБ. Требования по IOPS минимальны.

Определение потребностей в доступности

Доступность — это степень, в которой среда SharePoint Server 2010 воспринимается пользователями как доступная. Доступная система устойчива, то есть влияющие на службу инциденты возникают нечасто, и при их возникновении предпринимаются своевременные и эффективные меры.

Требования в отношении доступности могут существенно увеличить объем необходимого пространства. Дополнительные сведения об этом см. в статье Планирование доступности (SharePoint Server 2010).

Выбор версии и выпуска SQL Server

Хотя Продукты SharePoint 2010 может работать в среде Microsoft SQL Server 2008 R2, SQL Server 2008 или SQL Server 2005, настоятельно рекомендуется использовать среду SQL Server 2008 или SQL Server 2008 R2 выпуска Enterprise, чтобы получить доступ к предлагаемым ими возможностям повышения производительности, доступности, безопасности и управляемости. Дополнительную информацию о преимуществах использования SQL Server 2008 R2 Enterprise Edition см. в статье Продукты SQL Server 2008 R2 и SharePoint 2010: эффективная совместная работа (технический документ) (SharePoint Server 2010).

В частности, могут оказаться полезными следующие функции:

  • Сжатие резервных копий. Сжатие резервных копий позволяет ускорить резервное копирование в SharePoint. Оно доступно в выпусках SQL Server 2008 Enterprise Edition и SQL Server 2008 R2 Standard Edition. Задав сжатие в скрипте резервного копирования или настроив сервер с SQL Server для сжатия по умолчанию, можно значительно сократить размер резервных копий базы данных и доставляемых журналов. Дополнительные сведения см. в статье Сжатие резервных копий (SQL Server) (https://go.microsoft.com/fwlink/p/?LinkId=129381).

    Примечание

    Сжатие данных SQL Server не поддерживается для Продукты SharePoint 2010, за исключением баз данных приложений службы поиска.

  • Прозрачное шифрование данных   Если требования безопасности включают прозрачное шифрование данных, необходимо использовать выпуск SQL Server Enterprise.

  • Приложение-служба Web Analytics   Если для проведения анализа планируется привлекать приложение-службу Web Analytics, целесообразно использовать выпуск SQL Server Enterprise, чтобы в системе можно было использовать разбиение таблиц на разделы.

  • Развертывание контента   Если планируется использовать средство развертывания контента, рекомендуется выбрать SQL Server Enterprise, чтобы в системе можно было использовать снимки базы данных SQL Server.

  • Удаленное хранилище больших двоичных объектов   Чтобы обеспечить удаленное хранение больших двоичных объектов в базе данных или каталоге вне набора файлов, связанных с каждой базой данных контента, необходимо использовать выпуск SQL Server 2008 или SQL Server 2008 R2 Enterprise.

  • Регулятор ресурсов. Регулятор ресурсов — технология, представленная в SQL Server 2008. Она позволяет управлять рабочей нагрузкой и ресурсами SQL Server благодаря установке ограничений на потребление ресурсов для входящих запросов. Регулятор ресурсов дает возможность различать рабочие нагрузки и выделять ресурсы ЦП и памяти, когда их запрашивают, с учетом установленных ограничений. Она доступна только в SQL Server 2008 с SQL Server 2008 R2 Enterprise. Дополнительные сведения об использовании регулятора ресурсов см. в статье об управлении рабочей нагрузкой SQL Server с помощью регулятора ресурсов.

    Регулятор ресурсов рекомендуется использовать вместе с SharePoint Server 2010, чтобы решать следующие задачи:

    • Ограничивать объем ресурсов SQL Server, которые потребляются веб-серверами, охватываемыми компонентом обхода контента при поиске. Рекомендуется установить для компонента обхода контента ограничение в 10 % от ресурсов ЦП, доступных в системе, находящейся под нагрузкой.

    • Отслеживать количество ресурсов, потребляемых в системе каждой базой данных, — например, с помощью регулятора ресурсов можно определять наилучший порядок размещения баз данных на компьютерах SQL Server.

  • PowerPivot для SharePoint 2010   Позволяет пользователям совместно работать с создаваемыми ими моделями данных и анализами в Excel и браузере с автоматическим обновлением результатов анализа. Входит в состав SQL Server 2008 R2 Enterprise Edition Analysis Services.

Проектирование архитектуры хранилища на основе требований по емкости и вводу-выводу

Производительность системы в немалой степени зависит от архитектуры хранилища и типов дисков, выбранных для рабочей среды.

Содержание:

  • Выбор архитектуры хранилища

  • Выбор типов дисков

  • Выбор типов RAID

Выбор архитектуры хранилища

В SharePoint Server 2010 поддерживаются архитектуры хранилищ DAS (Direct Attached Storage), SAN (Storage Area Network) и NAS (Network Attached Storage), причем NAS поддерживается только для баз данных контента, настроенных на использование удаленного хранилища больших двоичных объектов. Выбор архитектуры зависит от многих факторов, связанных с используемым бизнес-решением и имеющейся инфраструктурой.

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

DAS

DAS — цифровая система хранения, подсоединяемая к серверу или рабочей станции непосредственно, без использования промежуточной сети хранения. Типы физических дисков DAS включают SAS (Serial Attached SCSI) и SATA (Serial Attached ATA).

В общем случае рекомендуется выбирать архитектуру DAS, если платформа общего хранилища не гарантирует время реакции 20 мс и достаточные значения среднего и пикового показателей IOPS.

SAN

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

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

Общее хранилище обладает следующими преимуществами:

  • Упрощается перераспределение дискового пространства между серверами.

  • Обслуживается сразу несколько серверов.

  • Число дисков, к которым может производиться доступ, неограниченно.

NAS

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

Примечание

NAS поддерживается только для баз данных контента, настроенных на использование удаленного хранилища больших двоичных объектов. Любое устройство NAS должно отвечать на команду ping в течение 1 мс и возвращать первый байт данных в течение 20 мс. Это ограничение не распространяется на локальный провайдер SQL Server FILESTREAM, поскольку он сохраняет данные только локально, на том же сервере.

Выбор типов дисков

От типов дисков, используемых в системе, может зависеть ее надежность и производительность. При прочих равных условиях, чем больше диск, тем больше среднее время поиска дорожки. SharePoint Server 2010 поддерживает следующие типы дисков:

  • SCSI (Small Computer System Interface)

  • SATA (Serial Advanced Technology Attachment)

  • SAS (Serial-attached SCSI)

  • FC (Fibre Channel)

  • IDE (Integrated Device Electronics)

  • SSD (Solid State Drive) или флэш-диск

Выбор типов RAID

Технология RAID (избыточный массив независимых дисков) часто используется для повышения производительности отдельных дисков (путем расслоения данных по нескольким дискам) и усиления защиты от сбоев отдельных дисков.

В SharePoint Server 2010 поддерживаются все типы RAID, однако использовать рекомендуется RAID 10 или специализированное решение RAID с эквивалентными характеристиками.

При настройке массива RAID выровняйте файловую систему по смещению, установленному производителем. Если указания производителя отсутствуют, см. статью, содержащую практические советы по проверке системы ввода-вывода перед развертыванием SQL Server (https://go.microsoft.com/fwlink/p/?LinkID=105583).

Дополнительные сведения о подготовке RAID и подсистемы ввода-вывода SQL Server см. в статье, содержащей практические советы по SQL Server (https://go.microsoft.com/fwlink/p/?LinkId=168612).

Оценка требований к памяти

Объем памяти, необходимой для SharePoint Server 2010, непосредственно связан с размерами баз данных контента, размещенных на сервере SQL Server.

По мере добавления приложений-служб и функциональных компонентов требования, вероятно, будут расти. В следующей таблице приводятся рекомендации по объему памяти.

Примечание

Наши определения развертывания небольшого и среднего масштабов приведены в разделе Эталонные архитектуры статьи Обзор управления емкостью и изменения размера для SharePoint Server 2010.

Общий размер баз данных контента Рекомендуемый объем ОЗУ для компьютера SQL Server

Минимум для небольшой рабочей среды развертывания

8 ГБ

Минимум для средней рабочей среды развертывания

16 ГБ

Рекомендуемый размер до 2 терабайт

32 ГБ

Рекомендуемый размер — от 2 до 5 терабайт

64 ГБ

Рекомендуемый размер — более 5 терабайт

Дополнительная память свыше 64 ГБ может увеличить скорость кэширования SQL Server

Примечание

Эти значения превышают рекомендуемые минимальные значения для SQL Server из-за распределения данных, необходимых для среды SharePoint Server 2010. Дополнительные сведения о системных требованиях SQL Server см. в статье, посвященной требованиям к оборудованию и программному обеспечению для установки SQL Server 2008 (https://go.microsoft.com/fwlink/p/?LinkId=129377).

На объем памяти могут влиять и другие факторы:

  • Использование зеркального отображения SQL Server.

  • Частое использование файлов размером более 15 МБ.

Общие сведения о требованиях к топологии сети

Необходимо планировать систему сетевых подключений внутри ферм и между фермами. Рекомендуется использовать сеть с низкой задержкой.

Далее приводятся некоторые практические советы и рекомендации:

  • Соединение между любым сервером фермы и сервером SQL Server должно иметь пропускную способность и задержку уровня локальной сети. Задержка не должна превышать 1 мс.

  • Не рекомендуется использовать топологию территориально-распределенной сети, в которой сервер SQL Server развертывается из других компонентов фермы в удаленном режиме по сети с задержкой более 1 мс. Такая топология не тестировалась.

  • Разворачивайте соответствующую территориально-распределенную сеть, если планируется использовать зеркальное отображение или доставку журналов SQL Server для поддержания актуального состояния удаленных сайтов.

  • Рекомендуется оборудовать веб-серверы и серверы приложений двумя сетевыми адаптерами: один адаптер будет обрабатывать трафик конечных пользователей, а другой обеспечивать связь с серверами SQL Server.

Настройка конфигурации SQL Server

В следующих разделах описывается планирование настройки конфигурации SQL Server для SharePoint Server 2010.

Содержание:

  • Определение требуемого количества экземпляров серверов

  • Конфигурация дискового пространства и памяти

  • Задание параметров SQL Server

  • Конфигурация баз данных

Оценка требуемого числа серверов

В целом сервер SharePoint Server 2010 разрабатывался в расчете на использование горизонтального масштабирования SQL Server — т. е. SharePoint Server 2010 может работать лучше с большим числом серверов среднего размера, на которых запущен SQL Server, чем с небольшим числом крупных серверов.

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

Необходимость в развертывании дополнительного сервера базы данных SQL Server может возникать в следующих случаях:

  • если используется более четырех веб-серверов, использующих полную емкость;

  • Добавьте дополнительный сервер базы данных, если текущий сервер достиг своего предела мощности в отношении ОЗУ, ЦП, дисковых операций ввода-вывода, объема дисков или пропускной способности сети.

Примечание

Майкрософт поддерживает серверные конфигурации, не соответствующие этим условиям.

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

Конфигурация дискового пространства и памяти

На сервере, на котором запущен SQL Server 2008, рекомендуется отвести для кэша второго уровня на каждом ЦП не менее 2 МБ для оптимизации работы памяти.

Следуйте рекомендациям производителя по настройке конфигурации хранилища

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

При отсутствии указаний от производителя рекомендуем настроить хранилище для SQL Server 2008 с помощью служебной программы DiskPart.exe для настройки дисков. Дополнительные сведения см. в статье, содержащей практические советы по проверке системы ввода-вывода перед развертыванием (https://go.microsoft.com/fwlink/p/?LinkID=105583).

Подготовьте как можно больше ресурсов

Убедитесь, что каналы ввода-вывода SQL Server, предназначенные для обмена данными с дисками, не используются другими приложениями, например файлом подкачки страниц или журналами IIS.

Обеспечьте максимальную пропускную способность шины. Чем она больше, тем выше надежность и производительность. Имейте в виду, что диск — не единственный потребитель полосы пропускания шины; например, следует всегда учитывать сетевой доступ.

Задание параметров SQL Server

Перед развертыванием SharePoint Server необходимо настроить следующие параметры SQL Server.

  • Не включайте автоматическое создание статистики на сервере SQL Server, поддерживающем SharePoint Server. SharePoint Server настраивает необходимые параметры при подготовке и обновлении. Автосоздание статистики может существенно изменить план выполнения запроса, передав его от одного экземпляра SQL Server другому экземпляру SQL Server. Поэтому для согласованной поддержки всех клиентов SharePoint Server по мере необходимости предлагает кодированные указания к запросам, чтобы обеспечить максимальную производительность независимо от сценария работы.

  • Чтобы обеспечить оптимальную производительность, настоятельно рекомендуем присвоить значение 1 параметру max degree of parallelism (MAXDOP) для экземпляров SQL Server, на которых размещены базы данных SharePoint Server 2010. Дополнительные сведения о настройке параметра max degree of parallelism см. в статье, посвященной параметру max degree of parallelism (https://go.microsoft.com/fwlink/p/?LinkId=189030).

  • Чтобы обеспечить удобство обслуживания, настройте псевдонимы для подключения к SQL Server для каждого сервера базы данных, входящего в ферму. Псевдоним для подключения — это альтернативное имя, которое можно использовать для подключения к экземпляру SQL Server. Дополнительные сведения см. в статье, посвященной установке псевдонима SQL Server (SQL Server Management Studio) (https://go.microsoft.com/fwlink/p/?LinkId=189030).

Конфигурация баз данных

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

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

В идеальном варианте базу данных tempdb, базы данных контента, базу данных использования, базы данных поиска и журналы транзакций SQL Server 2008 следовало бы размещать на разных жестких дисках.

Далее приводятся некоторые практические советы и рекомендации по назначению приоритетов данным.

  • При выборе данных для более быстродействующих дисков соблюдайте следующую очередность:

    1. Файлы данных tempdb и журналы транзакций

    2. Файлы журналов транзакций баз данных

    3. Базы данных поиска, исключая базу данных администрирования поиска

    4. Файлы данных баз данных

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

  • Результаты тестирования и отзывы клиентов свидетельствуют о том, что производительность фермы SharePoint Server 2010 может значительно упасть из-за недостаточно быстрого выполнения дисковых операций ввода-вывода для tempdb. Чтобы избежать этого, размещайте tempdb на выделенных дисках. Если наблюдается или ожидается высокая нагрузка (т. е. среднее время операции чтения или записи превышает 20 мс), разместите файлы на разных дисках или замените диски более быстродействующими.

  • Чтобы достичь оптимальной производительности, разместите базу данных tempdb в массиве RAID 10. Число файлов данных tempdb должно равняться числу основных ЦП, и эти файлы должны быть одинакового размера. При этом подсчете принимайте двухъядерный процессор за два ЦП, а каждый процессор, поддерживающий Hyper-Threading, — за один ЦП. Дополнительные сведения см. в статье Оптимизация производительности базы данных tempdb (https://go.microsoft.com/fwlink/p/?LinkID=148537).

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

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

Использование нескольких файлов данных для баз данных контента

Для достижения наилучшей производительности придерживайтесь следующих рекомендаций.

  • Создавайте файлы только в первичной файловой группе базы данных.

  • Размещайте файлы на нескольких дисках.

  • Число файлов данных не должно превышать количества ЦП. При этом подсчете принимайте двухъядерный процессор за два ЦП, а каждый процессор, поддерживающий Hyper-Threading, — за один ЦП.

  • Создавайте файлы данных одинакового размера.

Важно!

Для резервного копирования и восстановления нескольких файлов данных можно использовать средства резервного копирования и восстановления, встроенные в SharePoint Server 2010, однако если выполнить запись поверх данных в том же месте, эти средства не позволят восстановить группу файлов данных в другом месте. Поэтому при использовании нескольких файлов данных для базы данных контента настоятельно рекомендуется использовать средства резервного копирования и восстановления SQL Server. Дополнительные сведения о резервном копировании и восстановлении SharePoint Server 2010 см. в статье Планирование резервного копирования и восстановления в SharePoint Server 2010.

Дополнительные сведения о создании файловых групп и управлении ними см. в статье Архитектура файлов и файловых групп (https://go.microsoft.com/fwlink/p/?LinkId=117909).

Ограничение баз данных контента в размерах для лучшей управляемости

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

Мы рекомендуем указать 200 ГБ в качестве ограничения на размер баз данных контента, если конкретные сценарии и условия использования не требуют большего размера. Дополнительные сведения см. в разделе Ограничения для баз данных контента статьи Управление мощностью SharePoint Server 2010 Ограничения, связанные с программным обеспечением.

Размер семейства веб-сайтов, если оно не единственное в базе данных, не должен превышать 100 ГБ. Это ограничение позволит использовать средства фрагментарного резервного копирования SharePoint Server 2010 для перемещения семейства веб-сайтов в другую базу данных при необходимости.

Дополнительные сведения о крупномасштабных репозиториях документов см. в разделе "Оценка требований к производительности и объему для крупномасштабных репозиториев документов" статьи Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010).

Упреждающий контроль роста размеров файлов данных и журналов

Ростом размеров файлов данных и журналов рекомендуется управлять в упреждающем режиме с учетом следующих рекомендаций:

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

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

    • Если планируются базы данных контента с превышением рекомендуемого размера (200 ГБ), установите значение авторасширения базы данных не в процентах, а в виде фиксированного числа мегабайтов. Это позволит сократить частоту увеличения размера файла в SQL Server. Увеличение размера файла — блокирующая операция, в ходе которой происходит заполнение нового пространства пустыми страницами.

    • Для базы данных хранилища свойств приложения-службы поиска установите значение параметра авторасширения равным 10%.

    • Если расчетный размер базы данных контента в течение ближайшего года не должен превысить рекомендуемого максимума в 200 ГБ, установите для базы данных максимальный размер, прогнозируемый на этот год (с 20-процентным допуском), используя свойство ALTER DATABASE MAXSIZE. Регулярно пересматривайте это значение, следя за тем, чтобы оно соответствовало прежним темпам роста.

  • Поддерживайте процент доступного пространства по всем дискам на уровне не ниже 25%, чтобы обеспечить возможность роста размеров и работу в условиях пиковых нагрузок. Если возможность роста обеспечивается путем добавления дисков в массив RAID или выделения дополнительного места в хранилище, внимательно следите за размерами дискового пространства, чтобы не допустить нехватки места.

Проверка и мониторинг хранилища и производительности SQL Server

Регулярное тестирование производительности системы и проверка решения резервного копирования имеют важное значение для соблюдения соглашений об уровне обслуживания (SLA). В частности, тестирование подсистемы ввода-вывода компьютера, на котором запущен SQL Server, поможет добиться удовлетворительной производительности всей системы.

Тестирование используемого решения резервного копирования даст гарантии того, что резервное копирование системы будет выполнено за отведенное на техническое обслуживание время. Если при данном решении резервного копирования не удается соблюдать требуемые SLA, рассмотрите возможность перехода на решение добавочного резервного копирования, такого как System Center Data Protection Manager (DPM) 2010.

Важно отслеживать следующие ресурсы сервера под управлением SQL Server: ЦП, память, долю попаданий в кэш и подсистему ввода-вывода. Если какой-либо из этих компонентов демонстрирует признаки замедления или перегрузки, проанализируйте соответствующую стратегию, опираясь на данные о текущей и прогнозируемой рабочей нагрузке. Дополнительные сведения см. в статье, посвященной устранению проблем с производительностью SQL Server 2008 (https://go.microsoft.com/fwlink/p/?LinkID=168448).

В следующем разделе приводится перечень счетчиков производительности, которые рекомендуется использовать для мониторинга производительности баз данных SQL Server, работающих в среде SharePoint Server 2010. Для каждого счетчика указываются примерные значения, свидетельствующие об исправности.

Дополнительные сведения о мониторинге производительности и использовании счетчиков производительности см. в статье Руководство по отслеживанию производительности (https://go.microsoft.com/fwlink/p/?LinkId=189032).

Мониторинг счетчиков SQL Server

Для обеспечения исправности серверов необходимо следить за следующими счетчиками SQL Server.

  • Общая статистика   Этот объект содержит счетчики для мониторинга работы сервера в целом, например число текущих подключений или число пользователей, в течение секунды подключающихся к компьютерам с запущенными экземплярами SQL Server и отключающихся от них. Рекомендуется наблюдать за следующим счетчиком:

    • Соединений пользователей   Этот счетчик показывает число подключений пользователей на компьютере, на котором запущен SQL Server. Если его значение окажется на 500% выше базового, это может привести к снижению производительности.
  • Базы данных   Этот объект содержит счетчики для мониторинга операций массового копирования, пропускной способности средства резервного копирования и восстановления, операций с журналами транзакций. Мониторинг транзакций и журналов транзакций позволит определить, сколько пользовательских операций выполняется в базе данных и насколько заполнен журнал транзакций. Объем пользовательских операций может влиять на производительность базы данных, размер журнала, выполнение блокировки и репликации. Мониторинг операций с журналом на нижнем уровне, дающий оценки активности пользователей и загруженности ресурсов, помогает выявлять узкие места в системе. Рекомендуется наблюдать за следующим счетчиком:

    • Транзакций/с   Этот счетчик показывает количество транзакций для данной базы данных или всего сервера, выполняемых в секунду. Это значение сопоставляется с базовым, что позволяет устранять возникающие неполадки.
  • Блокировки   Этот объект содержит информацию о блокировках SQL Server по отдельным типам ресурсов. Рекомендуется наблюдать за следующими счетчиками:

    • Среднее время ожидания (мс)   Этот счетчик показывает среднее время ожидания по всем запросам блокировки, вызвавшим переход в состояние ожидания.

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

    • Ожиданий блокировок/с   Этот счетчик показывает число запросов блокировки в секунду, которые не были удовлетворены немедленно и были вынуждены ждать освобождения ресурсов.

    • Количество взаимоблокировок/с   Этот счетчик показывает число взаимоблокировок, происходящих в секунду на компьютере, на котором запущен SQL Server. Его значение не должно превышать 0.

  • Кратковременные блокировки   Этот объект содержит счетчики для мониторинга внутренних блокировок ресурсов SQL Server, называемых кратковременными блокировками. Мониторинг таких блокировок, дающий оценки активности пользователей и загруженности ресурсов, помогает выявлять узкие места в системе. Рекомендуется наблюдать за следующими счетчиками:

    • Среднее время ожидания кратковременной блокировки (мс)   Этот счетчик показывает среднее время ожидания блокировки для запросов кратковременных блокировок, которым пришлось ожидать обработки.

    • Ожиданий кратковременных блокировок/с   Этот счетчик показывает число запросов кратковременных блокировок, которые не удалось удовлетворить немедленно.

  • Статистика SQL   Этот объект содержит счетчики для слежения за компиляцией и типом запросов, направляемых в экземпляр SQL Server. Мониторинг числа компиляций и повторных компиляций, а также число пакетов, полученных экземпляром SQL Server, позволяет судить о том, как быстро в SQL Server обрабатываются запросы пользователей и насколько эффективно работает оптимизатор запросов. Рекомендуется наблюдать за следующими счетчиками:

    • Компиляций SQL/с   Этот счетчик показывает, сколько раз в секунду вводится путь к компилируемому коду.

    • Повторных компиляций SQL/сек   Этот счетчик показывает число повторных компиляций инструкции в секунду.

  • Диспетчер буферов   Этот объект содержит счетчики, позволяющие контролировать, как в SQL Server используется память для хранения страниц данных, внутренних структур данных и кэша процедур, и как работает физическая подсистема ввода-вывода при чтении и записи страниц базы данных SQL Server. Рекомендуется наблюдать за следующим счетчиком:

    • Коэффициент попадания в буферный кэш

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

  • Кэш планов   Этот объект содержит счетчики, позволяющие следить за тем, как в SQL Server используется память для хранения таких объектов, как хранимые процедуры, специальные и подготовленные инструкции Transact-SQL и триггеры. Рекомендуется наблюдать за следующим счетчиком:

    • Коэффициент попадания в кэш

    • Этот счетчик показывает отношение числа успешных обращений в кэш к числу операций поиска для планов.

Мониторинг счетчиков физических серверов

Для обеспечения исправности компьютеров, на которых запущен SQL Server, необходимо следить за следующими счетчиками.

  • Процессор: % загруженности процессора: _Total   Этот счетчик показывает, какой процент времени процессор выполняет процессы приложений или операционной системы, отличные от Idle. На компьютере, на котором запущен SQL Server, это значение должно оставаться в диапазоне от 50% до 75%. В случае постоянной перегрузки необходимо выяснить, вызвано ли это каким-либо аномальным процессом, или же серверу требуются дополнительные ЦП.

  • Система: длина очереди процессора   Этот счетчик показывает число потоков в очереди процессора. Необходимо следить за тем, чтобы оно не более чем вдвое превышало число ЦП.

  • Память: доступно МБ   Этот счетчик показывает размер физической памяти в мегабайтах, доступной для процессов, выполняемых на компьютере. Необходимо следить за тем, чтобы он составлял не менее 20% от общего объема доступной физической оперативной памяти.

  • Память: обмен страниц/сек   Этот счетчик показывает скорость считывания страниц с диска или записи на диск в случае страничных прерываний. Необходимо следить, чтобы значение счетчика не превышало 100.

Дополнительные сведения и описание способов устранения неполадок памяти см. в статье, посвященной мониторингу использования памяти в SQL Server 2005 (https://go.microsoft.com/fwlink/p/?LinkID=105585).

Мониторинг счетчиков дисков

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

  • Физический диск: % активности диска: диск данных   Этот счетчик показывает, какую часть истекшего времени выбранный диск обслуживал запросы на чтение и запись; это основной индикатор занятости диска. Если значение счетчика Физический диск: % активности диска слишком высоко (более 90%), проверьте счетчик Физический диск: текущая длина очереди диска, чтобы узнать, сколько системных запросов ожидает доступа к диску. Число ожидающих запросов ввода-вывода должно не более чем в 1,5–2 раза превышать число шпинделей физического диска.

  • Логический диск: обращений к диску/сек   Этот счетчик показывает скорость выполнения операций чтения и записи на диске. Используйте его для мониторинга тенденций роста размеров данных и составления соответствующих прогнозов.

  • Логический диск: скорость чтения с диска (байт/сек) и Логический диск: скорость записи на диск (байт/сек)   Эти счетчики показывают скорость передачи данных с диска или на диск в ходе операций чтения или записи.

  • Логический диск: средний размер одного чтения с диска (байт)   Этот счетчик показывает среднее число байтов, передаваемых с диска в ходе операций чтения. Это значение может характеризовать задержку доступа к диску: большие объемы считывания могут слегка увеличивать задержку.

  • Логический диск: средний размер одной записи на диск (байт)   Этот счетчик показывает среднее число байтов, передаваемых на диск в ходе операций записи. Это значение может характеризовать задержку доступа к диску: большие объемы записи могут слегка увеличивать задержку.

  • Логический диск: текущая длина очереди диска   Этот счетчик показывает число невыполненных запросов доступа к диску на момент сбора данных о производительности. Чем меньше значение этого счетчика, тем лучше. Значение, большее 2 для одного диска, может указывать на узкое место в системе и требует тщательного исследования. Таким образом, значение, не превышающее 8, считается приемлемым для логического устройства (LUN), состоящего из 4 дисков. Узкие места могут приводить к скоплению невыполненных запросов, затрагивая не только текущий сервер, с которого производятся обращения к диску, но и увеличивая время ожидания для пользователей. Возможными путями решения этой проблемы являются добавление дисков в массив RAID, замена имеющихся дисков более быстродействующими или перемещение части данных на другие диски.

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

  • Logical Disk: Avg. Disk sec/Read и Logical Disk: Avg. Disk sec/Write. Эти счетчики показывают среднее время выполнения операции чтения с диска или записи на диск (в секундах). Необходимо следить, чтобы эти значения не превышали 85 % от уровня объема диска, иначе время доступа к диску станет расти экспоненциально. Мощность используемого оборудования можно узнать из документации производителя или определить с помощью средства SQLIO для измерения производительности дисковой подсистемы. Дополнительную информацию см. в статье, посвященной средству SQLIO для измерения производительности дисковой подсистемы (https://go.microsoft.com/fwlink/p/?LinkID=105586).

    • Логический диск: среднее время чтения с диска (сек.)   Этот счетчик показывает среднее время выполнения операции чтения с диска (в секундах). В правильно настроенных системах оптимальными являются значения от 1 до 5 мс для журналов (идеальный вариант — 1 мс для массива с кэшем) и от 4 до 20 мс для данных (желательно менее 10 мс). В периоды пиковой нагрузки возможны более высокие задержки, но если они случаются регулярно, необходимо выяснить причины проблемы.

    • Логический диск: среднее время записи на диск (сек.)   Этот счетчик показывает среднее время выполнения операции записи на диск (в секундах). В правильно настроенных системах оптимальными являются значения от 1 до 5 мс для журналов (идеальный вариант — 1 мс для массива с кэшем) и от 4 до 20 мс для данных (желательно менее 10 мс). В периоды пиковой нагрузки возможны более высокие задержки, но если они случаются регулярно, необходимо выяснить причины проблемы.

    При использовании конфигураций RAID со счетчиками **Логический диск: средний размер одного чтения с диска (байт)   ** и Логический диск: средний размер одной записи на диск (байт) скорость ввода-вывода для диска рассчитывается по формулам, приведенным в таблице ниже.

    Уровень RAID Формула

    RAID 0

    Число операций ввода-вывода на диске = (число операций чтения + число операций записи) / число дисков

    RAID 1

    Число операций ввода-вывода на диске = [число операций чтения + (2 × число операций записи)] / 2

    RAID 5

    Число операций ввода-вывода на диске = [число операций чтения + (4 * число операций записи)] / число дисков

    RAID 10

    Число операций ввода-вывода на диске = [число операций чтения + (2 * число операций записи)] / число дисков

    Предположим, например, что в системе RAID 1 с двумя физическими дисками счетчики имеют указанные ниже значения.

    Счетчик Значение

    Среднее время чтения с диска (сек)

    80

    Логический диск: среднее время записи на диск (сек)

    70

    Средняя длина очереди диска

    5

    Число операций ввода-вывода для диска вычисляется следующим образом: (80 + (2 × 70))/2 = 110

    Длина очереди диска равняется: 5/2 = 2,5

    Эти цифры указывают на потенциально узкое место в подсистеме ввода-вывода.

Другие средства мониторинга

Отслеживать задержки доступа к дискам и анализировать тенденции можно также в динамическом представлении управления sys.dm_io_virtual_file_stats в SQL Server 2008. Дополнительные сведения см. в статье sys.dm_io_virtual_file_stats (Transact-SQL) (https://go.microsoft.com/fwlink/p/?LinkID=105587).

See Also

Other Resources

Управление производительностью и емкостью (SharePoint Server 2010)
Управление базами данных (Office SharePoint Server 2010)