Параметры рабочих процессов 1с 8.3. Установка субд ms sql server

Печать (Ctrl+P)

В этой статьи я делаю обзор основных мероприятий, которые нужно выполнить для увеличения производительности 1С в клиент-серверном варианте работы 1С:

1. Увеличение аппаратных мощностей.
2. Настройка сервера 1С:Предприятия
3. Настройка SQL сервера
4. Оптимизация кода и алгоритмов в 1С.

1. Увеличение аппаратных мощностей

Минимальные требования, предъявляемые к компьютерам, представленным на сертификацию в фирму «С» для получения логотипа «Совместимо! Система программ 1С:Предприятие» написаны

Производительность сервера 1С: предприятие довольно сильно зависит от частоты процессора, а для сервера базы данных характеристики компьютера должны соответствовать требованиям Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database.

2. Настройка сервера 1С:Предприятия

Инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие можно посмотреть на диске ИТС

В версии 8.3 было добавлено несколько новых параметров в настройке рабочих серверов:

• Максимальный объем памяти рабочих процессов . Настройка позволяет регулировать объем памяти, который могут занять все рабочие процессы данного кластера на данном рабочем сервере.
• Безопасный расход памяти за один вызов . Настройка позволяет ограничить объем памяти, который будет занят при выполнении серверного вызова на данном рабочем сервере.
• Количество ИБ на процесс и количество соединений на процесс . Данные настройки позволяют косвенно регулировать количество рабочих процессов на данном рабочем сервере.
• Менеджер под каждый сервис . Настройка позволяет запустить каждый сервис менеджера кластера как отдельный процесс.

3. Настройка SQL сервера

Особенность настройки Microsoft Sql Server с целю увеличения производительности можно посмотреть на диске ИТС

С помощью Maintenance Plan в разделе Management необходимо выполнять для повышения производительности следующие регламентные задания:

• Дефрагментацию индексов и обновление статистики нужно производить ежедневно, т.к. если фрагментированность индексов > 25%, это резко снижает производительность сервера.
• Дефрагментация и обновление статистики – делается быстро и не требует отключения пользователей. Также рекомендуется делать ежедневно.
• Полная реиндексация – делается с блокировкой БД, рекомендуется делать хотя бы раз в неделю. Естественно, после полной переиндексации сразу же делается дефрагментация индексов и обновление статистики.

3.1 Анализ степени фрагментации индексов

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

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

Для эффективности использования индексов Microsoft SQL Server требуется

• Регулярная переиндексация таблиц базы данных с помощью команды DBCC DBREINDEX ( table_name ) .
• Регулярная дефрагментация индексов базы данных с помощью команды DBCC INDEXDEFRAG (database_name , table_name, index_name ) .

Выбор способа решения этой проблемы зависит от интенсивности операций по модификации таблиц базы данных.

В MS SQL Server 2005 появились новые средства для контроля этого параметра.

Функция таблицы динамического управления sys.dm_db_index_physical_stats возвращает процент фрагментации в столбце avg_fragmentation_in_percent . Если значение в этом столбце превышает 25%, то для восстановления исходных параметров производительности рекомендуется выполнить дефрагментацию этого индекса. От снижения фрагментации индексов могут выиграть операции сканирования больших диапазонов данных, обычные в приложениях хранилищ данных и отчетов.

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

3.2 Использование физической памяти размером более 2 ГБ в Microsoft SQL Server

Microsoft SQL Server 2000 Standard Edition и Microsoft SQL Server 2005 Workgroup Edition могут использовать до 2 ГБ физической памяти, которая динамически распределяется и освобождается в зависимости от рабочей нагрузки. При увеличении объемов базы данных этого объема оперативной памяти становится недостаточно для эффективного кэширования данных и поддержания производительности на приемлемом уровне.

3.3 Уменьшение размера журнала транзакций Microsoft SQL Server

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

Для уменьшения размера файла журнала необходимо предварительно удалить неактивные записи журнала транзакций с помощью команды BACKUP LOG ,а затем уже с помощью команды DBCC SHRINKFILE уменьшить размер файла журнала транзакций.Последовательность команд, которую нужно исполнить в Query Analyzer , выглядит следующим образом:

BACKUP LOG Имя_Базы_Данных WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Имя_Файла_Журнала_Транзакций )

3.4 Перемещение базы данных TEMPDB на другой диск большего размера.

