Effector saver - это специализированная программа для автоматического резервного копирования 1С:Предприятия.Программа позволяет создавать резервные копии баз данных 1С:Предприятия, баз Microsoft SQL или PostgreSQL серверов, пользовательских папок и файлов.Сохранять же резервные копии можно на внешние, сетевые и локальные диски, FTP сервер.Effector saver вмещает большое количество расширенных функций, которые значительно упрощают резервное копирование: планирование и автоматический запуск задач, удобное заполнение настроек и тестирование баз 1С, автоотключение пользователей 1С:Предприятия 8.

Наша цель - создание ежедневных архивов. На компьютере где производится настройка, должна быть установлена программа 1С:Предприятие и подключена необходимая база данных.Скачаем программу с официального сайта https://efsaver.ru/download.htmlЗапускаем файл инсталляции Мастера установки.

На последнем этапе Мастера установки, соглашаемся с запуском программы и нажимаем "Завершить".

Настроим параметры автозапуска "Агента". Для этого в Панели инструментов выбераем "Сервис" & "Параметры программы" & "Параметры запуска".

Выбираем "Запускать агент как приложение" (выбор зависит от установки программы на рабочую станцию или на сервер).  

Нажимаем кнопку "Запустить агента" - "Сохранить".

Создаем задачу резервного копирования

Выбираем "Задачи" - "Добавить задачу".

Выбираем чем архивироватьПоле "Наименование" оставим по умолчанию, оно автоматически изменится на имя выбранной базы 1С.

Из выпадающего списка "Вид задачи" выбираем "Архивирование средствами 1С:Предприятие 8".

Указываем базу для архивацииВ закладке "Подключение" нажимаем "Выбрать и заполнить". В открывшемся окне "Выбор базы 1С:Предприятия" указываем нужную нам базу и нажимаем "Выбрать".

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

Заполняем имя и пароль пользователя выбранной базы, под которым будет запускаться резервное копирование средствами конфигуратора 1С:Предприятия.У этого пользователя в базе должны быть соответствующие права. Обратите внимание, имя задачи автоматически изменилось на имя выбранной базы.

Если для защиты 1С используется USB ключ, то не нужно устанавливать флаг "Использовать программную лицензию 1С".

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

В параметре "Количество одновременно хранимых архивов" установим 10. Effector saver будет удалять более старые резервные копии данной задачи, как только их количество превысит 10 штук.

Выбираем когда производить архивированиеЧтобы установить время выполнения задачи, переходим на вкладку "Расписание".

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

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

В поле "Время начала" установите произвольное время в формате "чч:мм" в тот период, когда последний пользователь прекращает работу с базой и до момента начала работы первого пользователя. Например ночь, 01:00.

Активация и сохранение настройки задачиУстанавливаем флаг "Выполнять задачу" в верхней части окна настройки.

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

Удостоверьтесь, что пользователи вышли из базы 1С:Предприятия.

В главном окне "Менеджера" кликнув мышкой делаем активной строку со своей задачей.

Всё, готово. Резервная копия успешно создана.

Просмотр результатов работы задачиПосле завершения процесса резервного копирования во вкладке "Журнал" мы увидим дату и результат выполнения задачи по созданию бэкапа.

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

Во вкладке "Файлы" можно просмотреть список файлов бэкапа, которые были созданы в результате выполнения задачи.

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

По умолчанию PostgreSQL настроен таким образом, чтобы расходовать минимальное количество ресурсов для работы с небольшими базами до 4 Gb на не очень производительных серверах. То есть, если дело касается систем посерьезней, то вы столкнетесь с большими потерями производительности базы данных лишь потому, что дефолтные настройки могут в корне не соответствовать производительности вашего северного оборудования. Настройки выделения ресурсов оперативной памяти RAM для работы PostgreSQL хранятся в файле postgresql.conf.

Доступен как из папки, куда установлен PostgreSQL / Data, так и из pgAdmin:

