Оценка требований к производительности и емкости для служб Access в SharePoint Server 2010
Применимо к: SharePoint Server 2010 Enterprise
Последнее изменение раздела: 2016-11-30
В этой статье содержатся сведения о том, как использование Access в Microsoft SharePoint Server 2010 влияет на топологии, в которых применяется Microsoft SharePoint Server 2010.
Содержание:
Характеристики тестовой фермы
Результаты тестирования
Рекомендации
Устранение неполадок
Характеристики тестовой фермы
В этом разделе описывается набор данных, который использовался во время тестирования, рабочие нагрузки на продукт во время сбора данных о производительности, использовавшееся во время тестирования оборудование, а также топология, для которой это оборудование было развернуто.
Набор данных
Емкость и производительность Службы Access в значительной степени зависят от состава приложений, размещаемых в службе. Зачастую наибольшее влияние на емкость и производительность оказывают размер таблиц и сложность запросов. При тестировании используются типичные размеры и уровни сложности, но для каждого приложения и набора данных они различны. Емкость и производительность будут зависеть от используемых приложений, их сложности и размера набора данных.
Чтобы оценить профиль емкости, приложения Службы Access были смоделированы в ферме, выделенной для Службы Access (другие тесты SharePoint в ней не выполнялись). В ферме содержались следующие типичные сайты:
1500 приложений Службы Access с профилем размера "Маленький"; не более 100 элементов в списке.
1500 приложений Службы Access с профилем размера "Средний"; не менее 2000 элементов в списке.
1500 приложений Службы Access с профилем размера "Большой"; не менее 10 000 элементов в списке.
Каждое приложение состоит из нескольких списков, а другие списки подобраны по размеру на основе этого самого большого списка. Службы Access может обрабатывать более 10 000 элементов данных. Это число было выбрано для профиля "Большой", поскольку предполагалось, что приложения большего размера не слишком распространены.
Приложения были равномерно распределены среди следующих приложений:
Контакты Простое приложение для управления контактами, управляемое одним списком.
Проекты Простое приложение для отслеживания задач и проектов, управляемое двумя списками (проекты и задачи, связанные с каждым проектом).
Заказы Простая система ввода заказов, которая аналогична примеру базы данных Northwind Traders в Microsoft Access, но меньшего размера, и включает множество взаимосвязанных списков (заказы, сведения о заказах, счета, сведения о счетах, заказы на покупку, сведения о заказах на покупку и т. д.).
Рабочая нагрузка
Для моделирования работы приложения были созданы рабочие нагрузки для выполнения следующих операций (одной или нескольких):
Открытие форм
Листание страниц форм
Фильтрация и сортировка таблиц данных
Обновление, удаление и вставка записей
Публикация приложения
Визуализация отчетов
В каждую рабочую нагрузку включается "время обдумывания" между действиями пользователя (от 5 до 20 секунд). Это отличается от других документов по планированию емкости SharePoint. Состояние в Службы Access отслеживается; указатели памяти и наборы записей между действиями пользователя сохраняются. Это важно для моделирования полного сеанса пользователя, а не только отдельных запросов. В качестве средней рабочей нагрузки одного пользователя использовалось два запроса в секунду.
В приведенной ниже таблице показаны проценты, определяющие, какое приложение и какого размера следует использовать.
| Маленький | Средний | Большой | |
|---|---|---|---|
Контакты |
16% |
10% |
9% |
Проекты |
18% |
12% |
10% |
Заказы |
11% |
8% |
6% |
Определения зеленой и красной зон
Для каждой конфигурации выполнялись два теста, позволяющие определить "зеленую зону" и "красную зону". Зеленая зона — это рекомендуемая пропускная способность, которую можно поддерживать. Красная зона — это максимальная пропускная способность, которая допустима в течение недолгого времени, но которой следует избегать.
В качестве зеленой зоны была определена точка, в которой выполняющийся тест потреблял не более половины ресурса, представляющего собой узкое место. В данном случае узким местом был % ЦП на каком-либо из трех уровней: интерфейсный веб-сервер, сервер приложений (службы данных Access) или сервер базы данных (SQL Server). Сначала определялось узкое место для конкретной конфигурации. Если узким местом являлся ЦП на уровне служб данных Access, проверялось, потребляет ли тест зеленой зоны 40–50 процентов ЦП на компьютерах служб данных Access.
В качестве красной зоны была выбрана точка, в которой достигалась максимальная пропускная способность. При этом подтверждалось использование ЦП в диапазоне 80–90 процентов. При поиске узкого места обращалось внимание на % ЦП, объем используемой памяти (байты исключительного пользования), длину очереди диска, сетевой ввод-вывод и другие ресурсы, которые могли указывать на узкое место.
Оба теста (зеленой и красной зоны) выполнялись в течение часа при постоянной пользовательской нагрузке.
Ваши результаты могут отличаться
Представленные в этой статье данные по емкости и производительности будут отличаться от показателей в реальной среде. Это моделирование предназначено только для оценки фактических возможностей пользователей. Эти данные можно использовать в качестве отправной точки при проектировании среды с соответствующим масштабированием. После завершения первоначального этапа разработки системы протестируйте созданную конфигурацию, чтобы убедиться, что система будет поддерживать показатели, характерные для данной среды.
Настройки оборудования и топология
Оборудование лаборатории
Для получения детализированных результатов тестирования использовались разные конфигурации фермы. В конфигурациях фермы использовались от одного до четырех интерфейсных веб-серверов, от одного до четырех серверов приложений (при наличии Службы Access или служб данных Access) и один компьютер сервера базы данных, на котором функционирует Microsoft SQL Server 2008. Кроме того, тестирование проводилось с использованием четырех клиентских компьютеров. Все серверные компьютеры были 64-разрядными. Все клиентские компьютеры — 32-разрядными.
В приведенной ниже таблице перечислено оборудование, использовавшееся при тестировании.
| Роль компьютера | ЦП | Память | Сеть | Диск |
|---|---|---|---|---|
Интерфейсный веб-сервер |
2 процессора, 4 ядра 2,33 ГГц |
8 ГБ |
1 ГБ |
2 шпинделя RAID 5 |
Сервер приложений (службы данных Access) |
2 процессора, 4 ядра 2,33 ГГц |
8 ГБ |
1 ГБ |
2 шпинделя RAID 5 |
Сервер базы данных (SQL Server) |
4 процессора, 4 ядра 2,6 ГГц |
32 ГБ |
1 ГБ |
Хранилище DAS RAID 0, подключенное для каждого номера логического устройства (LUN) |
Топология
Как показывает практика, важным ограничивающим фактором для пропускной способности является ЦП на сервере приложений, где выполняются службы данных Access. Мы изменяли топологию, добавляя компьютеры служб данных Access, пока не устранили это узкое место, а затем добавили интерфейсный веб-сервер, чтобы еще увеличить пропускную способность.
1x1: один компьютер с интерфейсным веб-сервером и один компьютер со службами данных Access
1x2: один компьютер с интерфейсным веб-сервером и два компьютера со службами данных Access
1x3: один компьютер с интерфейсным веб-сервером и три компьютера со службами данных Access
1x4: один компьютер с интерфейсным веб-сервером и четыре компьютера со службами данных Access
2x1: два компьютера с интерфейсным веб-сервером и один компьютер со службами данных Access
2x2: два компьютера с интерфейсным веб-сервером и два компьютера со службами данных Access
2x4: два компьютера с интерфейсным веб-сервером и четыре компьютера со службами данных Access
Компьютер, на котором работает SQL Server, является относительно мощным и никогда не становился узким местом (хотя и начал приближаться к предельной нагрузке ЦП при тестировании конфигурации 2x4), поэтому он оставался неизменным во всех топологиях. В зависимости от запросов, являющихся частью реального набора приложений, узким местом может стать сервер базы данных (SQL Server).
Службы отчетов выполнялись в режиме подключения для всех тестов на уровне сервера приложений (службы данных Access.
Результаты тестирования
В приведенных ниже таблицах показаны результаты тестирования Службы Access. Для каждой группы тестов изменялись только отдельные параметры, чтобы продемонстрировать влияние конкретного показателя на производительность фермы.
Все тесты, описанные в этой статье, выполнялись с учетом времени обдумывания или времени ожидания. Это отличается от результатов планирования емкости для других частей SharePoint.
Сведения об узких местах Службы Access см. в разделе, в котором описываются наиболее распространенные узкие места и причины их возникновения (Возможно, на английском языке) далее в этой статье.
Общий масштаб
Ниже приведены таблица и график, в которых резюмируется влияние добавления дополнительных интерфейсных веб-серверов и выделенных компьютеров служб данных Access в ферму. Эти числовые значения пропускной способности относятся только к компьютерам служб данных Access. Они не отражают влияния на всю ферму в целом.
| Топология | Базовый максимум для решения (запросов в секунду) | Базовая рекомендация (запросов в секунду) |
|---|---|---|
1x1 |
25 |
15 |
1x2 |
54 |
29 |
1x3 |
82 |
45 |
1x4 |
88 |
48 |
2x1 |
25 |
15 |
2x2 |
55 |
29 |
2x4 |
116 |
58 |
.gif "Максимальное и рекомендованное значение RPS")
Результаты для рекомендуемой нагрузки
На приведенном ниже графике показаны результаты для рекомендуемой устойчивой пропускной способности.
.gif "Пропускная способность и ADS")
Как сказано ранее в этой статье, при добавлении четвертого компьютера служб данных Access узкое место смещается к интерфейсному веб-серверу, а добавлением второго интерфейсного веб-сервера решается ограничение ресурса на уровне интерфейсного веб-сервера. Этим подразумевается, что конфигурации 1x1, 1x2 и 1x3 являются подходящими. Однако при добавлении четвертого компьютера служб данных Access необходимо также добавить интерфейсный веб-сервер. Поскольку масштабирование происходит линейно (по прямой от 1x1 к 1x4), можно предположить, что добавление седьмого компьютера служб данных Access подразумевало бы добавление третьего интерфейсного сервера и т. д., для удовлетворения нужд фермы.
Следует помнить, что эти результаты получены на основе смоделированной рабочей нагрузки, и необходимо понаблюдать за фактическим развертыванием, чтобы найти точку, в которой требуются дополнительные интерфейсные веб-серверы для поддержки дополнительных компьютеров служб данных Access. К тому же, интерфейсные веб-серверы выделены для Службы Access, а в реальной среде эти серверы, скорее всего, используются совместно с другими рабочими нагрузками SharePoint. Результаты показаны на приведенном ниже графике.
.gif "Время отклика и ADS")
На приведенном ниже графике показано время отклика при данном уровне пропускной способности. Отклик происходит очень быстро, менее чем через ¼ секунды в среднем для запроса.
.gif "% ЦП SQL и ADS")
Эти результаты показывают, что компьютер SQL Server не являлся узким местом, поскольку при добавлении второго интерфейсного веб-сервера решилась проблема с нехваткой ресурса, а загрузка ЦП SQL Server всегда была менее 50 процентов. Однако следует иметь в виду, что экземпляр SQL Server используется совместно с другими службами SharePoint и самим продуктом SharePoint, так что совокупное воздействие может привести загрузку ЦП или длину запроса ввода-вывода к той точке, в которой они становятся узким местом.
Максимум
На приведенном ниже графике показаны результаты, в которых пропускная способность выходит за пределы устойчивых значений.
На этом графике видно, что потребовался второй интерфейсный веб-сервер, чтобы максимально увеличить полезность четвертого компьютера служб данных Access. И опять же, ваши результаты могут отличаться, поскольку зависят от приложений и схем их использования.
.gif "Пропускная способность и ADS")
В этом случае время отклика увеличилось, поскольку вся система оказалась под нагрузкой. Однако эти уровни держатся примерно одну секунду, что приемлемо для большинства пользователей.
Может показаться странным, что при использовании четырех компьютеров служб данных Access время отклика для двух интерфейсных веб-серверов превышает время отклика для одного интерфейсного веб-сервера. Это связано с тем, что при наличии двух интерфейсных веб-серверов увеличивается общая пропускная способность системы.
И снова SQL Server не является здесь ограничивающим фактором, поскольку при добавлении второго интерфейсного веб-сервера мы снова возвращаемся к линейному масштабированию. Однако достигается почти 90 процентов загрузки ЦП на экземпляре SQL Server. Таким образом, остается очень маленький резерв. Если бы нам пришлось добавить пятый компьютер служб данных Access, компьютер SQL Server, скорее всего, стал бы узким местом.
.gif "% ЦП SQL и ADS")
Подробные результаты
В приведенных ниже таблицах показаны подробные результаты для рекомендованных конфигураций.
| Общие | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
Запросов в секунду |
14,96 |
28,76 |
45,22 |
48,01 |
14,85 |
28,77 |
58,02 |
Тестов в секунду |
2,00 |
3,81 |
6,11 |
6,42 |
1,99 |
3,81 |
7,80 |
Средняя задержка |
235,80 |
241,21 |
247,21 |
244,87 |
240,70 |
242,26 |
250,94 |
| Среднее значение на уровне интерфейсного веб-сервера | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% ЦП |
13,82 |
24,40 |
41,02 |
43,62 |
6,31 |
12,48 |
26,18 |
Максимальное число байтов исключительного пользования w3wp |
9,46E+08 |
2,31E+08 |
1,49E+09 |
1,55E+09 |
8,43E+08 |
9,84E+08 |
1,19E+09 |
| Среднее значение на уровне сервера приложений (службы данных Access) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% ЦП |
46,30 |
42,83 |
43,74 |
34,51 |
46,56 |
43,45 |
42,13 |
% ЦП w3wp |
33,61 |
31,15 |
30,71 |
24,29 |
33,48 |
31,64 |
29,72 |
% ЦП RS |
8,62 |
7,94 |
9,17 |
6,84 |
9,03 |
8,02 |
8,71 |
Максимальное общее число байтов исключительного пользования |
4,80E+09 |
4,89E+09 |
4,91E+09 |
4,62E+09 |
5,32E+09 |
4,82E+09 |
5,07E+09 |
Максимальное число байтов исключительного пользования w3wp |
2,10E+09 |
1,97E+09 |
2,04E+09 |
1,86E+09 |
2,00E+09 |
2,00E+09 |
2,07E+09 |
Максимальное число байтов исключительного пользования RS |
1,78E+09 |
2,00E+09 |
1,97E+09 |
1,86E+09 |
2,30E+09 |
1,89E+09 |
2,02E+09 |
| Уровень сервера базы данных (SQL Server) (один компьютер) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% ЦП |
12,07 |
18,64 |
32,53 |
36,05 |
9,89 |
21,42 |
47,46 |
Среднее число байтов исключительного пользования |
2,96E+10 |
3,22E+10 |
3,25E+10 |
3,25E+10 |
2,89E+10 |
3,22E+10 |
3,25E+10 |
Максимальное число байтов исключительного пользования |
3,26E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
Общая средняя длина очереди диска |
0,74 |
1,18 |
1,64 |
1,77 |
0,67 |
1,24 |
2,18 |
В приведенной ниже таблице показаны результаты для максимальных конфигураций.
| Общие | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
Запросов в секунду |
14,96 |
28,76 |
45,22 |
48,01 |
14,85 |
28,77 |
58,02 |
Тестов в секунду |
2,00 |
3,81 |
6,11 |
6,42 |
1,99 |
3,81 |
7,80 |
Средняя задержка |
235,80 |
241,21 |
247,21 |
244,87 |
240,70 |
242,26 |
250,94 |
| Среднее значение на уровне интерфейсного веб-сервера | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% ЦП |
13,82 |
24,40 |
41,02 |
43,62 |
6,31 |
12,48 |
26,18 |
Максимальное число байтов исключительного пользования w3wp |
9,46E+08 |
2,31E+08 |
1,49E+09 |
1,55E+09 |
8,43E+08 |
9,84E+08 |
1,19E+09 |
| Среднее значение на уровне сервера приложений (службы данных Access) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% ЦП |
46,30 |
42,83 |
43,74 |
34,51 |
46,56 |
43,45 |
42,13 |
% ЦП w3wp |
33,61 |
31,15 |
30,71 |
24,29 |
33,48 |
31,64 |
29,72 |
% ЦП RS |
8,62 |
7,94 |
9,17 |
6,84 |
9,03 |
8,02 |
8,71 |
Максимальное общее число байтов исключительного пользования |
4,80E+09 |
4,89E+09 |
4,91E+09 |
4,62E+09 |
5,32E+09 |
4,82E+09 |
5,07E+09 |
Максимальное число байтов исключительного пользования w3wp |
2,10E+09 |
1,97E+09 |
2,04E+09 |
1,86E+09 |
2,00E+09 |
2,00E+09 |
2,07E+09 |
Максимальное число байтов исключительного пользования RS |
1,78E+09 |
2,00E+09 |
1,97E+09 |
1,86E+09 |
2,30E+09 |
1,89E+09 |
2,02E+09 |
| Уровень сервера базы данных (SQL Server) (один компьютер) | 1x1 | 1x2 | 1x3 | 1x4 | 2x1 | 2x2 | 2x4 |
|---|---|---|---|---|---|---|---|
% ЦП |
12,07 |
18,64 |
32,53 |
36,05 |
9,89 |
21,42 |
47,46 |
Среднее число байтов исключительного пользования |
2,96E+10 |
3,22E+10 |
3,25E+10 |
3,25E+10 |
2,89E+10 |
3,22E+10 |
3,25E+10 |
Максимальное число байтов исключительного пользования |
3,26E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
3,25E+10 |
Общая средняя длина очереди диска |
0,74 |
1,18 |
1,64 |
1,77 |
0,67 |
1,24 |
2,18 |
Рекомендации
В этом разделе приведены общие рекомендации по производительности и емкости.
Емкость и производительность Службы Access в значительной степени зависят от состава приложений, размещаемых в службе. Наибольшее влияние обычно оказывают размер таблиц и сложность запросов. При тестировании используются типичные размеры и уровни сложности, но для каждого приложения и набора данных они различны. Поэтому емкость и производительность будут зависеть от используемых приложений, их сложности и размера данных.
Рекомендации к оборудованию
Службы Access использует стандартное оборудование для интерфейсных веб-серверов и для серверов приложений; никакие специальные требования не предъявляются. Для компьютеров уровня сервера приложений (службы данных Access) применимы обычные рекомендации SharePoint Server 2010 по количеству ЦП, скорости и памяти.
Топологии с пропорциональным увеличением и уменьшением масштаба
Чтобы увеличить емкость и производительность одной из первоначальных топологий, можно сделать две вещи. Можно осуществить пропорциональное увеличение масштаба, увеличивая емкость существующих серверов, или пропорциональное уменьшение масштаба, добавляя дополнительные серверы в топологию. В этом разделе описываются общие характеристики производительности нескольких топологий с пропорциональным увеличением и уменьшением масштаба.
В примерах топологий представлены следующие распространенные способы топологии с пропорциональным уменьшением масштаба для сценария Службы Access.
В целях увеличения пользовательской нагрузки проверьте ЦП для имеющихся серверов приложений Службы Access. По возможности добавьте в эти серверы ЦП или ядра, или и те, и другие. Добавьте компьютеры серверов Службы Access при необходимости. Все это можно делать до той точки, в которой интерфейсный веб-сервер становится узким местом, а затем нужно добавить интерфейсные веб-серверы, если необходимо.
В наших тестах память на уровнях интерфейсного веб-сервера и сервера приложений (службы данных Access) не являлась узким местом. В зависимости от размера результирующих наборов память может представлять проблему. Но мы не считаем это типичным случаем. Отслеживайте байты исключительного пользования для процесса w3wp служб данных Access, как описано в этой статье.
В наших тестах SQL Server не являлся узким местом. Но наши тесты выполнялись изолированно от других служб SharePoint Server 2010. Необходимо отслеживать показатели ЦП и дискового ввода-вывода SQL Server и добавлять дополнительные серверы или шпиндели по мере необходимости.
Параметры служб Access, связанные с производительностью
Одним из способов регулирования характеристик производительности Службы Access является ограничение размера и сложности выполняемых запросов. В Службы Access предоставляется набор настраиваемых средств регулирования для управления запросами. Каждый из последующих запросов можно задать через центр администрирования SharePoint . (В разделе Управление приложениями щелкните Управление приложениями-службами, затем выберите Службы Access.)
В большинстве случаев производительность в значительной степени зависит от количества данных, которые необходимо извлечь из SharePoint для выполнения запроса. Этот показатель можно регулировать несколькими способами. Во-первых, можно ограничить входные данные запроса:
Максимальное число источников в запросе
Максимальное число записей в таблице
Во-вторых, можно ограничить результирующий размер запроса:
Максимальное число столбцов в запросе
Максимальное число строк в запросе
Разрешение внешних соединений
Помимо размера запроса (размера данных на входе и выходе) можно регулировать сложность обработки данных, чтобы снизить нагрузку ЦП на уровне сервера приложений (службы данных Access):
Максимальное число вычисляемых столбцов в запросе
Максимальное число предложений Order By в запросе
Понятно, что предшествующие параметры будут влиять на приложения, выполняющиеся на сервере. Например, если при создании приложения в нем представлено 40 столбцов выходных данных запроса, а параметры настроены ниже этого уровня, в приложении будет возникать ошибка выполнения. Необходимо найти баланс между нуждами пользователей и приемлемой производительностью, в значительной степени зависящий от типа приложений Access, которые предполагается использовать в ферме.
Можно применить одну дополнительную более ограничительную меру. SharePoint Server 2010 поддерживает изначально набор операций запросов, который Службы Access увеличивает для соответствия более широкому набору сценариев приложений. При увеличении Службы Access запросов из SharePoint существует вероятность, что потребуется извлекать большие объемы данных из базы данных контента SharePoint. Вместо этого можно настроить Службы Access на работу только с теми операциями запросов, которые изначально поддерживаются SharePoint. Тем самым можно избежать получения данных, требуемых для более сложных операций:
- Разрешить запросы, которые нельзя обрабатывать удаленно
Оптимизация
Распространенные узкие места и причины их возникновения
В ходе тестирования производительности было обнаружено несколько узких мест. Узкое место — это состояние, при котором достигается предельная емкость отдельного компонента фермы. Узкие места снижают пропускную способность фермы.
В таблице раздела Устранение неполадок далее в этой статье перечисляются некоторые распространенные узкие места и описываются причины их возникновения и возможные решения.
Мониторинг производительности
Счетчики производительности позволяют отслеживать состояние системы и определять, требуется ли применять к системе горизонтальное или вертикальное масштабирование. В приведенных ниже таблицах содержатся сведения о счетчиках производительности, которые необходимо отслеживать, и процессах, к которым необходимо применять счетчики производительности.
Интерфейсные веб-серверы
В следующей таблице перечислены счетчики производительности и процессы, используемые для наблюдения за веб-серверами в ферме.
| Счетчик производительности | Применяется к объекту | Примечания |
|---|---|---|
% загруженности процессора |
Процессор (_Total) |
Показывает время в процентах, в течение которого данный поток использовал процессор для выполнения инструкций. |
Байты исключительного пользования |
Процесс (w3wp) |
Это значение не должно совпадать с максимальным числом байтов исключительного пользования, заданным для процессов w3wp. Если эти значения близки, необходимо дополнительно выяснить, какой компонент использует память. |
Службы данных Access
В следующей таблице перечислены счетчики производительности и процессы, используемые для наблюдения за серверами приложений, в данном случае службами данных Access (службы данных Access), в составе фермы.
| Счетчик производительности | Применяется к объекту | Примечания |
|---|---|---|
% загруженности процессора |
Процессор (_Total) |
Показывает время в процентах, в течение которого данный поток использовал процессор для выполнения инструкций. |
% загруженности процессора |
Процесс (w3wp) |
Службы данных Access выполняются в рамках собственного процесса w2wp, и будет несложно определить соответствующий процесс w2wp, поскольку он займет большую часть времени ЦП. |
Средняя длина очереди диска |
Физический диск (_Total) |
Отслеживает слишком большое количество операций записи на диск в связи с ведением журнала. |
% загруженности процессора |
Процесс (ReportingServicesService) |
Отчеты обрабатываются Службы SQL Server Reporting Services. Если выполняется слишком много отчетов или если отчеты очень сложные, значения ЦП и байтов исключительного пользования для этого процесса будут высокими. |
Байт исключительного пользования |
Процесс (w3wp) |
Службы Access кэширует результаты запросов в памяти до тех пор, пока не завершится сеанс пользователя (время ожидания для которого можно настроить). Если через службы данных Access идет обработка большого количества данных, потребление памяти для процесса w3wp служб данных Access увеличится. |
Байт исключительного пользования |
Процесс (ReportingSrevicesService) |
Отчеты обрабатываются Службы SQL Server Reporting Services. Если выполняется слишком много отчетов или если отчеты очень сложные, значения ЦП и байтов исключительно пользования для этого процессы будут высокими. |
Серверы баз данных
В следующей таблице перечислены счетчики производительности и процессы, используемые для наблюдения за серверами баз данных в ферме.
| Счетчик производительности | Применяется к объекту | Примечания |
|---|---|---|
% загруженности процессора |
Процессор (_Total) |
Показывает время в процентах, в течение которого данный поток использовал процессор для выполнения инструкций. |
% загруженности процессора |
Процесс (sqlservr) |
Средние значения, превышающие 80%, указывают на недостаточную вычислительную мощность процесса на сервере базы данных. |
Байт исключительного пользования |
Процесс (sqlservr) |
Показывает среднее количество памяти, потребляемой SQL Server. |
Средняя длина очереди диска |
Физический диск (_Total) |
Показывает среднюю длину очереди диска; запросы базы данных ожидают записи на диск. Зачастую это наглядный показатель того, что экземпляр SQL Server находится на грани перегрузки, и дополнительные шпиндели дисков могут помочь в распределении нагрузки. |
Устранение неполадок
В следующей таблице перечислены распространенные узкие места, а также приведены возможные причины и решения.
| Узкое место | Причина | Решение |
|---|---|---|
ЦП служб данных Access |
Службы Access зависит от количества обрабатываемых данных на уровне сервера приложений. Если используется конфигурация 1x1, 1x2 или 1x3, первым обнаруженным узким местом будет, скорее всего, ЦП на серверах служб данных Access. |
Увеличьте количество ЦП или ядер, или и тех, и других в имеющихся компьютерах служб данных Access. Добавьте дополнительные компьютеры служб данных Access, если это возможно. |
Загрузка ЦП веб-сервера |
Если веб-сервер перегружен пользовательскими запросами, загрузка ЦП на нем приближается к 100 процентам. Это не позволяет веб-серверу быстро реагировать на запросы и может привести к задержкам и появлению на клиентских компьютерах сообщений об ошибках. |
Эту проблему можно устранить двумя способами. Можно добавить еще веб-серверы в ферму для распределения пользовательской нагрузки, а можно масштабировать один или несколько веб-серверов, установив на них более быстрые процессоры. |
Операции ввода-вывода для диска на сервере базы данных |
Если количество запросов ввода-вывода к жесткому диску превышает его пропускную способность, запросы помещаются в очередь. В результате время, затрачиваемое на выполнение каждого запроса, увеличивается. |
Распределение файлов данных между несколькими физическими дисками позволяет обеспечить параллельный ввод-вывод. Полезные сведения об устранении проблем с дисковым вводом-выводом можно найти в блоге, посвященном выделению дисков для SharePoint и операции дискового ввода-вывода (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=129557&clcid=0x419) (Возможно, на английском языке). |
Использование ЦП Службы Reporting Services |
Процесс Службы Reporting Services использует основную часть ресурсов ЦП. |
Выделите компьютер для процесса Службы Reporting Services, что позволит уменьшить нагрузку на уровне сервера приложений (службы данных Access) (режим подключения) или на уровне интерфейсного веб-сервера (локальный режим). |