TEMPDB представляет собой системную базу данных Microsoft SQL Server, в которой хранятся временные таблицы, созданные как самим сервером, так и пользователями. Эта база данных создается заново при каждом перезапуске Microsoft SQL Server. По умолчанию размер этой базы данных неограничен и увеличение его осуществляется при необходимости автоматически, порциями по 10% от текущего размера TEMPDB. Однако эти параметры могут быть переопределены пользователем. По умолчанию, минимальный размер этой базы данных, который устанавливается при старте Microsoft SQL Server, определяется размером системной базы данных MODEL. Очистка журнала транзакций в этой базе данных производится автоматически, при этом удаляются только неактивные записи журнала транзакций.

При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используетсяMicrosoft SQL Server при выполнении запросов, использующих операторы GROUP BY , UNION , DISTINCT и т.п.

В процессе работы 1С:Предприятия 8 возможно значительное увеличение размера базы данных TEMPDB. Если размер диска, на котором расположена база данных TEMPDB, окажется недостаточным, работа 1С:Предприятия 8 может завершиться аварийно.

Если эта проблема проявляется регулярно, то рекомендуется переместить TEMPDB на другой диск большего размера.

Эту операцию можно выполнить следующим способом:

1. определить логические имена файлов базы данных TEMPDB (колонка “NAME” результата выполнения процедуры). Для этого нужно в Query Analyzer выполнить следующую команду:

USE tempdb GO EXEC sp_helpfile GO 2.изменить месторасположение файлов базы данных TEMPDB с помощью команды ALTER DATABASE . Для этого нужно в Query Analyzerвыполнить следующую последовательность команд: USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev , FILENAME = "Новый_Диск:\Новый_Каталог\tempdb.mdf" ) GO ALTER DATABASE tempdb MODIFY FILE (NAME = templog , FILENAME = "Новый_Диск:\Новый_Каталог\templog.ldf" ) GO 3. Перезапустить Microsoft SQL Server.

4. Оптимизация кода и алгоритмов в 1С

4.1 Оптимизация запросов

Значительная часть проблем, приводящих к неоптимальной работе запросов, может быть обнаружена путем анализа кода конфигурации и структуры метаданных. Имеется перечень типичных ошибок в коде и структуре данных, последствия которых достаточно хорошо изучены и легко предсказуемы. Анализ кода с использованием этого перечня позволяет решить большую часть проблем с производительностью запросов, не углубляясь в детальную техническую информацию (текст запроса на языке SQL, план запроса и т.д.).

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

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

4.2 Использование замера производительности

1С:Предприятие 8 позволяет отлаживать и измерять производительность для кода на встроенном языке, исполняемом как на клиенте, так и на сервере. Особенностью работы замера производительности для клиент-серверной информационной базы в 1С:Предприятии 8 является то, что результаты замера производительности объединяются в один файл. Они включают в себя данные о ходе исполнения кода на встроенном языке как на клиенте, так и на сервере. Для получения такого замера достаточно запустить сервер 1С:Предприятия 8 в отладочном режиме (с помощью ключа командной строки /debug )и в Конфигураторе в нужный момент просто включить режим замера производительности.

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

Более подробнее об использования замера производительности можно посмотреть на диске ИТС .

Перед началом работ по оптимизации системы необходимо всегда получать начальную оценку производительности при помощи “Оценки интегральной производительности системы по методике APDEX” .

4.3 Инструменты рефакторинга кода

Функции рефакторинга кода, реализованные в конфигураторе платформы 8.3.5, 1068. а также функции автоматического преобразования модальных методов и участков кода показаны на рис 1.

Рис 1 Инструменты рефакторинга кода в конфигураторе

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

ТАК ЧТО ЖЕ ИЗМЕНИЛОСЬ В КЛАСТЕРЕ 1С 8.3:

Первым делом, после установки кластера 1С ранее нужно было создать рабочие процессы. Как оказалось, процессы кластера начали создаватся автоматически в зависимости от нагрузки базы.

Пробный запуск фоновых заданий основной базы заставило кластер 1С безконечно перегружать rphost.exe и дополнительный rphost.exe никак не хотел создаватся. Покопавшись в настройках все стало понятно.

Максимальный объем памяти рабочих процессов - это объем памяти, который могут использовать рабочие процессы вместе. Нужно быть очень внимательными при установке параметра, измеряется в байтах . Если установить неверное значение (недостаточное для нормальной работы пользователей) пользователям будет выдана ошибка " Недостаточно свободной памяти на сервере 1С ". Так же эту ошибку можно получить, когда на сервере 1С закончилась квота по памяти.

