SQL настройка

Использование 1С Предприятие в клиент-серверном режиме дает очень много плюсов, к примеру, скорость и надежность работы. Но так же не надо забывать, что СУБД — это отдельная информационная система, которая требует определенного внимания и обслуживания. Мы подготовили основные рекомендации по созданию плана обслуживания баз данных Microsoft SQL Server в которых хранятся информационные базы 1С.

Рекомендуемые регламентные операции СУБД для работы «1С: Предприятие 8» клиент-серверного варианта при использовании СУБД MS SQL Server:

  • Регулярное резервное копирование баз данных
  • Обновление статистики
  • Очистка процедурного КЭШа
  • Реорганизация индекса
  • Перестроение индекса

Создание плана обслуживания

Все перечисленные выше операции возможно автоматизировать при использовании Плана обслуживания в Microsoft SQL Server.

Для начала необходимо подключиться к серверу используя (устанавливается отдельно от MS SQL Server); перейти во вкладку «Управление» — «Планы обслуживания» — ПКМ – «Создать план обслуживания…» и задать имя плана.

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

Теперь в наш план необходимо добавить непосредственно сами задачи по обслуживанию. Для этого используем «Панель элементов» (слева от Обозревателя объектов) и добавляем нашу первую задачу «Проверка целостности базы данных».

В задаче «Проверка целостности базы данных» выберем необходимые для обслуживания базы: ПКМ по объекту данной задачи – «Изменить», в открывшемся окне из списка «Базы данных» выбираем необходимые нам базы (все кроме системных или конкретные)

Последующие задание необходимо выбирать исходя из нагрузки и времени выполнения регламентного задания: «Перестроение индекса» или «Реорганизация индекса».

«Перестроение индекса» — включает полное перестроение индексов таблиц базы данных, однако в версии MS SQL Server Standard происходит отключение всех клиентов от базы на время выполнения операции.

«Реорганизация индекса» — исправление уже имеющихся индексов, не требует отключение клиентов от базы

«Реорганизацию индекса» имеет делать смысл каждый день. В то время как полное «Перестроение индекса» лишь раз в неделю.

Добавляем необходимую нам задачу через «Панель элементов» и выбираем необходимые для этой задачи базы.

Далее нам необходимо установить между ними связь: выбираем нашу первую задачу «Проверка целостности базы данных» и кликнув (ЛКМ) на зеленую стрелку вниз (под объектом) протянем её до объекта нашей следующей задачи.

Открыв «Редактор управления очередностью» (2х ЛКМ по появившейся линии связи) мы можем задавать значение выполнения:

Успешное выполнение (зеленая линия) – последующие задание будет выполняться только в случае успешного выполнения предыдущего.

Ошибка (красная линия) – последующие задание будет выполняться только в случае ошибки выполнения предыдущего задания.

Завершение (темно-синяя линия) – последующие задание будет выполняться после предыдущего независимо от результатов выполнения предыдущего.

В данном случае, после успешного выполнения задачи «Проверка целостности базы данных» начнётся выполнение задачи «Реорганизация индекса», если проверка выявила повреждение базы данных, то последующие задачи обслуживания выполнятся не будут.

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

Далее добавим задачу по «Очистке процедурного КЭШа», однако такая задача отсутствует в «Панели элементов», поэтому мы добавляем задачу «Выполнение инструкции T-SQL».

Изменим объект «Выполнение инструкции T-SQL» (2х ЛКМ) и в появившемся окне в поле «Инструкция T-SQL» пропишем:

dbcc freeproccache

После чего не забываем создать связь для вновь добавленной задачи.

Теперь перейдём непосредственно к созданию резервной копии базы, добавляем соответствующий элемент на «Панели элементов». Открываем параметры задачи (2х ЛКМ по объекту).

На вкладке «Общее» мы можем выбирать необходимый нам тип резервной копии (Полное, Разностное, Журнал транзакций), базы и компонент резервного копирования (базу данных целиком или отдельные её компоненты).

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

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

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

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

Помимо самих бэкапов баз, место на жестком диске могут занимать журналы регламентных заданий MS SQL Server, их мы тоже будем периодически очищать, добавив задачу «Очистка журнала».

В итоге наш «План обслуживания» будет выглядеть следующим образом:

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

Просмотреть журнал выполнения «Плана обслуживания» на наличие ошибок возможно через «Просмотр журнала»: «Обозреватель объектов» — «Управление» — «Планы обслуживания» — ПКМ (по плану обслуживания) – «Просмотр журнала».

Отдельно стоит обратить внимание на запуск в системе службы «Агент SQL Server». Данная служба отвечает за выполнение «Планов обслуживания», соответственно, в свойствах службы необходимо проверить чтобы стоял «Тип запуска: Автоматический».

График обслуживания

Периодичность выполнения регламентных операций, рекомендуемая разработчиками «1С: Предприятие 8».