В общем на начальном этапе при возникновении трудностей и замедления работы БД, заметной для глаз пользователей достаточно увеличить три параметра:

shared_buffers

Это размер памяти, разделяемой между процессами PostgreSQL, отвечающими за выполнения активных операций. Максимально-допустимое значение этого параметра – 25% всего количества RAM

Например, при 1-2 Gb RAM на сервере, достаточно указать в этом параметре значение 64-128 Mb (8192-16384).

temp_buffers

Это размер буфера под временные объекты (временные таблицы). Среднее значение 2-4% всего количества RAM

Например, при 1-2 Gb RAM на сервере, достаточно указать в этом параметре значение 32-64 Mb.

work_mem

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

При 1-2 Gb RAM на сервере, рекомендуемое значение 32-64 Mb.

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

Еще два важных параметра это maintenance_work_mem (для операций VACUUM, CREATE INDEX и других) и max_stack_depth

Примеры оптимальных настроек:

Hardware:

• CPU: E3-1240 v3 @ 3.40GHz
• RAM: 32Gb 1600Mhz
• Диски: Plextor M6Pro

postgresql.conf:

• shared_buffers = 8GB
• work_mem = 128MB
• maintenance_work_mem = 2GB
• fsync = on
• synchronous_commit = off
• wal_sync_method = fdatasync
• checkpoint_segments = 64
• seq_page_cost = 1.0
• random_page_cost = 6.0
• cpu_tuple_cost = 0.01
• cpu_index_tuple_cost = 0.0005
• cpu_operator_cost = 0.0025
• effective_cache_size = 24GB

Вариант настроек от pgtune:

Полезные запросы:

Блокировки БД по пользователям

 select a.usename, count(l.pid) from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid where not(mode = ‘AccessShareLock’) group by a.usename;   

Вывести все таблицы, размером больше 10 Мб

 SELECT tableName, pg_size_pretty(pg_total_relation_size(CAST(tablename as text))) as size

from pg_tables

where tableName not like ‘sql_%’ and pg_size_pretty(pg_total_relation_size(CAST(tablename as text))) like ‘%MB%’;   

Определение размеров таблиц в базе данных PostgreSQL

 SELECT tableName, pg_size_pretty(pg_total_relation_size(CAST(tablename as text))) as size

from pg_tables

where tableName not like ‘sql_%’

order by size;   

Пользователи блокирующие конкретную таблицу

 select a.usename, t.relname, a.current_query, mode from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid inner join pg_stat_all_tables t on t.relid=l.relation where t.relname = ‘tablename’;   

 select relation::regclass, mode, a.usename, granted, pid from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid where not mode = ‘AccessShareLock’ and relation is not null;   

Запросы с эксклюзивными блокировками

 select a.usename, a.current_query, mode from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid where mode ilike ‘%exclusive%’;   

Количество блокировок по пользователям

 select a.usename, count(l.pid) from pg_locks l inner join pg_stat_activity a on a.procpid = l.pid where not(mode = ‘AccessShareLock’) group by a.usename;   

Количество подключений по пользователям

 select count(usename), usename from pg_stat_activity group by usename order by count(usename) desc;   

При попытке удалить запись из регистра сведений - получаю ошибку: она заблокирована, ошибка блокировок и т.д.

Отключил всех пользователей, перезапустил сервер, пробую удалить - опять ошибка блокировки

Путем тестов было вяснено, что проблема не в коде, а происходит это на этапе обращения платформы к SQL серверу... после долгих поисков решений, в интернете была найдена статья, которая помогла в решении данной проблемы:

Кто что блокирует, MS SQL + 1C

В повседневной работе достаточно задействовать только первый блок "/*кто кого*/". Открываем MS SQL Server Management Studio, правой на корень - "new query" - вставляем код запроса (только верхнюю часть до "Кто что блокирует", остальное - для детального анализа), выполняем запрос (вверху есть кнопочка выполнения запроса).