Безопасный расход памяти за один вызов - позволяет контролировать расход памяти при серверном вызове, измеряется в байтах . Если вызов использует больше памяти чем положено, этот вызов будет завершен в рамках кластера 1С без перезапуска рабочего процесса (rphost.exe). Соответственно "неудачник", который выполнил вызов сервера, утратит сеанс с базой 1С без влияния на работу других пользователей.

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

Количество ИБ на процесс - позволяет изолировать информационные базы по рабочим процессам. По умолчанию у текущего кластера 1С было установлено значение - "8", но на протяжении нескольких часов работы сервер себя очень нестабильно, сеансы пользователей зависали. После изоляции каждой информационной базы (значение - "1") проблемы пропали.

Количество соединений на процесс - по умолчанию значение "128". Так как у текущей базы очень большая нагрузка фоновыми заданиями (расчет логистики, анализ прайсов, анализ конкурентов и прочее) было принято решение уменьшить количество до "25".

Немного изменились настройки и самого кластера 1С:

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

Режим распределения нагрузки - есть два варианта параметра: "Приоритет по производительности" - памяти сервера тратится больше и производительность выше, "Приоритет по памяти" - кластер 1С экономит память сервера.

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

Первым делом, после установки кластера 1С ранее нужно было создать рабочие процессы. Как оказалось, процессы кластера начали создаваться автоматически в зависимости от нагрузки базы.

Пробный запуск фоновых заданий основной базы заставило кластер 1С бесконечно перегружать rphost.exe и дополнительный rphost.exe никак не хотел создаваться. Покопавшись в настройках все стало понятно.

Максимальный объем памяти рабочих процессов – это объем памяти, который могут использовать рабочие процессы вместе. Нужно быть очень внимательными при установке параметра, измеряется в байтах. Если установить неверное значение (недостаточное для нормальной работы пользователей) пользователям будет выдана ошибка “Недостаточно свободной памяти на сервере 1С”. Так же эту ошибку можно получить, когда на сервере 1С закончилась квота по памяти.

Безопасный расход памяти за один вызов – позволяет контролировать расход памяти при серверном вызове, измеряется в байтах. Если вызов использует больше памяти чем положено, этот вызов будет завершен в рамках кластера 1С без перезапуска рабочего процесса (rphost.exe). Соответственно “неудачник”, который выполнил вызов сервера, утратит сеанс с базой 1С без влияния на работу других пользователей.

в одном ГБ – 1073741824 Байт, следовательно в 2 ГБ – 2147483648 Байта

Объем памяти рабочих процессов, до которого сервер считается производительным – при превышении этого параметра сервер в кластере 1С перестанет принимать новые соединения.

Количество ИБ на процесс – позволяет изолировать информационные базы по рабочим процессам. По умолчанию у текущего кластера 1С было установлено значение – “8 “, но на протяжении нескольких часов работы сервер себя очень нестабильно, сеансы пользователей зависали. После изоляции каждой информационной базы (значение – “1”) проблемы пропали.

Количество соединений на процесс – по умолчанию значение “128 “. Так как у текущей базы очень большая нагрузка фоновыми заданиями (расчет логистики, анализ прайсов, анализ конкурентов и прочее) было принято решение уменьшить количество до “25”.

Немного изменились настройки и самого кластера 1С:

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

Режим распределения нагрузки – есть два варианта параметра: “Приоритет по производительности” – памяти сервера тратится больше и производительность выше, “Приоритет по памяти” – кластер 1С экономит память сервера.

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

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

Это снижает вероятность неправильной настройки сервера и понижает требования к квалификации админов.

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

Стабильность работы при использовании больших объемов памяти определятся новыми параметрами рабочего сервера.

Особенно интересен параметр «безопасный расход памяти за один вызов». Для тех кто плохо представляет что это такое – лучше не тренируйтесь на «продуктивной» базе. Параметр «Максимальный объем памяти рабочих процессов» позволяет при «переполнении» не обваливать весь рабочий процесс, а только один сеанс «с неудачником». «Объем памяти рабочих процессов, до которого сервер считается производительным» позволяет заблокировать новые соединения как только будет преодолен этот порог памяти.

Рекомендую изолировать рабочие процессы по информационным базам, к примеру указать параметр «Количество ИБ на процесс = 1″. При нескольких высоконагруженных базах это позволит уменьшить взаимное влияние как по надежности, так и по производительности.

Отдельный вклад в стабильность системы вносит «расходование» лицензий/ключей. В 8.3 появилась возможность использования «менеджера программных лицензий» напоминая менеджер «аладина». Цель – возможность вынести ключ на отдельную машину.

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

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