Периодичность Операция Описание задачи
Перед каждым выполнением плана обслуживания Проверка целостности базы Перед выполнением любых задач по обслуживанию баз рекомендуется проверить их целостность во избежание дальнейших и необратимых повреждений базы
Не реже 1 раза в неделю Реорганизация индекса Дефрагментация индексов повышает эффективность работы запросов
Не реже 1 раза в неделю Перестроение индекса Полное перестроение индексов таблиц базы данных, существенно оптимизирует работу базы (требует отключение клиентов в редакции MS SQL Server Standard)
Не реже 1 раза в день Обновление статистики Помогает SQL серверу выстраивать оптимальный план выполнения запросов
После выполнения операции «Обновление статистики» Очистка процедурного КЭШа Очистка КЭШа запросов для исключения выполнения сервером устаревших планов запросов
Не реже 1 раза в день Резервное копировании данных Выполнение полного резервного копирования базы данных для возможности восстановление в случае повреждения
Исходя из потребностей и свободного места в файловой системе Очистка после обслуживания Удаляет устаревшие архивы базы данных
Исходя из потребностей и свободного места в файловой системе Очистка журнала Удаляет данные журнала связанные с процессами выполнения плана обслуживания

В данной публикации речь пойдёт о настройке важных параметров пула ASP.NET-приложений при вызове удалённых веб-сервисов и активной работе с сетью на стороне сервера через стандартные классы .NET.

Введение

Приходилось ли вам когда-нибудь самим настраивать производственные веб-сервера (production servers) под управлением ОС Windows Server 2008 R2/IIS 7.5 и выше? Для системных администраторов, имеющих большой опыт работы с IIS, скорее всего, это тривиальная задача, но вот для веб-разработчиков, которым по различным причинам порой приходится самим участвовать в настройке «боевых» серверов, данная информация может оказаться весьма полезной.
Итак, приступаем. Ускоряем сайт на ASP.NET — экономим деньги предприятия и нервы администратора.
Предыстория
1. Параметры конфигурации IIS
2. Настройка ASP.NET
3. Рекомендации по оптимизации базовой конфигурации
Дополнительно
Заключение

Предыстория

В конце прошлого года в одной крупной организации мы столкнулись с проблемами производительности веб-серверов при резко увеличившейся пользовательской нагрузке. В веб-приложении на тот момент было зарегистрировано более 200 000 клиентов. В обычном режиме одновременно работает около 1000 пользователей, за день примерно 10-15% уникальных посетителей от общего числа зарегистрированных, поэтому нагрузка относительно невысокая. Однако существуют пиковые нагрузки, при которых система оказывается практически неработоспособной.
Веб-администаторы проверили всё, что можно, и никак не могли понять, в чём дело. Ведь несмотря на то, что по всем основным параметрам системы на физическом уровне с производительностью было всё хорошо, возникали сбои с доступностью сервисов, а в пуле собиралась огромная очередь запросов. В организации используется NLB-кластер на 4 узла (Windows Server 2008 R2 + IIS 7.5 + .NET 4.5), есть запас по загрузке ЦП и памяти, сетевые каналы большие, количество используемых портов достаточное. Все проверки указывали на то, что проблемы кроются в недрах IIS и настройке пула ASP.NET. Живой пример, когда администраторам не помешала бы помощь опытных веб-разработчиков…

Параметры конфигурации IIS

Общее описание конфигурации .NETНачиная с IIS 7, все настройки конфигурации ASP.NET хранятся в XML-файлах (*.config). Они заменили метабазу, которая использовалась в IIS 6.0 и более ранних версиях.
Схема конфигурационных файлов для IIS 7.x и выше выглядит так:

Рис. 1. Схема конфигурационных файлов
На вершине иерархической конфигурации .NET находится файл machine.config. Он определяет глобальные параметры для конкретной машины. В этом файле определяются поддерживаемые разделы конфигурационных файлов, настраивается рабочий процесс ASP.NET и регистрируются поставщики различных модулей. Для оптимизации процесса инициализации файл machine.config был значительно упрощен, и он располагается в каталоге:
%systemroot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\
Здесь же находится файл machine.config.comments, который позволяет узнать, какие параметры используются по умолчанию. С помощью этих данных в machine.config можно добавить параметры с переопределенными значениями.
Корнем иерархии конфигурации ASP.NET является файл web.config, расположенный в том же каталоге, что и machine.config. Этот файл включает в себя параметры, которые используются для всех приложений ASP.NET.
ApplicationHost.config — корневой файл конфигурации IIS, включает в себя описание всех сайтов, приложений, виртуальных каталогов и пулов приложений, а также глобальные установки по умолчанию для параметров веб-сервера. Он находится в следующих папках в зависимости от версии ОС:

  • для 32-битной — %WINDIR%\System32\inetsrv\config\
  • для 64-битной — %WINDIR%\SysWOW64\inetsrv\config\

