РПЗ_Аниканов (954315), страница 7
Текст из файла (страница 7)
5.7. Конфигурирование пользователей для работы в системе
Для этих целей используется программа UserManagerforDomains. Для предоставления права для работы в UserManagerforDomains имеются дополнительные возможности, в частности, кнопка Config. Нажав на нее, увидим следующее окно. Установим параметр AllowLogontoTerminalServer. Кроме того, необходимо дать пользователю право локально регистрироваться на данном сервере (UserManagerforDomains / Policies / UserRights / Logonlocally). Лучше всего создать группу пользователей, дать ей право локальной работы на сервере, а затем включать в эту группу каждого нового пользователя TerminalServer.
Следующий набор параметров - тайм-ауты (их значения задаются в минутах). Параметр Idle определяет время ожидания сервера в случае отсутствия каких-либо действий со стороны пользователя. По истечении этого срока сервер переводит сессию пользователя в состояние disconnected (в этом случае она остается работать на сервере со всеми запущенными приложениями, но клиентская программа на рабочем месте пользователя теряет связь с TerminalServer; если пользователь вновь запустит клиентскую часть, то он возобновит работу своей сессии в прежнем состоянии). Параметр Disconnection определяет, сколько минут сессия может находиться в состоянии disconnected. По истечении этого времени она принудительно закрывается сервером и ее ресурсы освобождаются (открытые пользователем приложения закрываются без сохранения открытых файлов). Параметр Connection определяет, сколько минут сессия пользователя может быть активна (независимо от действий пользователя).
Для этого нужно зададим домашний каталог пользователя нажать кнопку Profile в свойствах пользователя. Самым важным параметром в этой конфигурации является TerminalServerHomeDirectory. Когда пользователь открывает сессию в TerminalServer, значение этого параметра задает значения двух переменных окружения - %HOMEDRIVE% и %HOMEPATH%, а эти переменные, в свою очередь, используются в приложениях, установленных на сервере. Кроме двух данных переменных, значения которых определяются при настройке профиля пользователя, есть еще другие переменные, специфичные для сессии в TerminalServer. Это переменные: %CLIENTNAME% - NetBIOS-имя клиентского компьютера (на котором непосредственно работает пользователь и запускается клиент TerminalServer), %TEMP% и %TMP% - переменные, задающие путь к каталогу, где хранятся временные файлы (у каждого - свой каталог), %USERDOMAIN% - имя домена Windows NT, %USERNAME% - имя пользователя, %USERPROFILE% - путь к его профилю (по умолчанию "C:\WTSRV\PROFILES\<имя пользователя>"), %WINSTATIONNAME% - строка, состоящая из символов <RDP-tcp#> и цифрового идентификатора сессии пользователя. Все эти переменные создаются при открытии сессии пользователя в и после ее завершения прекращают свое существование.
6. Настройка рабочих параметров СУБД.
Microsoft SQL Server имеет мириады конфигурационных опций и параметров настройки для оптимизации производительности базы данных. Многие их этих параметров достаточно сложны и могут влиять друг на друга. Только достаточно квалифицированный администратор БД может управлять всеми этими параметрами для настройки сервера. Это добавляет сложности к управлению сервером, стоимость обучения администратора БД, и предполагает что по мере усложнения используемой базы данных может потребоваться настройка сервера.
Хорошо известны общие положения оптимизации работы СУБД. Производительность сервера измеряется транзакциями в секунду, а клиента – определяется временем отклика. Исходной картиной для настройки является базовая линия (BaseLine).
В Microsoft автоматическую настройку SQL Server 7.0 называют одной из его замечательных положительных черт. И это подтверждает практика. Почти все опции, влияющие на производительность сервера, в документации SQL Server 7.0 отмечены как SC (SelfConfiguring). Это означает, что сервер устанавливает для них оптимальные значения самостоятельно. С другой стороны, если оптимальные значения параметров устанавливаются автоматически и их не рекомендуется изменять, зачем тогда открыт доступ к ним? Зачем разработчики все-таки оставляют администраторам искушение настраивать сервер? Если параметры доступны, очень хочется этим воспользоваться. Некоторые специалисты называют параметры Memory, Locks, Userconnections первыми очевидными претендентами на настройку. Рассматривая возможность конфигурирования сервера, стоит начать с параметров, для изменения которых нет ограничений и запретов.
Из параметров конфигурации SQL Server 7.0 нужно выбрать те, которые связаны с производительностью и не отмечены как настраиваемые автоматически. Среди них существуют еще и такие, которые имеет смысл изменять только в многопроцессорных конфигурациях: affinitymask и lightweightpooling. Сюда же можно отнести параметр priorityboost. В базе знаний MSDN отмечается, что установка значения этого параметра в 1 (что означает изменение приоритета с 7 на 15 в однопроцессорном варианте сервера) не дает положительного эффекта.
Параметры памяти SQL Server 7.0 по умолчанию регулируются автоматически. Maxservermemory и Minservermemory на выделенном сервере настройки не требуют. Ручная настройка параметра Maxservermemory на практике применяется для ограничения объема памяти, которую может использовать SQL Server, и обеспечения гарантии запуска и работы других приложений. А это не связано с оптимизацией СУБД.
В результате отсева остается два параметра: Networkpacketsize и Minmemoryperquery.
6.1. Networkpacketsize (размер сетевого пакета)
Сетевая библиотека SQL Server передает и получает данные из сети фиксированными порциями, размер которых соответствует размеру сетевого пакета (Networkpacketsize). Маленький размер пакета (512 байт) будет эффективен, если определяющим фактором является время реакции сервера. Увеличение размера сетевого пакета СУБД при условии, что сетевые протоколы тоже поддерживают большие пакеты, приведет к увеличению пропускной способности, так как передача больших пакетов обходится дешевле. Это имеет смысл только в том случае, когда работа приложений действительно требует в ответ на один запрос или в рамках одной транзакции пересылать большой объем данных. Настраивать значение параметра networkpacketsize следует только на выделенном под СУБД сервере.
Если в таблицах базы данных имеются поля типа Text и Image, можно записать идентификаторы этих объектов и с помощью SQL ServerProfiler получить трассировку событий Object: Opened и Object:Closed c соответствующей фильтрацией по Object ID. Теперь нужно посмотреть, насколько активно идет работа с полями этих типов. Если выяснилось, что с типами Text и Image постоянно идет интенсивная работа, можно продолжить анализ.
Как определить, что через сеть отправляются и принимаются большие объемы данных? Какой объем считать большим и насколько увеличивать размер пакета? Рассмотрим отдельно отправляемые и получаемые данные. Размер сетевого пакета стоит увеличивать, если средний объем данных, возвращаемых запросами, устойчиво превышает размер сетевого пакета по умолчанию. Определить объем данных, отправляемый сервером в сеть, позволяет административное приложение NetworkMonitor. В этом приложении нужно установить фильтрацию отправляемых сервером пакетов TCP и IP, узнать среднюю скорость передачи за конкретный период времени, а именно параметр BytesPerSecond. Объем принимаемых данных выводится аналогично. Но как по скорости передачи определить средний объем одного запроса? Для этого нужно знать среднее количество запросов в секунду. Такого счетчика в мониторе производительности SQL Server нет. Можно воспользоваться средним значением счетчика BatchRequests/sec объекта SQL Server: SQL Statistics. Он показывает, сколько пакетных запросов на выполнение SQL-операторов, получаемых в секунду. Эта статистика определяется операциями ввода/вывода, количеством пользователей, размером буферного кэша, сложностью запросов и т. д. Высокий показатель счетчика свидетельствует о большой пропускной способности сервера. Если значение параметра BytesPerSecond, полученное в NetworkMonitor, разделить на среднее значение счетчика BatchRequests/sec, определяемое в PerformanceMonitor, то получим очень грубую среднюю оценку количества байтов, соответствующих одному пакетному запросу. Очевидно, что показания в NetworkMonitor и PerformanceMonitor нужно снимать одновременно. Если полученное значение намного превышает размер сетевого пакета, то последний можно увеличить. Максимальный размер сетевого пакета в SQL Server 7.0 + SP2 составляет 64 Кбайт.
Размер сетевого пакета можно устанавливать и на клиенте, причем для клиента будет работать именно его настройка. Серверная настройка дает значение по умолчанию, если на клиенте дополнительно ничего не указано. Если для клиента, получающего небольшие объемы данных, важно время отклика, то для него размер сетевого пакета можно уменьшить.
Рекомендованное в документации увеличение размера сетевого пакета при выполнении команды BulkInsert имеет смысл только в том случае, когда исходные файлы находятся не на сервере. Такие ситуации можно выявить с помощью SQL ServerProfiler, настроив фильтрацию по критерию Text: Include: BulkInsert.
Сегодня основным транспортным протоколом в сетях стал TCP/IP. В SQL Server 7.0 сетевая библиотека TCP/IP устанавливается по умолчанию как одна из основных. Как соотносится параметр Networkpacketsize и параметры протокола TCP/IP? Нужно ли настраивать размер сетевого пакета SQL Server в соответствии с размером TCP-окна?
Размер окна TCP определяет объем информации, который можно передать без подтверждения. В Windows NT максимальный размер окна равен 64 Кбайт, что соответствует максимальному размеру сетевого пакета SQL Server. При установке соединения между хостами размер окна задается равным четырем максимальным размерам TCP-пакета. Для сети Ethernet по умолчанию начальный размер окна равен 16 Кбайт. С помощью NetworkMonitor можно увидеть, что в таком окне как раз помещается четыре сетевых пакета SQL Server. В Windows 2000 предусмотрен автоматический переход к масштабированию размеров окна, если максимальный размер TCP-пакета превышает 64 Кбайт. В предельном случае размер окна может составлять 1 Гбайт. Таким образом, о соотношении размера окна TCP и размера сетевого пакета SQL Server 7.0 позаботились разработчики сервера, и администратору беспокоиться об этом не нужно. Размер сетевого пакета никогда не превысит размера окна. Другие транспортные протоколы и соотношение с ними размеров сетевого пакета мы в этой статье не рассматривать не будем.
6.2. Minmemoryperquery (минимум памяти, гарантированно выделяемый каждому запросу)
Этот параметр определяет минимум памяти, гарантированно выделяемый каждому запросу. Выделяемая память имеет область сортировки. Если запрос не может получить минимум памяти, он ожидает своей очереди в соответствии со значением параметра querywait. Иногда система может позволить запросу задействовать памяти больше, чем указывает параметр minmemoryperquery. Запросы, требующие много памяти, включают сортировку или хеширование (процесс выделения элемента индексного массива непосредственно по информации, которая содержится в массиве). Прежде чем пытаться поднять производительность, увеличивая значение параметра minmemoryperquery, нужно выяснить, есть ли запросы, требующие такого увеличения.
Хеширование используется при реализации операторов Join. Такие запросы можно отфильтровать по критерию Text: Include: Join в SQL ServerProfiler. Запросы с сортировкой фильтруются по критерию Text: Include: Orderby. Просто отфильтровать такие запросы недостаточно. Нужно не учитывать случаи применения специально созданных для ускорения сортировки индексов. Если соответствующие индексы используются, то большой объем памяти для сортировки не нужен. В этом случае запросы с сортировкой выполняются сравнительно быстро.
Значение параметра minmemoryperquery увеличивается для того, чтобы запрос получал сразу много памяти и не обращался за ней дополнительно. Определить общий объем памяти, выделенной под хеширование, сортировку, создание индексов и выполнение bcp, можно с помощью счетчика GrantedWorkspaceMemory объекта SQL Server: MemoryManager в PerformanceMonitor. Его значение увеличивается только тогда, когда для сортировки нет подходящих индексов. По счетчику MaximumWorkspaceMemory определяют, сколько всего имеется памяти для выполнения таких операций, и его показатель, как и всякий общий резерв, должен намного превышать значение GrantedWorkspaceMemory. Счетчик MemoryGrantsPending показывает количество процессов в секунду, ожидающих получения памяти. Если выполняется много параллельных запросов c хешированием и сортировкой, а минимальный размер памяти увеличен, то не все запросы смогут ее получить. В этом случае тестирование после увеличения параметра minmemoryperquery показывает возросшее среднее значение MemoryGrantsPending, следовательно, minmemoryperquery нужно восстановить. Очень важно, чтобы оперативной памяти на компьютере было не меньше 1 Гбайт. В противном случае эффекта ожидать не стоит[6]
Таблица 11. Минимальные и максимальные значение параметров Networkpacketsize и Minmemoryperquery
| Название параметра | Минимальное значение | Максимальное значение | Значение по умолчанию |
| Networkpacketsize (Байт) | 512 | 65 535 | 4096 |
| Min memory per query (Кбайт) | 512 | 2 147 483 647 | 1024 |
affinitymask
Параметр affinitymask(маска "родственности") является битовой переменной, которая указывает, на каких ЦП может выполнять свою работу SQL Server. Значение 0 (принятое по умолчанию) позволяет планировщику MicrosoftWindows NT/2000 определять, на каких ЦП будет работать SQL Server. Поскольку это битовая переменная, то двоичное представление этого значения определяет, какие ЦП будут использоваться. Ниже приводятся пять первых двоичных значений. Например, если вы используете 4-процессорную систему, то можете задать для параметра affinitymask значение 15 (1111), чтобы SQL Server работал на всех ЦП.
costthresholdforparallelism
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