Выполнив запрос, запоминаем "ID виновника", быстренько идем в консоль сервера 1С, заходим в ветку "Сеансы" нашей базы. Видим все соединения с 1С-сервером, ищем там колонку "Соединение с СУБД", чтобы увидеть соединения 1С-сервера с MSSQL-сервером. В колонке будет всего несколько заполненных значений, среди них и будет "ID виновника".

Что делать если его там нет, тут 3 варианта:

1. Вернитесь в MSSQL и сделайте запрос еще несколько раз подряд, если значения меняются или таблица вообще пуста - постоянной блокировки нет, у вас (уже) все в порядке.

2. Сеанс который блокирует MSSQL находится в другой базе т.е. блокировка не в той базе (можно попробовать задействовать ветку всех сеансов в консоли 1С-сервера) - вернитесь в MSSQL и внимательно посмотрите в колонку DB в ней находится название базы.

3. Бывает что ID процесса в 1С-консоли вообще отсутствует, такое тоже бывает если у вас есть какие-то внешние программы подключенные напрямую в базу 1С, если пускаете кого-то в MSSQL напрямую, то вариант не исключен.

Код SQL-запроса:

 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED





DECLARE @dbid AS smallint;

use [ВАШАБАЗА];

SET @dbid=DB_ID();





/*кто кого*/

SELECT DB_NAME(pr1.dbid) AS 'DB'

      ,pr1.spid AS 'ID жертвы'

      ,RTRIM(pr1.loginame) AS 'Login жертвы'

      ,pr2.spid AS 'ID виновника'

      ,RTRIM(pr2.loginame) AS 'Login виновника'

      ,pr1.program_name AS 'программа жертвы'

      ,pr2.program_name AS 'программа виновника'

      ,txt.[text] AS 'Запрос виновника'

FROM   MASTER.dbo.sysprocesses pr1(NOLOCK)

       JOIN MASTER.dbo.sysprocesses pr2(NOLOCK)

            ON  (pr2.spid = pr1.blocked)

       OUTER APPLY sys.[dm_exec_sql_text](pr2.[sql_handle]) AS txt

WHERE  pr1.blocked <> 0





/* Кто что блокирует */

SELECT s.[nt_username]

      ,request_session_id

      ,tran_locks.[request_status]

      ,rd.[Description] + ' (' + tran_locks.resource_type + ' ' + tran_locks.request_mode + ')' [Object]

      ,txt_blocked.[text]

      ,COUNT(*) [COUNT]

FROM   sys.dm_tran_locks AS tran_locks WITH (NOLOCK)

       JOIN sys.sysprocesses AS s WITH (NOLOCK)

            ON  tran_locks.request_session_id = s.[spid]

       JOIN (

                SELECT 'KEY' AS sResource_type

                      ,p.[hobt_id] AS [id]

                      ,QUOTENAME(o.name) + '.' + QUOTENAME(i.name) AS [Description]

                FROM   sys.partitions p

                       JOIN sys.objects o

                            ON  p.object_id = o.object_id

                       JOIN sys.indexes i

                            ON  p.object_id = i.object_id

                            AND p.index_id = i.index_id

                UNION ALL

                SELECT 'RID' AS sResource_type

                      ,p.[hobt_id] AS [id]

                      ,QUOTENAME(o.name) + '.' + QUOTENAME(i.name) AS [Description]

                FROM   sys.partitions p

                       JOIN sys.objects o

                            ON  p.object_id = o.object_id

                       JOIN sys.indexes i

                            ON  p.object_id = i.object_id

                            AND p.index_id = i.index_id

                UNION ALL

                SELECT 'PAGE'

                      ,p.[hobt_id]

                      ,QUOTENAME(o.name) + '.' + QUOTENAME(i.name)

                FROM   sys.partitions p

                       JOIN sys.objects o

                            ON  p.object_id = o.object_id

                       JOIN sys.indexes i

                            ON  p.object_id = i.object_id

                            AND p.index_id = i.index_id

               

                UNION ALL

                SELECT 'OBJECT'

                      ,o.[object_id]

                      ,QUOTENAME(o.name)

                FROM   sys.objects o

            ) AS RD

            ON  RD.[sResource_type] = tran_locks.resource_type

            AND RD.[id] = tran_locks.resource_associated_entity_id

       OUTER APPLY sys.[dm_exec_sql_text](s.[sql_handle]) AS txt_Blocked