Каждый локальный файл web.config применяет параметры конфигурации для каталога, в котором он расположен, а также для всех дочерних каталогов. Настройки вложенных каталогов могут быть переопределены собственными «конфигами”.
Прежде чем начинать настройку конфигурации IIS, обратите внимание на счетчики производительности ASP.NET, оцените текущую и пиковую загрузки системы, зафиксируйте имеющиеся показатели. Проверьте логи на наличие ошибки «HTTP Error 503.2 — Service Unavailable”. Постарайтесь определить, не блокируется ли часть запросов в очереди.
Если производительность системы удовлетворяет потребностям заказчика, то лучше оставить параметры по умолчанию, ведь они рассчитаны для большинства ASP.NET приложений.
При конфигурации IIS можно выделить два основных параметра, влияющих на доступность приложения и его производительность.
1. Параметр appConcurrentRequestLimit — максимальное количество одновременных запросов в приложении. Увеличение числа одновременных запросов IIS расширит доступные ресурсы веб-сервера для обслуживания запросов. Значение по умолчанию — 5000.
Наиболее быстро изменить параметр appConcurrentRequestLimit можно утилитой appcmd.exe через командную строку. Сделать это можно как глобально для всех сайтов IIS через файл ApplicationHost.config, так и для отдельного сайта (приложения).
cd %windir%\system32\inetsrv appcmd.exe set config /section:system.webserver/serverRuntime /appConcurrentRequestLimit:20000
Выполняем команду, затем открываем в IIS раздел «Configuration Editor» для корневого каталога и проверяем новое значение установленного параметра appConcurrentRequestLimit. Причём здесь же можно вручную изменить это значение.

Рис. 2. Установка параметра appConcurrentRequestLimit
Для установки данного параметра наиболее часто используется формула:
<usersCount * 1.5>, где usersCount — количество одновременно работающих пользователей.
2. Параметр QueueLength — максимальное количество запросов, которые драйвер Http.sys размещает в очереди пула приложений. Когда очередь заполнена, новые запросы получают ошибку «503.2 — Service Unavailable». Значение по умолчанию — 5000.
Данный параметр можно настроить несколькими способами:

  • глобально для .NET на уровне сервера через machine.config, секция processModel/requestQueueLimit;
  • на уровне IIS через ApplicationHost.config: system.web/httpRuntime -> appRequestQueueLimit;
  • задать значение параметра queueLength для конкретного пула.

В качестве примера изменим данный параметр для пула «DefaultAppPool» через командную строку:
appcmd.exe set apppool «DefaultAppPool» /queueLength:20000
Выполняем команду, затем открываем в IIS раздел «Application Pools», выбираем в списке пул «DefaultAppPool «, заходим в меню «Advanced Settings» и проверяем.

Рис. 3. Установка параметра queueLength
На заметку: Просмотр текущих запросов в работающем пуле через «IIS ->Worker Processes”В диспетчере IIS выберите узел сервера в дереве, затем нажмите на иконку «Worker Processes»:

Рис. 4. Меню Worker Processes в диспетчере IIS
В появившемся списке вы можете видеть загрузку всех запущенных в текущий момент пулов.

Рис. 5. Просмотр работающих пулов через Worker Processes
При нажатии «View Current Request” появляется таблица со списком адресов обрабатываемых страниц и другими полезными параметрами. Для обновления списка можно нажимать F5 на экране. Таким образом, вы сможете найти «подвисшие» запросы:

Рис. 6. Список текущих запросов в пуле
Для просмотра показателей производительности, конечно, лучше использовать счётчики Performance Monitor, но они не покажут вам, как Requests Monitor, URL-адреса текущих запросов.

Настройка ASP.NET

ASP.NET ограничивает число рабочих потоков и потоков портов завершения вызова, используемых для выполнения запросов. Если веб-приложение на стороне сервера активно использует вызовы внешних веб-сервисов, стандартные классы из пространства имён System.NET для организации запросов по сети, то могут возникнуть конфликты низкой производительности и взаимоблокировок. Вначале часть запросов может просто «подвисать”, время выполнения будет значительно возрастать. В худшем случае, если используется классический режим настройки пула (classic pipeline), это вообще может привести к перезагрузке пула (recycle). Обнаружение взаимоблокировки ASP.NET не выполняется для пула, запущенного в integrated mode (по умолчанию в IIS 7 и выше).
Работа пулов приложений в интегрированном режиме имеет несколько преимуществ по сравнению с работой в классическом режиме. Рекомедуется запускать пулы приложений в integrated mode.
На рисунке ниже наглядно видно, как происходит обработка запросов в ASP.NET и какие параметры имеют наиболее важное значение:

