MS Tech.Ed Russia 2011 online translation

онлайн трансляция MS Tech.Ed Russia 2011
Смотреть всем!

Перепост от Олега Филиппова: Давайте забудем о свертке БД? Файловые группы и секции таблиц SQL, сжатие таблиц SQL.

Давайте забудем о свертке БД? Файловые группы и секции таблиц SQL, сжатие таблиц SQL.:

I) Проблемы, которые мы пытаемся решать сверткой БД
   1) Увеличение размера БД
   2) Низкая производительность выполнения запросов
   3) Большой объём "ненужных данных" которые мешают работе пользователей
II) "Технологические" решения проблем
   1) Проблема увеличения размера БД
         а) Разделение БД на файловые группы
         б) Размещение БД или её части на сетевом диске
         в) Сжатие таблиц БД
         г) Секционирование таблиц БД
   2) Проблема низкой производительности запросов
   3) Проблема большого объёма "ненужных данных", которые мешают работе пользователей  

В современных условиях очень странно бывает иногда слышать "нам нужно свернуть БД 1С - её объём превышает 50 ГБ". Если бы такое собирались сделать администраторы систем SAP R3 или Oracle e Business Suite или даже MS Dynamics Ax их бы наверное уволили. Тем не менее, для 1С это является "стандартной практикой". 

Для файловых версий история тянется ещё с версии 1С 7.7 с ограничением в 2ГБ на размер базы. Сейчас ограничение 2ГБ уже только на размер таблицы, размер файла уже может получиться очень и очень не маленьким. Правда если база у вас выросла до такого размера, то наверное туда активно вносились данные - может нужно задуматься о клиент-сервере?

Собственно целью данной статьи является "отговорить" от выполнения свертки БД пользователей клиент-серверного варианта 1С, за счет использования несколько более "продвинутых" технологий.

I) Проблемы, которые мы пытаемся решать сверткой БД

1) Увеличение размера БД
Собственно главный вопрос: а для чего уменьшать размер БД? 
Давайте приложим немного математики:
Серверный жесткий диск на 500 ГБ стоит около 10 т.р. Объединить в RAID 1 для надежности будет 20 т.р.
Естественно могут быть проблемы отсутствия места под новые жесткие диски в самом сервере... 
А покупка внешнего дискового массива уже обойдётся не так дешево. Что же делать?
Да всё просто - разместить файлы БД на сетевом диске, а как? Ну об этом статье далее.

Увеличение доступного для БД дискового пространства обойдётся нам в 20 т.р. + 10 минут работы специалиста. Сколько часов работы специалиста потребует свертка БД? А сколько времени простоя может получиться? По самым скромным оценкам за свертку УПП объемом гигабайт в 60, со средним количеством ошибок, партионным учетом с проверкой результатов свертки, выправления этого же партионного учета возьмутся тысяч за 30-40.
Универсальной обработкой всё и сразу вряд ли свернётся, особенно если у вас база практически "никогда не останавливается". Партионный учет в любом случае выправлять. Вообщем много там работы. А самое главное, что итоговая проверка должна быть очень тщательной, и всё равно останутся ошибки...

Кроме того, если база уже размером не 60 а, к примеру, 120 ГБ... малейшая ошибка в коде 1С при свертке и всё... процедура заканчивается не удачно. А ошибки точно будут. Как "недостаточно памяти" при работе с ТЗ, так и ошибки вроде
http://img180.imageshack.us/img180/656/1c3y.jpg

Итоговая цифра получается 30-40 т. минимум против 20-25 в случае покупки жесткого диска, и получения 500 ГБ дополнительного места

Поэтому появляются продукты вроде http://infostart.ru:8080/public/78934/ 
Хорошие наверное продукты, и цели свои выполняют. Вот только меняется структура таблиц от версии к версии платформы. 1С нам об этом не раз говорили. Появился разделитель данных в 14-ом релизе и всё... скорее всего эта обработка для 14 релиза уже не подойдёт. Да и страшно как-то, не говоря уже о нарушении лицензионного соглашения.