WHERE  (

           tran_locks.request_mode = 'X'

           AND tran_locks.resource_type = 'OBJECT'

       )

       OR  tran_locks.[request_status] = 'WAIT'

GROUP BY

       s.[nt_username]

      ,request_session_id

      ,tran_locks.[request_status]

      ,rd.[Description] + ' (' + tran_locks.resource_type + ' ' + tran_locks.request_mode + ')'

      ,txt_blocked.[text]

ORDER BY

       6 DESC

       





IF EXISTS ( SELECT  Name





            FROM    tempdb..sysobjects





            WHERE   name LIKE '#LOCK_01_01%' )

    DROP TABLE #LOCK_01_01









CREATE TABLE #LOCK_01_01





    (





      spid INT,





      dbid INT,





      ObjId INT,





      IndId SMALLINT,





      Type VARCHAR(20),





      Resource VARCHAR(50),





      Mode VARCHAR(20),





      Status VARCHAR(20)





    )





INSERT  INTO #LOCK_01_01





EXEC sp_lock









select OBJECT_NAME(ObjId) as [Имя объекта], Mode [Тип блокировки (код)],





CASE

     WHEN Mode='Sch-S' THEN 'Блокировка стабильности схемы. Гарантирует, что элемент схемы, такой как таблица или индекс, не будет удален до тех пор, пока сеанс связи удерживает блокировку стабильности схемы на данный элемент схемы;'





 WHEN Mode='Sch-М' THEN '= Блокировка изменения схемы. Должен поддерживаться любым сеансом связи, во время которого предполагается изменить схему данного ресурса. Гарантирует, что другие сеансы не имеют ссылок на обозначенный объект;'





 WHEN Mode='S' THEN 'S = Коллективная блокировка. Удерживающему сеансу предоставлен коллективный доступ к ресурсу;'





 WHEN Mode='U' THEN 'U = Блокировка обновления. Указывает блокировку обновления, полученную на ресурсы, которые со временем могут быть обновлены. Используется для предотвращения общей формы взаимоблокировки, которая возникает, когда множество сеансов блокируют ресурсы для потенциального обновления в последующее время;'





 WHEN Mode='X' THEN 'X = Монопольная блокировка. Удерживающему сеансу предоставлен исключительный доступ к ресурсу;'





 WHEN Mode='IS' THEN 'IS = Блокировка с намерением коллективного доступа. Указывает намерение поместить S блокировки на некоторые подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='IU' THEN 'IU = Блокировка с намерением обновления. Указывает намерение поместить U блокировки на некоторые подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='IX' THEN 'IX = Блокировка с намерением монопольного доступа. Указывает намерение поместить X блокировки на некоторые подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='SIU' THEN 'SIU = Коллективная блокировка с намерением обновления. Указывает коллективный доступ к ресурсу с намерением получения блокировок обновления на подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='SIX' THEN 'SIX = Коллективная блокировка с намерением монопольного доступа. Указывает коллективный доступ к ресурсу с намерением получения монопольных блокировок на подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='UIX' THEN 'UIX = Блокировка обновления с намерением монопольного доступа. Указывает блокировку обновления ресурса с намерением получения монопольных блокировок на подчиненные ресурсы в иерархии блокировок;'





 WHEN Mode='BU' THEN 'BU = Блокировка массового обновления. Используется для массовых операций;'

     --[ ELSE else_result_expression ]

END as [Тип блокировки]





,syspr.spid, syspr.dbid, syspr.open_tran, syspr.status, syspr.hostprocess, syspr.loginame, syspr.hostname





 From