Рис. 7. Процесс обработки запросов в ASP.NET
Для оптимальной работы веб-приложений по умолчанию включен режим автоконфигурации настроек пула. В этом случае, cвойство autoConfig равно «true» для секции <processModel> в файле machine.config, а другие ключевые параметры не заданы вообще.
Хорошенько «покопавшись” в MSDN и файле machine.config.comments, я нашёл описание базовой конфигурации пула. Есть 7 основных параметров, влиящих на работу ASP.NET с сервисами и сетью:
Параметр maxconnection определяет максимальное количество одновременных запросов с одного IP-адреса. При включенной по умолчанию автоконфигурации пула этот параметр определяется по формуле:
maxConnection = 12 * cpuNum, где cpuNum — это количество ядер процессора
Таким образом, на сервере с 4-х ядерным процессором максимальное кол-во одновременных подключений к конечному IP-адресу равно 48=12*4 (по умолчанию).
Самый простой способ обойти данное ограничение — это прямо в коде своего ASP.NET приложения в методе Application_Start в файле global.asax указать следующее:
// maximum number of concurrent connections allowed by a ServicePoint object System.Net.ServicePointManager.DefaultConnectionLimit = Int16.MaxValue;
Более гибко настраивать maxconnection лучше через конфигурационные файлы на уровне домена приложения (web.config) или веб-сервера (applicationHost.config). Секция <system.net> содержит параметры, которые определяют, как .NET Framework подключается к сети.
<system.net> <connectionManagement> <add address=»*» maxconnection=»5000″ /> <add address = «http://www.habrahabr.ru» maxconnection = «9999» /> <add address = «http://65.53.32.230:88» maxconnection = «240» /> </connectionManagement> </system.net>
Важно: Схема для адреса параметра maxconnection должна быть такой:
http(s)://<IP-адрес или Имя сервера>:<Порт>
Увеличение maxconnection позволяет делать больше одновременных вызовов к удаленным сервисам. Этот атрибут не влияет на локальные вызовы веб-служб! Необходимо понимать, что недостаточно только обойти ограничение на количество одновременных подключений к сервису. Так как увеличение числа одновременных вызовов приводит к увеличению использования потоков CLR, которые используются для создания удаленных и обработки обратных вызовов.
ASP.NET через параметр maxWorkerThreads устанавливает ограничения потоков на рабочем процессе w3wp.exe (начиная с IIS 7). В связи с тем, что ASP.NET встроена в IIS, процессы ASP.NET формируют запросы на рабочих потоках. Из-за недостаточного количества потоков в CLR ThreadPool запросы будут становиться в очередь и «подвисать”.
Аттрибуты, заданные в секции <processModel>:
1. Параметр maxWorkerThreads — указывает максимальное количество рабочих потоков для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.
2. Параметр maxIoThreads — указывает максимальное количество потоков ввода/вывода для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.
3. Параметр minWorkerThreads — указывает минимальное количество рабочих потоков для каждого процессора, которые могут быть предоставлены немедленно для обслуживания удаленного запроса. Значение по умолчанию — 1.
4. Параметр minIoThreads — указывает минимальное количество потоков ввода/вывода для каждого процессора, которые могут быть предоставлены немедленно для обработки обратного вызова. Значение по умолчанию — 1.
Параметры minWorkerThreads/minIoThreads позволяют оперативно справиться с внезапно возросшим количеством одновременных подключений, когда в случае бездействия пул потоков может не иметь достаточно времени, чтобы достичь оптимального уровня потоков.
Аттрибуты, заданные в секции <httpRuntime>:
1. Параметр minFreeThreads — определяет количество потоков, которые могут быть использованы для работы, кроме обработки входящих запросов к рабочему процессу. Этот параметр не дает процессу ASP.NET использовать потоки из пула для обработки нового HTTP-запроса, если общее число потоков в пуле опустится ниже этого предела. Значение по умолчанию — 8.
2. Параметр minLocalRequestFreeThreads — определяет минимальное количество свободных потоков, которые ASP.NET держит доступными для выполнения новых локальных запросов. Значение по умолчанию — 4.
Обратите внимание, параметры maxWorkerThreads, minWorkerThreads, maxIoThreads, minIoThreads неявно умножаются на число процессоров, а параметры minFreeThreads и minLocalRequestFreeThreads — нет.
ASP.NET не будет выполнять более, чем следующее количество одновременных запросов:
(maxWorkerThreads * число ЦП) — minFreeThreads
Обратите внимание: на весь пул приложения, то есть на каждый рабочий процесс w3wp.exe, обслуживающий пул, имеется один пул потоков CLR ThreadPool. Для всех доменов приложений (сайтов), настроенных на один пул, используется общий набор потоков. Следовательно, для требовательных к ресурсам приложений лучше использовать отдельные пулы.

Рекомендации по оптимизации базовой конфигурации