Требования назначенной функциональности 1с

Так на ноутбуке с ключом защиты чтобы не запускать пользователей на сервер кластера надо добавить «требования» для объекта требования «Клиентское соединение с ИБ» – «Не назначать», т.е. запретить рабочим процессам данного сервера обрабатывать клиентские соединения.

Еще больший интерес предоставляет возможность запускать «только фоновые задания» на рабочем сервере кластера без сеансов пользователей. Таким образом можно высоконагруженные задачи (код) вынести на отдельный машины. При чем можно одно фоновое задание «закрытия месяца» через «Значение дополнительного параметра» запускать на одном компьютере, а фоновое задание «Обновление полнотекстового индекса» на другом.Уточнение происходит через указание «Значение дополнительного параметра». Например если указать BackgroundJob.CommonModule в качестве значения, то можно ограничить работу рабочего сервера в кластере только фоновыми заданиями с любым содержимым. Значение BackgroundJob.CommonModule.<Имя модуля>.<Имя метода> – укажет конкретный код.

Зачастую на машине вместе с сервером 1С:Предприятие работают другие службы — терминальный сервер, SQL-сервер и т.д. И в какой-то момент сервер 1С:Предприятие, а точнее рабочий процесс rphost отъедает памяти больше чем планировалось или же всю память. Что приводит к замедлению работы других служб и зомбированию сервера. Для избежания таких ситуаций необходимо настроить автоматический перезапуск рабочих процессов сервера 1С:Предприятия

Решение

1. Откроем консоль администрирования серверов 1С Предприятия;
2. Развернем дерево центрального сервера до кластеров и выделим интересующий наc кластер. В примере кластер всего один;
3. Откроем свойства выделенного кластера и увидим следующую форму

Свойства кластера сервера 1С:Предприятие 8.3

Разберем пример указанный на изображении:

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

Допустимый объем памяти — объем памяти, в пределах которого рабочий процесс может без проблемно работать. Объем указывается в килобайтах, в примере указана величина в 20 гигабайт(на самом деле цифра слишком большая и отталкиваться необходимо от конкретной системы, но средняя цифра 4 Гб). Как только память занятая рабочим процессом превысит указанную величину, так начинается отсчет времени.

Интервал превышения допустимого объема памяти — после того как таймер запущенный после превышения допустимого объема памяти отсчитает указанное время, будет запущен новый рабочий процесс, на который передаются все соединения, старый процесс помечается как выключенный. Интервал указывается в секундах, в примере указаны 30 секунд.

Выключенные процессы останавливать через — время, через которое будет остановлен рабочий процесс, помеченный как выключенный, если указано значение 0, то процесс не будет завершен. Интервал указывается в секундах, в примере указаны 60 секунд.

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

Итого

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

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

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

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

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

Стабильность работы при использовании больших объемов памяти определятся новыми параметрами рабочего сервера.

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

Рекомендую изолировать рабочие процессы по информационным базам, к примеру указать параметр «Количество ИБ на процесс = 1″. При нескольких высоконагруженных базах это позволит уменьшить взаимное влияние как по надежности, так и по производительности.

Отдельный вклад в стабильность системы вносит «расходование» лицензий/ключей. В 8.3 появилась возможность использования «менеджера программных лицензий» напоминая менеджер «аладина». Цель — возможность вынести ключ на отдельную машину.

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

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

Так на ноутбуке с ключом защиты чтобы не запускать пользователей на сервер кластера надо добавить «требования» для объекта требования «Клиентское соединение с ИБ» — «Не назначать», т.е. запретить рабочим процессам данного сервера обрабатывать клиентские соединения.

Еще больший интерес предоставляет возможность запускать «только фоновые задания» на рабочем сервере кластера без сеансов пользователей. Таким образом можно высоконагруженные задачи (код) вынести на отдельный машины. При чем можно одно фоновое задание «закрытия месяца» через «Значение дополнительного параметра» запускать на одном компьютере, а фоновое задание «Обновление полнотекстового индекса» на другом.Уточнение происходит через указание "Значение дополнительного параметра". Например если указать BackgroundJob.CommonModule в качестве значения, то можно ограничить работу рабочего сервера в кластере только фоновыми заданиями с любым содержимым. Значение BackgroundJob.CommonModule..- укажет конкретный код.

Понятное дело, что нет смысла пересказывать документацию. Но если кто то посоветует дельное, расширю статью.