#LOCK_01_01





inner join master.dbo.sysprocesses as syspr

on syspr.spid = #LOCK_01_01.spid and syspr.dbid = #LOCK_01_01.dbid





where

#LOCK_01_01.Type = 'TAB'

and

#LOCK_01_01.dbid = @dbid     





/* Чем занят сервер*/

SELECT s.[spid]

      ,s.[loginame]

      ,s.[open_tran]

      ,s.[blocked]

      ,s.[waittime]

      ,s.[cpu]

      ,s.[physical_io]

      ,s.[memusage]

       INTO #sysprocesses

FROM   sys.[sysprocesses] s





WAITFOR DELAY '00:00:01'





SELECT txt.[text]

      ,s.[spid]

      ,s.[loginame]

      ,s.[hostname]

      ,DB_NAME(s.[dbid]) [db_name]

      ,SUM(s.[waittime] -ts.[waittime]) [waittime]

      ,SUM(s.[cpu] -ts.[cpu]) [cpu]

      ,SUM(s.[physical_io] -ts.[physical_io]) [physical_io]

      ,s.[program_name]

FROM   sys.[sysprocesses] s

       JOIN #sysprocesses ts

            ON  s.[spid] = ts.[spid]

            AND s.[loginame] = ts.[loginame]

       OUTER APPLY sys.[dm_exec_sql_text](s.[sql_handle]) AS txt

WHERE  s.[cpu] -ts.[cpu]

       + s.[physical_io] -ts.[physical_io]

       > 500

       OR  (s.[waittime] -ts.[waittime]) > 3000

GROUP BY

       txt.[text]

      ,s.[spid]

      ,s.[loginame]

      ,s.[hostname]

      ,DB_NAME(s.[dbid])

      ,s.[program_name]

ORDER BY

       [physical_io] DESC

       

DROP TABLE #sysprocesses

   

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

Недавно я разместил статью: Чтение данных с сайта в формате XML и загрузка в 1С пришло время это автоматизировать:

Регламентные и фоновые задания

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

Механизм заданий решает следующие задачи:

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

Механизм заданий состоит из следующих компонентов:

• Метаданных регламентных заданий;
• Регламентных заданий;
• Фоновых заданий;
• Планировщика заданий.

Фоновые задания & предназначены для выполнения прикладных задач асинхронно. Фоновые задания реализуются средствами встроенного языка.

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

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

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

С описанием, думаю, хватит - приступим к реализации:

Создание регламентного задания

Имя метода – путь к процедуре, которая будет выполняться в фоновом задании по заданному расписанию. Процедура должна находиться в общем модуле. Рекомендуется не использовать типовые общие модули, а создать свой. Не забудьте, что фоновые задания исполняются на сервере!

Использование – признак использования регламентного задания.

Предопределенное – указывает, является ли регламентное задание предопределенным.

Если хотите что бы регламентное задание заработало сразу после помещения в БД, укажите признак Предопределенное. В противном случае вам необходимо будет использовать обработку “Консоль заданий” или вызывать запуск задания программно.

Количество повторов при аварийном завершении задания – сколько раз выполнен перезапуск фонового задания, если оно было выполнено с ошибкой.

Интервал повтора при аварийном завершении задания – с какой периодичностью будет выполнен перезапуск фонового задания, если оно было выполнено с ошибкой.

Настройка расписания

Расписание выполнения задания:

Особенности выполнения фоновых заданий файловом и клиент-серверном вариантах

Механизмы выполнения фоновых заданий в файловом и клиент-серверном вариантах различаются.

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

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

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

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

• На информационную базу установлена явная блокировка регламентных заданий. Блокировка может быть установлена через консоль кластера;
• На информационную базу установлена блокировка соединения. Блокировка может быть установлена через консоль кластера;
• Из встроенного языка вызван метод УстановитьМонопольныйРежим() с параметром Истина;
• В некоторых других случаях (например, при обновлении конфигурации базы данных).