Прежде всего, необходимо точно определить количество процессоров на веб-сервере. Как вариант, можно посмотреть TaskManager -> вкладка «Performance». Если процессор поддерживает режим HyperThreadingTechnology (HTT), значит половина ядер логические (Logical processors), а не физические (Cores). Например, при включенном режиме HTT процессор с 4-мя физическими ядрами будет работать как 8 логических ядер:
Рис. 8. Окно загрузки процессоров в TaskManager
Также можно попробовать воспользоваться следующими командами в командной строке:
WMIC CPU Get DeviceID,NumberOfCores,NumberOfLogicalProcessors илиecho %NUMBER_OF_PROCESSORS%
Например, на сервере с 4-мя процессорами и свойством autoConfig=»true» ASP.NET будет иметь следующие параметры по умолчанию:
maxConnection – 48; maxWorkerThreads – 80; maxIoThreads – 80, minFreeThreads – 8, minLocalRequestFreeThreads – 4.
Если веб-страница на backend-части делает несколько сетевых вызовов для каждого запроса, то MSDN рекомендует использовать следующие настройки конфигурации:
В этом разделе приведены только рекомендации, а не правила. Причём дата публикации этих данных довольно давняя. Для нашей «боевой” системы мы используем немного другие параметры конфигурации. Данные формулы — хорошая отправная точка для старта оптимизации, они хорошо показывают зависимость параметров друг от друга. Например, увеличив значение параметра maxConnection в несколько раз, вы легко можете «прикинуть” базовые значения для остальных параметров.
Изменения в секцию <processModel> разрешено вносить только в файле machine.config из-за установленного там же атрибута allowDefinition=»MachineOnly» при добавлении секции processModel.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Machine.config:
<section name=»processModel» type=»System.Web.Configuration.ProcessModelSection, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a» allowDefinition=»MachineOnly» allowLocation=»false» />

Чтобы иметь возможность устанавливать значения секции processModel для каждого приложения в отдельности через web.config, необходимо установить свойство allowDefinition=»Everywhere».
Приведу настройки конфигурации с нашего веб-сервера<system.web> <processModel autoConfig=»False» maxWorkerThreads=»100″ maxIoThreads=»100″ minWorkerThreads=»50″ minIoThreads=»8″ /> <httpRuntime minFreeThreads=»640″ minLocalRequestFreeThreads=»96″> </system.web> <system.net> <connectionManagement> <add address = «http://Адрес_сервера_1» maxconnection = «5000» /> <add address = «http://Адрес_сервера_2» maxconnection = «5000» /> </connectionManagement> </system.net>
Важно: после внесения изменений требуется обновить Application pools.
Помните, что увеличивать данные параметры нужно только в случае необходимости при наличии достаточного количества ресурсов ЦП.
Для анализа производительности веб-серверов рекомендую настроить счётчики ASP.NET через Performance Monitor:
Для более глубокого анализа процесса w3wp.exe, обслуживающего пул приложений IIS, можно попробовать отладчик WinDbg из Windows Software Development Kit.
Возможно, что после проверки счётчиков вам придётся внести корректировки в конфигурацию вашей системы.

Дополнительно

Для лучшего понимания работы IIS рекомендую ознакомиться, как происходит процесс обработки запроса от браузера пользователя до конечного пула приложения ASP.NET в этой полезной статье «Основы архитектуры IIS, или запросопровод для ASP.NET».
Если вы используете IIS8 — не будет лишним обратить внимание на «Полноценное регулирование нагрузки CPU (CPU Throttling)».

Заключение

Для сайтов, которые не совершают частые сетевые запросы на стороне сервера, стандартных настроек пула должно хватать (processModel/autoConfig=»true”). При этом IIS выставит ограничение в 20 рабочих потоков и 12 удаленных соединений на ядро. При превышении этих значений запросы начнут становиться в очередь и производительность веб-приложения упадёт.
Если ваш сайт работает хорошо и вы можете оценить предполагаемую нагрузку на систему, то не стоит ничего менять. Если же у вас начинаются «зависания” при обработке запросов к различным сервисам — не следует сразу винить во всем железо! Лучше внести изменения в базовую конфигурацию ASP.NET. Имейте в виду, что изменение базовых параметров пула приложений непременно приведёт к увеличению загрузки процессора. Оптимальная балансировка всех параметров системы — ключ к стабильной и производительной работе оборудования. Как говорится, «предупрежден — значит вооружен”.
Приглашаю всех поделиться вашим опытом настройки и оптимизации работы производственных веб-серверов на платформе Windows Server.

Отличительной особенностью MS SQL Server, по сравнению с другими СУБД, является относительная простота установки и администрирования. В данной статье мы произведем установку SQL Server 2012 и сделаем необходимые первоначальные настройки для работы с 1С:Предприятие.

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

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

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

Установка SQL Server

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

Правила поддержки установки

Помимо этого, стоит скачать все последние обновления (service pack, cumulative update) для Вашей версии SQL Server.

В целом, установка SQL Server не вызывает особой сложности, поэтому, рассмотрим только значимые этапы.

Процесс установки MS SQL Server

Этап «Роль установки»

На данном этапе необходимо выбрать «Установка компонентов SQL Server»

Роль установки

Этап «Выбор компонентов»

Здесь нам необходимо, как минимум, выбрать указанные в изображении пункты: «Службы компонента Database Engine», «Средства связи клиентских средств», «Обратная совместимость клиентских средств», «Компоненты документации», «Средства управления — основные» и «Средства управления — полный набор»

Выбор компонент SQL Server

Этап «Настройка экземпляра»

В настройках можно оставить «Экземпляр по умолчанию» или же выбрать «Именованный экземпляр» и задать имя и идентификатор экземпляра, но особой необходимости в этом нет. Поскольку, к именованному экземпляру обращение происходит посредством строки вида: ServerSQL\InstanceID — необходимо выбирать понятный и короткий идентификатор экземпляра.