И даже после этого найдутся пользователи которым "вдруг неожиданно понадобились" стертые данные, которые "как раз хотели поправить" каку-то циферку, которая "не влияет на последовательнсти" в документе закрытого периода. А хуже если выяснится что кто-то эти документы смотрел постоянно для каких-то только ему ведомых целей. Конечно это всё лишь ошибки в методике работы, но тем не менее недовольство пользователей будет.

2) Низкая производительность выполнения запросов
Ну кто же вам сказал что "чем меньше тем быстрее"? Для корректно разработанной ИС это утверждение не верно.
На рисунке ниже кратко и "на птичьем языке" приведен простейший пример выборки по индексу типа B-Дерева записи в таблице адресов:


 В тему индексов углубляться не хочу, тем более там всё несколько сложнее. Самое главное - поиск проходит не "горизонтально" по таблице, а "вертикально" по "уровням" индекса. 

Аналогия - записная книжка: Каждая страница начинается со своей буквы, только вот на каждой странице ещё такая же записная книжка в которой вы можете выбрать вторую букву в слове, и так до тех пор, пока не встретите ту страницу, на которой будет одна или несколько записей. Удобно? Конечно удобно, в случае если у вас больше нескольких сотен контактов. А если у вас их всего десять? Не проще ли их просто записать на один листочек, который можно просмотреть глазами? Вот и в случае индексов так же. Он эффективен если в таблице несколько тысяч записей, а вот если одна единственная - не очень. Благо СУБД научились самостоятельно выбирать "план запроса" и решать использовать или не использовать тот или иной индекс. Вот только в случае "перебора" всех строк таблицы без индекса СУБД очень часто блокирует всю эту таблицу, и вы наблюдаете "непонятно откуда взявшиеся блокировки" после свертки ИБ.

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

3) Большой объём "ненужных данных" которые мешают работе пользователей
Об этом вы пользователям сперва сделайте рассылку. И получите кучу сообщений что "данные ненужными не бывают". Тем не менее многим не нравится "видеть документы за прошлые периоды" и "архивные данные", с ними нельзя не согласиться. Но решает ли сверка эти проблемы? Убирает ли она ненужные номенклатуры из номенклатурного справочника? Контрагентов с которыми больше не будет вестись работа? А как показывает практика большинство проблем именно в этом.

II) "Технологические" решения проблем

1) Проблема увеличения размера БД
   а) разделяем БД на файловые группы

     - Открываем Management Studio в списке баз выбираем нужную, открываем её свойства.
     - Переходим на вкладку "Файловые группы" как показано на рисунке, и добавляем ещё одну файловую группу (на примере она названа SECONDARY)
      
      - Переходим на вкладку "Файлы" и добавляем новый файл,  для которого выбираем созданную файловую группу. Этот файл МОЖНО РАСПОЛОЖИТЬ НА ДРУГОМ ДИСКЕ 


   
      - Теперь используя обработку к примеру:http://infostart.ru/public/78049/ определяем какие таблицы мы можем смело "пожертвовать" на более медленный (ну или наоборот всё на медленный, остальные - на более быстрый) носитель. Правило 80/20 здесь действует. 80% операций проводятся с 20% данными, так что думайте какие таблички вам нужны оперативно, а какие не очень. "Хранилище дополнительной информации", документы ввода начальных остатков, документы которые уже не используете сразу определяйте как те которые можно перенести в "медленную" файловую группу.

     - Выбираем таблицу которую нужно перенести в другую файловую группу - выбираем меню изменения таблицы (проект) и в свойствах меняем файловую группу:

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

   б)  Сохраняем БД на сетевом диске