Обработки запуска и просмотра регламентных заданий вы можете скачать здесь:

Для 8.2 Обычные формы: Konsol82.rar 

Для 8.3 Управляемые формы: KonsolZadaniy83.rar 

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

Код позволяющий создать документ копированием:

 Процедура ДействияФормыДобавитьКопированием(Кнопка)

	колдок = 5;

	Если ВвестиЧисло(колдок,"Сколько создать?") Тогда

		Для н=1 по колдок Цикл 

			// Копирование документа

			ДокументКопия = ЭтаФорма.ЭлементыФормы.Список.ТекущаяСтрока.Скопировать();  

			ДокументКопия.Дата = РабочаяДата;	                                        

			ДокументКопия.Записать();

		КонецЦикла;

	КонецЕсли;	

КонецПроцедуры   

Я уже писал несколько статей:

Настройка и оптимизация сервера, кластера 8.3

Добавление, перезапуск, оптимизация рабочих процессов сервера кластера

теперь немного подробнее:

Кластер 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С 8.2

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

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

Отказоустойчивость сервера 8.2 достигается за счет:

• Хранение информации о сеансе работы пользователя.
• Пользователь не привязан больше к рабочему процессу.
• Резервирование рабочих процессов в кластере.
• Должно быть несколько рабочих процессов, в том числе резервируемые
• Резервирование кластеров.

Указывается запасной кластер, при подключении - перечисляются в строке соединения

Это позволяет обеспечить непрерывность работы!

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

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

При выходе из строя любого сервера кластера работа пользователей не остановится она будет автоматически переведена на резервный кластер и/или на резервные рабочие процессы. Для пользователей такой переход будет незаметным.

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

В прошлой статье: Установка адресного классификатора (KLADR) в 1С я рассказал Вам что такое Кладр и как его загрузить в 1С обычные формы (8.0-8.2).

В данной статье я расскажу как загрузить Адресный классификатор (KLADR) в управляемом интерфейсе или интерфейсе Такси:

Такси

Рассмотрим загрузку адресного классификатора на примере информационной базы конфигурации Бухгалтерия предприятие 3.0 в режиме Такси.

Для загрузки адресного классификатора необходимо войти в Вашу базу в режиме 1С Предприятие.

Далее необходимо в разделе "Справочники" открыть Настройка навигации и добавить Адресный классификатор в Обычное

В результате в меню появится Предприятие - Адресный классификатор, заходим в него

Откроется окно в котором можно выбрать Проверить обновление или Загрузить

Выберем Проверить обновление и программа через интернет проверит актуальность адресного классификатора и предложит обновить

Если выбрать Загрузить, то откроется окно - В котором нужно отметить необходимые к загрузке регионы и указать источник загрузки (щелкните на синюю надпись внизу)

Выберите источник загрузки

Загрузим из каталога на диске - укажите каталог с файлами kladr и нажмите Загрузить

По завершении загрузки вы уведите соответствующее сообщение!

Все

Управляемое Приложение

Так же рассмотрим загрузку адресного классификатора на примере информационной базы конфигурации Бухгалтерия предприятие 3.0.

Для загрузки адресного классификатора необходимо войти в Вашу базу в режиме 1С Предприятие.

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

Здесь в левой части окна необходимо выбрать «Адресный классификатор».

В открывшемся окне можно как и в примере выше нажать кнопку «Проверить» и программа сама обновит из интернета, но мы сделаем через нажать на кнопку «Загрузить»

Далее необходимо отметить галочками необходимые регионы, для которых Вам нужно загрузить адресный классификатор. Нажимаем «Далее».

В следующем окне отмечаем пункт «У меня есть файлы адресного классификатора» и нажимаем на кнопку «…» для указания пути к файлам КЛАДР.

Укажите путь к каталогу KLADR, у меня, например, это D:\TEMP\KLADR и нажмите Далее

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

По окончании процесса загрузки появится окно с сообщением.