Настройка экземпляра

Этап «Конфигурация сервера»

На вкладке «Учетные записи служб» желательно сразу указать автоматический запуск агента SQL Server для того чтобы в дальнейшем не было проблем при настройке планов обслуживания. Если устанавливается именованный экземпляр, режим запуска службы «Обозреватель SQL Server» так же должен быть установлен в режим «авто». На вкладке «Параметры сортировки» необходимо убедиться что стоит «Cyrillic_General_CI_AS», в противном случае, выбрать данный вариант.

Учетные записи служб Параметры сортировки

Этап «Настройка компонента Database Engine»

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

Настройка компонента Database Engine

Следующим этапом будет указание каталога данных на одноименной странице. Здесь есть свои рекомендации:

  1. Расположение файлов базы данных и журнала транзакций надо разнести на разные физические диски. Это обеспечит дополнительную надежность данных, т.к. в случае выхода из строя одного из дисков останется возможность восстановления базы данных (восстановление базы данных до актуального состояния по резервной копии и логу транзакций, в случае выхода диска с файлом БД).
  2. Вынести базу tempdb на отдельный физический диск. Это увеличит производительность, т.к. SQL Server постоянно работает с данной системной базой, создавая нагрузку на диск. Например, SQL Server использует tempdp для хранения временных таблиц.
  3. Выбрать отдельный диск или ресурс в локальной сети для хранения резервных копий. Данная рекомендация опять же обеспечивает дополнительную надежность.

Выбор каталогов данных

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

Постустановочная настройка

Для того чтобы сервер SQL не забрал для своих целей всей доступной оперативной памяти, необходимо установить ограничение. Для этого в Management Studio, в свойствах сервера, на вкладке «Память», необходимо задать параметр «Максимальный размер памяти сервера». Для того чтобы вычислить «комфортное» значение, надо узнать объем оперативной памяти установленной на сервере, из нее вычесть объем памяти, занимаемой приложениями, за исключением MS SQL Server, с учетом необходимого «запаса», и примерно это значение установить в указанном поле. В дальнейшем это значение можно подкорректировать. Так же разумным будет указание минимального размера памяти равного половине от максимального. Минимальное значение необходимо указать для того чтобы никакой другой процесс не смог забрать всю память, вытеснив при этом сервер SQL; это особенно важно если SQL Server расположен, например, на одном сервере с сервером 1С:Предприятие.

Максимальный размер памяти сервера

Последней настройкой будет установка параметра «Максимальная степень параллелизма» (Max degree of parallelism) в рекомендуемое значение, равное 1. Данный параметр указывает на оптимальную степень параллелизма (количество процессоров, задействованных для выполнения одной инструкции, для каждого из планов параллельного выполнения).

Максимальная степень параллелизма

Теперь необходимо установить скачанные обновления (service pack и cumulative update) и перезагрузить сервер.

На этом установка MS SQL Server для работы 1С:Предприятие завершена!

Хеллоу пипл С недавнего времени я начал замечать в диспетчере процесс sqlwriter.exe, но честно говоря может он и раньше был, я просто в диспетчер не заглядывал. Ну вот и думаю, что это за процесс и что ему нужно?

Итак, какой я могу сделать вывод исходя из своих знаний. Этот процесс относится к Microsoft SQL Server (написано в колонке Описание в диспетчере) и как я понял он нужен какой-то проге, которая работает с каким-то там сервером. В процессе sqlwriter.exe есть слово writer, то есть это что-то связанное с записью запросов к базе данных SQL. Ну, что-то типа такого..

Что делать вообще? Удалять этот процесс, а вернее даже думать об этом я бы не советовал. После его удаления у вас могут появится какие-то глюки или какая-то прога будет неправильно работать.

Итак, вот этот процесс sqlwriter.exe в диспетчере задач:

Процессор не грузит, оперативки много не использует, это уже хорошо.

Идем дальше, процесс запускается вот из этой папки:

C:\Program Files\Microsoft SQL Server\90\Shared

В общем как отключить процесс sqlwriter.exe так бы сказать безопасно? А вот тут такой рецептик у меня есть. В общем смотрите, в диспетчере нажимаете по процессу sqlwriter.exe правой кнопкой и выбираете Место хранения:

Откроется папка. Ничего с ней не делаете но и не закрываете. Потом процесс в диспетчере быстро завершаете а выделенный файл в папке переименовываете например в sqlwriter.exe_, в итоге у меня получилось так:

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

Потом я сделал перезагрузку на всякий случай чтобы убедится что процесса sqlwriter.exe больше не будет в диспетчере.

На всякий случай, если вы заметили у себя какие-то подозрительные процессы, то вполне возможно что у вас какая-то вирусная прога стоит… Тут я рекомендую воспользоваться утилитами AdwCleaner и HitmanPro. Почему именно они? Потому что они находят те вирусные проги и просто вирусы, которые не находят обычные антивирусы! А все потому, что это рекламные вирусы и типа они не особо опасные для ПК. Ну в принципе так оно и есть, но они любят пихать рекламу везде, но пароли при этом не крадут. Ну а по поводу обычных вирусов советую конечно же Dr.Web CureIt!, он мастер по уничтожению всяких трянов, червей, вирусов и прочей нечисти.