DBCC TRACEON (1807)

 Пишем данную команду в Management Studio, выполняем и можем успешно создавать базы по сети. Само собой при этом экземпляр SQL Server-а должен быть запущен от имени доменной учетной записи, и у этой записи должны быть права на нужную сетевую папку.
     Но прошу быть очень внимательными при использовании данной команды в случае если у вас пропадёт сеть при работе с БД вся БД на время её отсутствия будет не доступной. Microsoft не зря закрыли эту возможность для массового использования. Вообще эта возможность предполагается для создания баз на NAS хранилищах, что и настоятельно рекомендую. Подойдёт так же стабильный и надежный файловый сервер, имеющий прямое подключение к серверу на котором запущен MS SQL СУБД.
Подробнее про другие флаги трассировки можно прочитать в статье http://msdn.microsoft.com/ru-ru/library/ms188396.aspx 
     Т.е. часть файловую группу можно вообще хранить в сети, а уж там дисковое пространство расширяется без проблем.

   в) Сжатие таблиц базы данных

EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)' GO
 
После выполнения этого кода все таблицы в БД будут сжаты. Очевидно, что можно сжимать и таблицы по отдельности... это как бы на ваш выбор. Что даёт сжатие?
      - Экономия дискового пространства
      - Снижение нагрузки на дисковую подсистему
Что расходуется? - процессорное время.
Так что если у вас процессор загружен всё время на 70% и выше - сжатие вам использовать нельзя. Если 20-30% загрузка процессора, и при этом очередь к диску вырастает до 3-4... то сжатие таблиц - как раз "лекарство" для вас. Подробнее про сжатие таблиц БД - http://msdn.microsoft.com/ru-ru/library/cc280449(v=sql.100).aspx 
Важное замечание - функция сжатия таблиц доступна только для обладателей версии Enterprise SQL Server

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

   - Создаём функуцию секционирования по дате:

create partition function YearSection(datetime)
as range right for values ('20110101');

Всё что до 2011 года будет попадать в одну секцию, всё что после - в другую.

  - Создаём схему секционирования

create partition scheme YearScheme
as partition YearSection to (SECONDARY, PRIMARY);

  - Этим говорим, что все данные до 11 года будут попадать в файловую группу "Secondary" а после - в "Primary"

- Теперь осталось таблицу перестроить с разделением на секции. Для этого проще всего воспользоваться уже management studio, потому как процесс не простой. Вам нужно перестроить кластерный индекс для таблицы (который по сути и является самой таблицей), выбрав для индекса созданную схему секционирования:



На рисунке вы видите что выбор не доступен - всё правильно, секционирование таблиц возможно только в версии Enterprise MS SQL Server. Кластерный индекс отличить легко - картинка с круглыми скобками. Для РН и всех объектов 1С он создаётся. Для РН кластерный индекс по периоду есть всегда. Для документов и справочников хорошо бы конечно создать другой, который включает реквизит по которому будет секционирование... но это уже будет являться нарушением лицензионного соглашения.

2) Низкая производительность выполнения запросов.
Все действия, описанные выше не должны повлиять на скорость выполнения основных запросов. Более того, использование файловых групп и секций таблиц позволит вам разместить наиболее часто используемые данные на быстрых дисковых массивах, позволит поменять конфигурацию дисковых массивов, использовать небольшие по размеру i/o accelerator. Таким образом скорость выполнение запросов только повысится. А сжатие таблиц позволит вам дополнительно разгрузить дисковую подсистему, если она являлась узким местом. А вообще если говорить о скорости выполнения запросов, то анализ их планов выполнения, оптимизация запросов для грамотного использования индексов даст намного более существенный прирост производительности, чем все "ухищрения" на уровне MS SQL.

3) Большой объём "ненужных данных" которые мешают работе пользователей

Но для этого нужно не сворачивать базу, а проделать следующее:
а) Объяснить всем как пользоваться отборами, как они сохраняются, как пользоваться интервалами журнала, как они сохраняются
б) Пометить на удаление ненужные данные если они не несут никакой смысловой нагрузки (контрагентов и номенклатуру, с которыми больш не работаете) - этим вы принесёте пользователям больше пользы чем сверткой. В случае наличия ресурсов настроить автоматическую пометку на удаление неиспользуемых объектов и сделать отбор по умолчанию в программном коде для того чтобы не отображались по умолчанию не нужные пользователям объекты - помеченные на удаление
в) Настроить другие полезные "отборы по умолчанию" - например чтобы каждый менеджер по умолчанию видел только свои документы. А если хочет посмотреть документы "товарища" - нужно отключать отбор.

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

Интересное и важное мероприятие от Microsoft.

Ссылка на Хабре

Исключительно полезный постер об SQL Performance Counters

Позаимствовано у Alexey Knyazev

Сам документик

Путевые заметки при установке MS SQL 2008 и сервера 1С Предприятия 8 x86-64

- Требуется: отдельностоящий сервер с 16 ядрами и 16Гб ОЗУ;
- Предполагается работа в домене Windows 2003, учитывая его уровень, выбираем серверную ОС; (W2008 была в домене попробована, но упала после попытки дать пользователю домена права локального админа, бороться дальше не стали);
- Устанавливаем ОС Windows Server 2003 x86-64;
- Устанавливаем драйверы;
- Конфигурируем диски (если требуется);
- В моем случае под SQL уже было создано 2 раздела - (F)для данных SQL и (G) для логов SQL(быстрый); (собраны в RAID, как попросил);
- Выравниваем разделы на дисках с данными утилитой Paragon Alignment Tool; Можно воспользоваться утилитой от Microsoft diskpart.exe;
- Регистрируем сервер в домене;
- Если возможно, через Windows Update накатываем все обновления Windows Server 2003;
- Устанавливаем SQL 2008 x86-64:
* Установщик обновляет .Net Framework
* Обновляет версию установщика Windows
* Запускает непосредственно установку MS SQL
* Конфигурируем экземпляр сервера как Default Instance
* Выбираем компоненты по минимуму: DB Engine, Management tools и клиентский драйвер
* Запускать службы SQL Server и SQL Server Agent будем из-под доменного администратора, о чем указываем в настройках
* Указываем что пользовательские базы на F
* Указываем, что пользовательские логи на G
* TempDB тоже на G
* Корневая директория SQL пусть тоже будет на F
* Способ авторизации выбираем Mixed
* Указываем пароль для пользователя sa
* Добавляем текущего пользователя (вероятно, доменного админа) и пользователя, под которым обычно заходит администратор 1С Предприятия
* Настройки Collation и пр. тонкости оставим на потом
* Ждем окончания установки
- Для проверки запускаем Management Studio, если службы запустились корректно, должно подключиться к нашему экземпляру без проблем;
- Версия установленного сервера SQL - 10.0.1600;
- Желающие могут сразу сконфигурировать сервер: указать размер памяти, который мы можем отдать SQL. Для 16Гб ОЗУ я указал мин. 4000Мб - макс. 8000Мб, позже посмотрим реальное использование памяти сервером SQL;
- Скачиваем сервис-паки SQL 2008 SP1, SQL 2008 SP2, SQL 2008 SP3 (наверно можно было только SP3, но я предпочел не экспериментировать);
- Поочередно накатываем их, перезагружаемся;
- Версия SQL Server после установки SP3 - 10.0.5500;
- Устанавливаем средство диагностики для SQL: SQL 2008 R2 Best Practices Analyzer; До него потребуется установить PowerShell 2.0 и Microsoft Baseline Configuration Analyzer;
- Для "прикручивания" Performance Dashboard Reports пришлось воспользоваться советом;
- Во избежание проблем после начала эксплуатации, рекомендую сразу запустить Best Practices Analyser, чтобы понять, что в настройках ОС и SQL не хватает для корректной работы;
- Устанавливаем сервер 1С Предприятия 8:
* Всё по умолчанию, указываем только, что запускать мы его будем с правами доменного администратора;
* Устанавливаем драйвер HASP, USB ключ может быть установлен заранее;
* Служба Агента сервера 1С Предприятия должна сразу запуститься, если не запускается, в настройках службы неверно указаны параметры учетной записи под которой она стартует; Простое средство диагностики - открыть Task Manager и посмотреть наличие процесса RPHOST.EXE - если он есть, служба запущена;
* Открыть консоль сервера 1С Предприятия, отключить рабочий процесс, установить признак "Много процессов", включить существующий процесс, добавить необходимое количество рабочих процессов;
- Пытаемся создать информационную базу на сервере 1С Предприятия с подключением к установленному SQL;
- Пытаемся подключиться клиентом с компьютера из сети;
- Настраиваем Backup device в SQL и план для оперативного бэкапа;
- Настраиваем скрипт перезапуска рабочих процессов сервера 1С;