Нажимаем «ОК» и закрываем следующее окно. Адресный классификатор успешно загружен!

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

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

Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan. Существуют так же другие способы автоматизации выполнения этих процедур. В настоящей статье для каждой регламентной процедуры дан пример ее настройки при помощи Maintenance Plan для MS SQL Server 2005.

Для MS SQL Server рекомендуется выполнять следующие регламентные операции:

Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур.

Обновление статистик

MS SQL Server строит план запроса на основании статистической информации о распределении значений в индексах и таблицах. Статистическая информация собирается на основании части (образца) данных и автоматически обновляется при изменении этих данных. Иногда этого оказывается недостаточно для того, что MS SQL Server стабильно строил наиболее оптимальный план выполнения всех запросов.

В этом случае возможно проявление проблем с производительностью запросов. При этом в планах запросов наблюдаются характерные признаки неоптимальной работы (неоптимальные операции).

Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.

Для обновления статистик по всем таблицам базы данных необходимо выполнить следующий SQL запрос:

 exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'   

Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.

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

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

Настройка автоматического обновления статистик (MS SQL 2005)

Запустите MS SQL Server Management Studio и подключитесь к серверу СУБД. Откройте папку Management и создайте новый план обслуживания:

Создайте субплан (Add Sublan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач:

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

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

Обновление статистик необходимо проводить с включенной опцией Full Scan.

Сохраните созданный план. При наступлении указанного в расписании срока обновление статистик будет запущено автоматически.

Очистка процедурного КЭШа

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

Возможна ситуация, при которой MS SQL Server, ориентируясь на устаревшую статистическую информацию, построит неоптимальный план запроса. Этот план будет сохранен в процедурном КЭШе и использован при повторном вызове такого же запроса. Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план.

Таким образом, рекомендуется всегда после обновления статистик очищать содержимое процедурного КЭШа.

Для очистки процедурного КЭШа MS SQL Server необходимо выполнить следующий SQL запрос:

 DBCC FREEPROCCACHE   

Этот запрос следует выполнять непосредственно после обновления статистики. Соответственно, частота его выполнения должна совпадать с частотой обновления статистики.

 Настройка очистки процедурного КЭШа

для (MS SQL 2005)

Поскольку процедурный КЭШ необходимо очищать при каждом обновлении статистики, данную операцию рекомендуется добавить в уже созданный субплан «Обновление статистик». Для этого следует открыть субплан и добавить в его схему задачу Execute T-SQL Statement Task. Затем следует соединить задачу Update Statistics Task стрелочкой с новой задачей.

В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»:

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

При интенсивной работе с таблицами базы данных возникает эффект фрагментации индексов, который может привести к снижению эффективности работы запросов.

Рекомендуется регулярное выполнение дефрагментации индексов. Для дефрагментации всех индексов всех таблиц базы данных необходимо использовать следующий SQL запрос (предварительно подставив имя базы):

 sp_msforeachtable N'DBCC INDEXDEFRAG (<имя базы данных>, ''?'')'   

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

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

Настройка дефрагментации индексов (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов». Добавьте в него задачу Reorganize Index Task:

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

Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.

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

 sp_msforeachtable N'DBCC DBREINDEX (''?'')'   

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

После выполнения реиндексации нет необходимости делать дефрагментацию индексов.

В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов». Добавьте в него задачу Rebuild Index Task:

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

Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.

Реиндексация таблиц базы данных

Необходимо осуществлять регулярный контроль выполнения регламентных процедур на уровне СУБД. Ниже приведен пример контроля выполнения плана обслуживания для MS SQL Server 2005.

Откройте созданный вами план обслуживания и выберите из контекстного меню пункт «View History»:

Откроется окно с протоколом выполнения всех заданных регламентных процедур.

Успешно выполненные задачи и задачи, выполненные с ошибками, будут помечены соответствующими иконками. Для задач, выполненных с ошибками, доступна подробная информация об ошибке.

Источник: Регламентные операции MS SQL Server. Оптимизация работы