Ну вот на этом все, надеюсь что все понятно. Удачи вам, хорошего настроения

На главную! неизвестные процессы 30.07.2016
Сегодня рассмотрим один из вариантов обслуживания баз 1С в СУБД MS SQL.
1. Немного теории по планам обслуживания
2. Постановка задачи по созданию планов обслуживания
3. Создание плана обслуживания (Полная копия)
4. Создание плана обслуживания (Разностная копия)
5. Создание плана обслуживания (Резервная копия журналов транзакций)
6. Мониторинг планов обслуживания
1. Немного теории по планам обслуживания
Может многие со мой не согласятся, но для меня главной целью использования Планов обслуживания в MS SQL является создание резервных копий. Местные ITишники либо еще не делают резервные копии, либо уже делают, после печальных последствий отсутствия резервных копий. Да, не спорю, Планы обслуживания также нужны для оптимизации БД и выгрузки журналов транзакций, в последнем случаи, если не выполнять выгрузку журналов транзакций, у вас может вырасти база данных и занять все пространство на диске, 1С встанет колом и пользователи не смогут работать с базой, а вам придется выполнять шринк (Shrink) базы, это наверно самое страшное для ITишники после поломки базы и отсутствии резервных копий. Но об шринке (Shrink) поговорим в другой раз.
MS SQL Server поддерживает три модели восстановления:
1) Simple (Простая) — хранится только необходимый для жизни остаток журнала транзакций.
2) Full (Полная) — хранится весь журнал транзакций с момента последнего резервного копирования журнала транзакций.
3) Bulk logged (С неполным протоколированием) — часть операций записываются в очень компактном формате. В остальном идентична Full.
Модель восстановления базы можно посмотреть, в свойствах базы данных, на вкладке Параметры. Там же ее можно поменять. На практике я использую Full (Полная).

MS SQL поддерживает три типа формирования резервных копий:
1) Full (Полная копия)
2) Differential (Дифференциальная копия, Разностная копия)
3) Log (Резервная копия журналов транзакций)
Не путайте понятия: полная модель восстановления и полная резервная копия — разные вещи.
Рассмотрим подробно три типа формирования резервных копий.
1) Полная резервная копия
Позволяет восстановить состояние базы данных на некоторый момент времени. Состоит из копии файлов данных и журнала транзакций на момент завершения формирования резервной копии.
2) Разностная резервная копия
Хранит данных, изменившиеся с момента последней Полной резервной копии. При восстановлении нужно сначала восстановить Полную резервную копию в режиме NORECOVERY, потом можно применить любую из последующих Разностных копий. За счет этого можно значительно снизить объём дискового пространства для хранения резервной копии. Обратите внимание: без предыдущей Полной резервной копии Разностная копия бесполезна. Каждая последующая Разностная копия будет хранить все данные, входящие в предыдущую Разностную резервную копию, сделанную после предыдущей Полной копии. Поэтому каждая следующая Разностная копия больше предыдущих, пока снова не сделать Полную копию. Соответственно для восстановления на какой-то момент времени достаточно последней Полной резервной копии и последней Разностной копии. Промежуточные копии для восстановления не нужны.
3) Резервная копия журналов транзакций
Содержит копию журналов транзакций за некоторый период. Обычно с момента прошлой Резервной копии журналов транзакций до момента формирования текущей Резервной копии журналов транзакций. За счет этого Резервные копии журналов транзакций позволяют (с учетом Полной и Разностной копий) восстановить базу данных на любой момент времени. Резервная копия журналов транзакций высвобождает место в файле журнала транзакций, что позволяет ITишники избавиться от шринка базы данных.
Обратите внимание: набор Резервных копий журналов транзакций по сути бесполезен, если он не является непрерывной цепочкой, причем момент начала последнего успешного Полного или Разностного резервного копирования должен быть внутри периода этой цепочки.
2. Постановка задачи по созданию планов обслуживания
В организации N работают по шестидневке с 8:00 до 17:00. Обед с 12:00 до 13:00.
Имеется в MS SQL база данных с именем Moodle.
Что нужно сделать:
1) Проверить модель восстановления базы данных, должна быть Полная.
2) Создать план обслуживания, который будет создавать Полную резервную копию базы данных каждое воскресение в 17:00. Очищать хранилище от устаревших резервных копий старше 15 дней.
3) Создать план обслуживания, который будет создавать Разностную копию базы данных каждый день в 21:00 кроме воскресения.
4) Создать план обслуживания, который будет создавать Резервную копию журналов транзакций два раза в день, в 12:00 и в 17:00, кроме воскресения.
3. Создание плана обслуживания (Полная копия)
Запускаем SQL Server Management Studio, в Обозревателе объектов проходим по ветке Управление — Планы обслуживания.
Правой кнопкой по пункту Планы обслуживания и в контекстном меню выбираем Создать план обслуживания… Указываем имя, к примеру: Moodle. В открывшемся конструкторе будем создавать вложенные планы обслуживания. щелкните два раза по строке ВложенныйПлан _1
Задайте Имя, Описание и обязательно настройте Расписание выполнения вложенного плана обслуживания: еженедельно в воскресение 17:00:00Используя Панель элементов создадим первый вложенный план. Достаточно нужный элемент в панели ухватить, перенести на рабочую область и там бросить. Для открытия мастера настройки элемента достаточно два раза щелкнуть по элементу.