Поиск узких мест ввода-вывода для MS SQL Server

Поиск узких мест ввода-вывода для MS SQL Server

Копипаст из http://msmvps.com/blogs/irinanaumova/archive/2011/05/06/1792775.aspx

По материалам статьи Tibor Nagy: How to Identify I/O Bottlenecks in MS SQL Server - 17.03.2011

Проблема

Суть проблематики данной статьи - регулярное замедление в работе баз данных SQL Server. После статей, посвящённых анализу использования памяти и CPU, мы хотели бы продолжить исследование причины замедления путём анализа узких мест ввода-вывода.

Решение

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

Performance Monitor

Чтобы определить загрузку подсистемы ввода-вывода, можно воспользоваться системной утилитой Performance Monitor. Перечисленные ниже счётчики производительности могут оказаться полезны для этих целей:

PhysicalDisk Object: Avg. Disk Queue Length. Этот счетчик показывает среднее число запросов чтения и записи, которые были поставлены в очередь для указанного физического диска. Чем выше это число, тем большее дисковых операций ожидает ввода-вывода. Если это значение во время пиковой нагрузки на SQL Server частенько превышает двойку, следует задуматься о необходимости принятия адекватных мер. Если используется несколько дисков, показания счётчика нужно разделить на число дисков в массиве и убедиться, не превышает ли результирующее значение число 2. Например, у Вас есть 4 диска и длина очереди диска 10, искомая глубина очереди находится следующим образом: 10/4 = 2,5, это и будет значением, которое нужно анализировать, а не 10.

Avg. Disk Sec/Read и Avg. Disk Sec/Write показывают среднее время чтения и записи данных на диск. Хорошо, если это значение не превышает 10 ms, но все еще приемлемо, если значение меньше 20 ms. Значения, превышающие этот порог, требуют исследования возможностей оптимизации.

Physical Disk: %Disk Time - время, которое диск был занят обслуживанием запросов записи или чтения. Это значение должно быть ниже 50%.

Disk Reads/Sec и Disk Writes/Sec - показатель уровня загруженности диска операциями чтения - записи. Значение должно быть меньше 85% от пропускной способности диска, поскольку при превышении этого порога время доступа увеличивается по экспоненте.
Пропускную способность диска можно определить постепенно увеличивая нагрузку на систему. Одним из способов определения пропускной способности дисковой подсистемы является использование специализированной утилиты SQLIO. Она позволяет определить ту точку, где пропускная способность перестаёт расти при дальнейшем увеличении нагрузки.

При выборе конфигураций RAID можно использовать следующие формулы вычисления числа операций ввода-вывода (I/Os), приходящихся на один диск:

Raid 0: I/O на диск = (чтений + записей) / число дисков массива
Raid 1: I/O на диск = [чтений + (записей *2)] / 2
Raid 5: I/O на диск = [чтений + (записей *4)] / число дисков массива
Raid 10: I/O на диск = [чтений + (записей *2)] / число дисков массива

Вот пример вычисления количества операций ввода-вывода на диск для RAID 1 на основе значений счетчиков:

Disk Reads/sec = 90
Disk Writes/sec = 75
Формула для ввода-вывода на RAID-1 массив является [чтений + (записей*2)] / 2 или [90 + (75*2)] / 2 = 120 I/Os на диск.

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

Есть полезные динамические административные представления (DMV), с помощью которых можно выявить узкие места ввода-вывода.
Специальный тип ожидания краткой блокировки для операции ввода-вывода (I/O latch) имеет место тогда, когда задача переходит в состояние ожидания завершения кратковременной блокировки буфера, находящегося в состоянии обслуживания запроса ввода-вывода. В зависимости от типа запроса, это приводит к появлению ожиданий с именами PAGEIOLATCH_EX или PAGEIOLATCH_SH. Длительные ожидания могут указывать на проблемы с дисковой подсистемой. Чтобы посмотреть статистику таких ожиданий можно использовать системное представление sys.dm_os_wait_stats. Для того, что бы определить наличие проблем ввода-вывода, нужно посмотреть значения waiting_task_counts и wait_time_ms при нормальной рабочей нагрузке SQL Server и сравнить их со значениями, полученными при ухудшении производительности.

select * from sys.dm_os_wait_stats
where wait_type like
'PAGEIOLATCH%'
ORDER
BY wait_type asc

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

select
db_name(database_id),
file_id,
io_stall,
io_pending_ms_ticks,
scheduler_address
from sys.dm_io_virtual_file_stats (NULL, NULL) iovfs,
sys.dm_io_pending_io_requests as iopior
where iovfs.file_handle = iopior.io_handle

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

Я рекомендую регулярно проверять уровень фрагментации и конфигурацию дисков, используемых экземпляром SQL Server.
Фрагментация файлов на разделе NTFS может стать причиной существенной потери производительности. Диски должны регулярно дефрагментироваться. Исследование показывают, что в некоторых случаях диски, подключаемые из сетей SAN, менее производительны, если их файлы дефрагментированы, т.е. эти СХД оптимизированы под случайный ввод-вывод. Прежде чем устранять файловую фрагментацию, стоит выяснить, как она сказывается на производительности работы SAN.
Фрагментация индексов также может стать причиной повышения нагрузки ввода-вывода на NTFS, но на это влияют уже другие условия, отличные от тех, что существенны для SAN, оптимизированных для случайного доступа.

Конфигурация дисков / Best Practices

Как правило, для повышения производительности, файлы журналов кладут на отдельные физические диски, а файлы данных размещают на других физических дисках. Ввод-вывод для высоко нагруженных файлов данных (включая tempDB) носит случайный характер. Ввод-вывод для файла журнала транзакций носит последовательный характер, кроме случаев отката транзакций.
Встроенные в шасси сервера (локальные) диски можно использовать только для файлов журнала транзакций, потому что они хорошо ведут себя при последовательном вводе-выводе, а при случайном вводе-выводе ведут себя плохо.
Файлы данных и журналов должны размещаться на разных дисковых массивах, у которых используются разные наборы физических дисков. В большинстве случаев, когда решение должно укладываться в не большой бюджет, я рекомендую размещать файл журнала транзакций на массиве RAID1, собранном из локальных дисков. Файлы данных БД лучше разместить на внешней системе хранения в сети SAN, так, чтобы к используемым для данных физическим дискам доступ получал только SQL Server, что позволит контролировать обслуживание его запросов и получать достоверные отчёты загрузки дисковой подсистемы. От подключения дисковых подсистем напрямую к серверу лучше отказаться.
Кэширование записи должно быть включено везде, где только это возможно, и вы должны удостовериться, что кэш защищен от перебоев в питании и других возможных отказов (независимая батарея подпитки кэша на контроллере).
Во избежание появления узких мест ввода-вывода для OLTP систем, лучше не смешивать нагрузки, характерные для OLTP и OLAP. Кроме того, удостоверьтесь, что серверный код оптимизирован и, где это необходимо, созданы индексы, которые тоже позволяют избавиться от ненужного ввода-вывода.

Дополнительные материалы

Как справиться с PAGELATCH при больших INSERT-нагрузках
SQL Server: Методика тестирования дисковой подсистемы
Tips for DBA: выравнивание кластеров NTFS и блоков RAID-массивов
Tips for DBA: Статистика I/O файлов баз данных
Минимальные требования к размещению файлов пользовательских баз данных
Дефрагментация баз данных SQL Server с помощью утилиты Diskeeper
Правда о дефрагментации
Ввод-вывод

Published Fri, May 6 2011 18:01 by Ирина Наумова

Filed under: SQL Server

ZX Spectrum в России: большой путь маленького компьютера - Компьютерра-Онлайн

ZX Spectrum в России: большой путь маленького компьютера - Компьютерра-Онлайн

Автоматический перезапуск службы агента сервера 1С Предприятия 8

Автоматический перезапуск службы агента

сервера 1С Предприятия 8.

   

Известно, что при функционировании рабочих процессов сервера 1С Предприятия 8.1 rphost.exe существует следующая проблема: из-за особенностей платформы, с подключением каждого нового клиента к рабочему процессу, увеличивается размер занимаемой рабочим процессом оперативной памяти.  При этом, при отключении клиента, занимаемый при подключении объем не освобождается. Так же объем памяти, занимаемый рабочим процессом может увеличиваться при выполнении программного кода. Данное поведение называется “Утечками памяти” или “Memory Leaks”. В итоге, когда объем занимаемой памяти процессом rphost.exe вырастает больше опеределенного предела (в моем случае это было >1Gb), рабочий процесс безусловно перезапускается. Понятно, что клиенты, подключенные к этому процессу, получают сообщение, что соединение с сервером разорвано, прекращают работу и вынуждены переподключаться. В зависимости от количества пользователей и количества запущенных рабочих процессов, данная проблема возникает с той или иной частотой. В моем случае - пользователей порядка 60 и один рабочий процесс, подобная ситуация возникала до 5 раз в неделю. Т.е. ни о какой стабильной работе системы 1С Предприятие в этом случае речь не идет. 

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

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

    Поскольку служба агента сервера 1С Предприятия представляет собой стандартную службу, в арсенале Windows есть стандартный способ остановки и запуска служб из командной строки командами net stop и net start. Достаточно эти команды лишь включить в bat-файл и настроить шедулер на запуск bat-файла по расписанию, я настроил перезапуск один раз в сутки, в ночное время. Следует иметь ввиду, что если перезапускать рабочие процессы в рабочее время, все подключенные к серверу 1С Предприятия клиенты будут отключены!

Кроме того, чтобы немного разнести по времени команды остановки и запуска службы, будем использовать известную утилиту sleep.exe, которую легко найти в Сети.

   

Примерный текст bat-файла restart1c.bat:

rem @echo off
rem \\----- начало скрипт остановки и запуска агента сервера 1С Предприятия----\\
set logfile="stopstartlog.txt"
set timeout=20
echo %date% %time% >>%logfile%
net stop "1C:Enterprise 8.1 Server Agent" >>%logfile%
c:\scripts\sleep %timeout%
echo %date% %time% >>%logfile%
net start "1C:Enterprise 8.1 Server Agent" >>%logfile%
c:\scripts\sleep %timeout%
rem \\----- конец скрипт остановки и запуска агента сервера 1С Предприятия----\\

* logfile - файл stopstartlog.txt, куда будут записываться результаты выполнения команд, размещается в том же каталоге, что и сам bat-файл;
** timeout - время в секундах;
*** c:\scripts - каталог, где предполагается разместить программу sleep.exe, bat-файл и лог-файл;

Из этого же bat-файла можно сразу после перезапуска процессов запускать скрипт бэкапа средствами 1С Предприятия. В этом случае у вас гарантированно не будет подключен ни один клиент.

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