Ниже на рисунке представлен результат настройки, который должен у нас получится, но все по порядку.
Размещаем задачу «Проверка целостности базы данных», двойным щелчком мыши открываем диалог настройки задачи, в первую очередь в свойстве Базы данных отмечаем нужную базу, а остальное настраиваем как показано на рисунке. При желании можно посмотреть T-SQL код полученной задачи.
Размещаем следующую задачу «Перестроение индекса» она у нас будет выполнятся только после успешно выполненной предыдущей задачи. Настраиваем как показано на рисунке, не забываем указать конкретную базу данных.
Для связи двух задач щелкните по первой задаче «Проверка целостности базы данных» у этой задачи появится стрелка, щелкните по ней и не отпуская соедините со второй задачей «Перестроение индекса». Для изменения значения условия выполнение следующей задачи, щелкните два раза по линии и в открывшемся диалоговом окне выполните необходимые настройки.
Размещаем задачу «Обновление статистики» которая будет выполнятся после завершения предыдущей. Настраиваем эту задачу как на рисунке, не забываем выбрать базу данных. Размещаем задачу «Выполнение инструкции T-SQL» с кодом: DECLARE @intDBID INTEGER SET @intDBID = (SELECT dbid FROM master.dbo.sysdatabases WHERE name = ‘Moodle’) DBCC FLUSHPROCINDB (@intDBID) Инструкция DBCC FREEPROCCACHE используется для аккуратной очистки кэша планов. Освобождение кэша планов приводит, например, к тому, что хранимая процедура повторно компилируется, а не используется из кэша. При настройки для своей базы не забываем изменить имя БД Moodle. Размещаем следующую задачу «Резервное копирование базы данных» она у нас будет выполнятся полную резервную копию базы данных. Размещать резервные копии желательно на на СХД, если нет, то на физически другом диске, но не в коем случаи на том же диске где сама база данных, иначе теряется весь смысл резервных копий. Настраиваем как показано на рисунке, не забываем указать конкретную базу данных.

Размещаем следующую задачу «Очистка журнала» она у нас будет выполнятся очистку журналов. Настраиваем как показано на рисунке. Размещаем следующую задачу «Очистка после обслуживания» она у нас будет выполнятся удаление старых файлов резервных копий, так как свойстве Расширение файла указана маска *.*, то удаляются будут все файлы, и полной резервной копии, и разностной, и журнала транзакций. Настраиваем как показано на рисунке. Обратите внимание, две последние задачи выполняются после выполнения задачи «Резервное копирование базы данных» и самое главное, задачу «Очистка после обслуживания» нужно выполнять только после успешно выполненной задачи «Резервное копирование базы данных». Что бы не получилось, что у вас уже который раз не создаются резервные копии, а вы задачей «Очистка после обслуживания» удаляете последние актуальные копии.
4. Создание плана обслуживания (Разностная копия)
Добавим вложенный план обслуживания, на рисунке ниже красной рамкой выделена данная кнопка и показан результат схемы обслуживания, который должен получится, но все по порядку. Заполним поля свойств и настроим расписание как показано на рисунке. Размещаем две задачи «Проверка целостности базы данных» и «Резервное копирование базы данных», обратите внимание последняя задача выполняется только после успешного завершения предыдущей. Иначе какой смысл делать резервную копию если она не корректна. На рисунке представлена настройка задачи «Проверка целостности базы данных». На рисунках представлены настройки задачи «Резервное копирование базы данных». Обратите внимание на Тип резервной копии, должен стаять Разностное. И не забудьте указать конкретную базу данных.
5. Создание плана обслуживания (Резервная копия журналов транзакций)
Добавим два вложенных плана обслуживания, один настроим на 12:00 второй на 17:00. На рисунке представлен результат плана обслуживания на 12:00, на 17:00 отличатся ничем не будет, только временем выполнения.
Разместим одну задачу «Резервное копирование базы данных». Обратите внимание на Тип резервной копии, должен стаять Журнал тарнзакций. И не забудьте указать конкретную базу данных.
6. Мониторинг планов обслуживания
После создания всех Планов обслуживания они появятся в ветке Агент SQL Server. Откройте Мониторинг активности заданий, в этом мониторинге можно увидеть какие задачи, когда выполнялись, когда следующее выполнение и успешно ли они выполнялись. Для запуска определенного плана, достаточно в контекстном меню выбрать пункт Запустить задание на шаге…

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *