Влияние блокировок на производительность 1С:Предприятие 8

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

Ниже мы расскажем наш опыт по решению данных проблем.

Обнаружение проблем блокировок в 1С

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

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

Существует много инструментов, но практически у всех них есть один очень существенный недостаток — цена.

Но есть выход — мы в качестве инструмента анализа выбираем

Мы будем исследовать проблему на MS SQL Server, поэтому нам потребуются следующие сервисы из этого набора:

1. Мониторинг и анализ долгих запросов (подробнее о настройке читайте здесь ) — нужен для того чтобы оценить о наличии долгих операций к субд.

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

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

3. Анализ взаимных блокировок в 1С и MS SQL server (подробнее о настройке читайте здесь ) — позволит нам оценить более сложные ситуации с ожиданием ресурсов, когда несколько участников часть ресурсов уже успели «захватить» блокировкой и теперь вынуждены ждать вынуждены ждать друг друга из-за того, что они не могут освободить занятые ресурсы до завершения захвата других ресурсов, заблокированных соседями.

Вообщем в такой непростой ситуации вручную не разобраться, нужен такой сервис.

4. Контроль загруженности оборудования (подробнее о настройке читайте здесь ) помогает нам ответить на вопросы — сколько пользователей в системе, есть ли у них блокировки, как много блокировок, справляется ли железо с нагрузкой?

Сервисы настраиваются очень легко, но даже если у вас все равно остались вопросы, есть !

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

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

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

В результате мы получим картину производительности которая измеряется

— время запроса (разумеется, отранжировав проблемные запросы по весу (время запроса на количество вызовов этого запроса);

— время ожидания блокировок;

Итак, мы запустили сервис Анализ ожиданий на блокировках

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

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

В нижней таблице откройте детализацию по факту одного из событий «таймаута». Как например на картинке.

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

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

Решать эту проблему можно «правильно» и «по легкому».

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

Один из факторов как ни странно звучит — это уменьшение длительности .

Уменьшить длительность транзакции можно:

1. переписав алгоритм

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

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

3. уменьшив объем данных, обрабатываемый в тразакции (помимо линейной скорости помним еще про эскалацию блокировок)

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

Время исполнения запроса

1) разные пользователи могут работать параллельно с разными данными
2) разные пользователи должны работать строго последовательно с одними и теми же данными

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

Как работают блокировки (этот пункт можно не читать)

Работой с блокировками занимается специальный модуль SQL Server’а – менеджер блокировок (Lock Manager). В его задачи входит:

• создание и установка блокировок;
• снятие блокировок;
• эскалация блокировок;
• определение совместимости блокировок;
• устранение взаимоблокировок (deadlocks) и многое другое.

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

Основная причина, снижающая быстродействие – блокировки

Ожидания на блокировках являются основной проблемой быстродействия многопользовательского режима. И это понятно, ведь они увеличивают время ожидания операций, а значит и время отклика. Можно ли сказать, что ожидание на блокировках – это не правильно и ошибка многопользовательской системы? Так сказать нельзя, поскольку сам по себе механизм блокирования ресурсов обеспечивает целостность данных. С помощью механизма блокировок конкурентные данные ЗАПИСЫВАЮТСЯ ПОСЛЕДОВАТЕЛЬНО.

Разница между необходимыми и избыточными блокировками

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

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

Тут как бы невзначай ввожу определение:

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

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

Итак,пользователи в многопользовательских информационных базах могут часто жаловаться, что невозможно работать из-за этих блокировок, при этом в коде действительно могут быть блокировки, которые в этом месте не нужны (избыточные).
А еще и в коде конфигурации они сами по себе блокировки могут не присутствавать, про них можно прочитать например здесь http://kb.1c.ru/articleView.jsp?id=30 (статья является фрагментом книги П.С.Белоусов, А.В.Островерх «1С:Предприятие: от 8.0 к 8.1».). Предлагаю упрощенный способ объяснения различия блокировок на простом примере так:

В вашей конфигурации в режиме 1С:Предприятие создайте две одинаковых накладных с одинаковым составом товара. Но обязательно укажите различные склады поступления.
В коде обработки проведения надо добавить строчку с выводом на экран сообщения (или другой код, способный задержать исполнение обработки проведения на 21 секунду (таймаут блокировки происходит через 20 секунд, если параметры по умолчанию)).
Проводите два документа.
Если возникает таймаут, а по логике товары приходят на разные склады, в приложении присутствуют избыточные блокировки. Бизнес – логике (считай по здравому смыслу) здесь блокировок не должно быть.
Если же мы теперь сделаем в этих двух накладных одинаковые склады. То созданные блокировки в результате попытки одновременного проведения приведут НЕОБХОДИМОЙ блокировке и это ХОРОШО!

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

Конечно даже этот простой пример оставляет много вопросов. Например, а если документы от одного поставщика и «двигается» задолженность по нему. А если двигаются не одни остатки на складе, а несколько регистров, а документы разного вида.
Но самый главный вопрос – А ПО КАКОЙ ТАКОЙ БИЗНЕС-ЛОГИКЕ НЕ ДОЛЖНО БЫТЬ БЛОКИРОВОК. Кто эту бизнес – логику и где прописывает в контексте блокировок? Но довайте обо всем по порядку.

Избыточные блокировки – лишние – которые не нужны с точки зрения обеспечения целостности данных и при этом снижающие общую производительность системы, увеличивая общее время «простоя» — ожидания на блокировках.
Необходимая блокировка возникает при захвате двумя пользователями одних и тех же ресурсов (объектов данных). Если же пользователи работают с непересекающимися ресурсами, но при этом происходит ожидание на блокировке, то блокировка считается избыточной.

Наиболее понятными критериями избыточности блокировок обозначу:

1. Взаимные блокировки;

2. Уровень (область) блокировки выше необходимой (как частный случай повышения уровня блокировки, т.н. эскалация);

3. Время блокировки больше времени «реального» использования объекта блокировки.

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

• Константы
• Последовательность
• Регистры бухгалтерии
• Регистры накоплени
• Регистры сведений
• Регистры расчета

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

На рисунке показано физическое размещение констант конфигурации УПП в таблице базы данных MS SQL Server 2005.

Это означает, что при блокировке одной константы будут заблокированы все константы. СУБД накладывает блокировку на ВСЮ единственную СТРОКУ таблицы, т.е. на все константы.

Однако в последних релизах платформы хранение констант изменено. Теперь каждая константа — это отдельная таблица. Правда сильно не увлекайтесь, если вы создадите тысячи таблиц, то можете словить блокировку на базе master.

Внимание, если у вас конфигурация существует давно, то изменить формат хранения можно путем «реструкторизации» в Тестировании и Исправлении конфигуратора.

2) Отказаться от использования объекта метаданных «Последовательность». Хотя бы от движений при оперативном проведении, проводить при неоперативном (допроведении). Смотрите, как реализовано в последних версиях УПП.

3) Если в системе осуществляется оперативная запись движений по бухгалтерскому регистру в многопользовательском режиме, то рекомендуется:

• включить для данного регистра режим разделения итогов;
• не использовать контроль остатков регистра при оперативной работе.

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

5) Избавиться от некоторых избыточных блокировок, создаваемых платформой можно только путем . В автоматическом режиме работы конфигураций платформа «берет на себя» блокирование ресурсов. Цена беззаботного использования автоматического режима — возможны блокировки на границах диапазонов индексов, блокировки пустой таблицы, эскалация блокировок.

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

Уже несколько раза произнес «управляемые блокировки», «управляемый режим». Надо понимать, что существует два вида блокировок:
Блокировки СУБД – устанавливаются автоматически на уровне СУБД при выполнении запросов.
Блокировки 1С:Предприятие – устанавливаются автоматически при записи (модификации) данных и всегда вручную при чтении данных.

Дотошный читатель скажет, что 1С делит еще на объектные и не объектные блокировки, но сейчас этот подход мы трогать не будем.

Зато отмечу, что накладывает больше требований квалификации и опыту 1С-специалиста.

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

Основные причины избыточных блокировок (подитожим выше сказанное)

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

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

У ребенка и взрослого болит горло. Когда доктор задаст вопрос: «Что не так?», ребенок будет смотреть на доктора и кричать (верьте мне, я знаю), тогда как взрослый укажет на симптомы болезни. Эти явное различие направляет доктора к разным методам идентификации проблемы.
С ребенком, доктор должен выполнить много тестов, собрать данные, объединить их, выполнить анализ и только затем дать рекомендации. Тогда как с взрослым, он задаст несколько вопросов и, поскольку число исходных данных невелико, время анализа и определения проблемы будет существенно меньше. Как результат, рекомендации будут выданы намного раньше.

Пользуйтесь нашими сервисами и у Вас появиться больше возможностей бесплатно проанализировать проблему и найти решение!

1С: Бухгалтерия – одна из самых известных и наиболее удобных программ бухгалтерского учета. Доказательством этого является ее повсеместное распространение во всех сферах деятельности: торговле, производстве, финансах и др.

К сожалению, как и у всех компьютерных программ в 1С: Бухгалтерия также бывают различные сбои и зависания. Одна из наиболее часто встречающихся проблем – медленная работа системы.

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

Устранение распространенных причин медленной работы 1С

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

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

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

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

3. Следующая возможная причина - устаревшее ПО или неактуальная версия самой программы.

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

Чтобы установить последнюю версию системы 1С, необходимо зайти в программу в режиме «Конфигурация», далее из меню перейти в «Сервис» -> «Служебные» -> «Обновление конфигурации», после этого выбрать настройки по умолчанию и нажать кнопку «Обновить».

Хорошо знакомая ИТ-специалистам жалоба пользователей «висит 1С» имеет множество причин. Для постановки правильного «диагноза» – выявления и анализа проблемы, требуется ее воспроизведение, ведь проблему, которую невозможно воспроизвести, как правило, практически невозможно решить. Разобравшись в симптомах зависания 1С, мы сделаем первый шаг на пути к эффективно работающей системе.

Очень долгий запуск системы

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

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

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

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

Очень долгое открытие форм

Долгое открытие форм может быть обусловлено:

1. Большим количеством элементов управления на форме – время тратится на создание формы и взаимоувязку расположения элементов формы;
2. Выполнением алгоритмов при инициализации формы. Возможно, при создании формы проверяются какие-либо условия и/или происходит чтение связанных объектов из базы данных.

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

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

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

1. Алгоритмы, выполняющиеся при данном действии, проверяют или вычисляют связанные с ними данные, влияющие на режим выбора значения;
2. Форма выбора, которая открывается для выбора этого значения, при инициализации считывает все объекты из базы данных.

Для решения первой проблемы следует воспользоваться «Замером производительности», найти ресурсоемкие алгоритмы и оптимизировать их.

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

Также есть ситуации, когда при открытии формы выбора из базы данных считываются какие-либо связанные данные (например, при открытии формы выбора «Номенклатура» считываются остатки товаров на складах). Как правило, это не лучшее решение. Считывание связанных данных лучше выполнять асинхронно, уже после открытия формы. Это вызовет меньше дискомфорта у пользователя, т.к. после показа формы пользователь потратит некоторое время на восприятие открывшейся формы, и это время можно потратить на загрузку связанных данных.

Очень долгая реакция на обновления

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

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

Долгая запись объектов/проведение документов

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

Но даже в ЭТОМ случае, можно наметить направление для анализа.

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

Кардинальное изменение времени записи при неясных зависимостях, требует выполнения статистического анализа появления проблемы, т.е. анализа производительности. Самый простой способ – анализ использования журнала регистрации. Дополнительным преимуществом здесь является поддержка платформой «1С:Предприятие 8» сохранения данных журнала регистрации в файл формата SQLite. Это позволит использовать SQL-запросы для анализа данных журнала. Время записи объектов вполне можно получить из данных журнала, если учесть тот факт, что каждая запись объекта выполняется в транзакции, а у каждой транзакции есть свой идентификационный номер.

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

Если время записи объектов зависит от количества пользователей, проблемы, скорее всего, заключаются в коде (возможны ожидания на блокировках) или в пропускной способности оборудования. Для их решения следует привлечь специалиста, имеющего компетенцию «1С:Эксперт по технологическим вопросам», поскольку унифицированных правил решения такой задачи не существует.

В данной статье рассматриваются основные факторы: когда 1С тормозит, 1С зависает и медленно работает 1С. Данные подготовлены на основании многолетнего опыта компании SoftPoint по оптимизации крупных IT систем, построенных на связке 1С + MS SQL.

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

Из практики: Легче всего оптимизировать 1С v7.7 (Оптимизация 1С 8.1, 1С 8.2, 1С 8.3 более сложная задача, так как приложение состоит из 3 звеньев). Довести её до 400 одновременных пользователей – достаточно типовой проект. До 1500 – уже сложный, требующий упорной работы.

Второй миф: чтобы улучшить работу 1С и избавиться от зависаний 1С нужно поставить более мощный сервер. Как правило в проектах оптимизации в 95% случаев удаётся достичь приемлимых показателей либо вообще без апгрейда, либо обновив незначительную часть оборудования, например, добавив оперативную память. При этом нужно отметить, что оборудование всё-таки должно быть серверным, особенно дисковая подсистема. Устаревшая дисковая подсистема - лишь одна из причин, почему медленно работает 1С.

Основное ограничение при многопользовательской работе в 1С – блокировочный механизм. Именно блокировки в 1С, а не оборудование сервера обычно не дают работать в базе большому количеству людей. Чтобы побороть эту беду – приходится хорошенько потрудиться и менять логику блокировок в 1С - опустить их с табличных до построчных. Тогда, например, проведение документа будет блокировать только один, а не все документы в системе.

Рисунок 1. Очередь блокировок 1С в системе мониторинга PerfExpert, с информацией о пользователях 1С, модуле конфигурации и конкретной строке кода в этом модуле.

Изменение механизма блокировок 1С - очень сложная технология. Не всем под силу провернуть подобный фокус и для них остаётся только один путь – оптимизация структуры и ускорение времени выполнения операций. Дело в том, что блокировки в 1С и время выполнения операций – сильно взаимосвязанные показатели. Например, если операция проведения документа занимает 15 секунд, то при большом количестве пользователей велика вероятность, что во время проведения ещё кто-то попробует провести документ, и будет ожидать в блокировке. Если довести время проведения, хотя-бы до 1 секунды, то блокировки 1С по этой операции значительно снизятся.

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

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

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

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

Замедлять время выполнения операций и, следовательно, увеличивать интенсивность блокировок 1С помимо запуска тяжёлых отчётов может неоптимальная настройка MS SQL и MS Windows. Эта проблема обнаруживается у 95% клиентов. Нужно отметить, что это сервера серьёзных организаций, их поддержкой и настройкой занимаются целые отделы высоко квалифицированных администраторов.

Основной причиной не правильной настройки сервера является страх администраторов что-либо менять на работающем сервере и правило «Лучшее – враг хорошего». Если администратор поменяет настройки сервера и начнутся проблемы, то весь гнев начальства выльется на нерадивого админа. Поэтому ему выгоднее оставить всё как есть, и не делать ни шагу без распоряжения начальства, чем экспериментировать под свою ответственность.

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

На первый взгляд картина ясна – нужно оптимизировать всё, что тормозит работу сервера 1С. Но давайте представим себя на месте такого оптимизатора – допустим у нас 1С 8.1 8.2 8.3 УПП и одновременно работают 50 пользователей. В один ужасный день пользователи начинают жаловаться, что 1С тормозит, и нам нужно решить эту проблему.

Первым делом смотрим, что происходит на сервере - вдруг там какой-нибудь особо самостоятельный антивирус проводит полную проверку системы. Осмотр показывает, что всё прилично – сервер нагружен под 100%, причём только процессом sqlservr.

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

Следующий шаг – проверяем, какие программы нагружают MS SQL. Осмотр показывает, что нагрузка создаётся из примерно 20 соединений сервера приложений.

Из практики: зациклилась программа, оперативно обновляющая данные на сайте, и вместо того, что-бы обновлять раз в 4 часа – делала это не переставая, без пауз, сильно нагружая сервер, и блокируя данные.

Дальнейший анализ ситуации сталкивается с большими трудностями. Мы уже выяснили, что нагрузка идёт непосредственно из 1С, но как понять, что именно делают пользователи? Или хотя-бы, кто они. Хорошо, если пользователей 1С в организации 10, тогда можно просто пройтись по ним и узнать, чем они сейчас занимаются, но в нашем случае их полсотни, и раскиданы они по нескольким зданиям.

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

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

Когда мы начали работать на ниве оптимизации, то перепробовали много систем мониторинга серверов, к сожалению, найти что-то, решающее эту задачу на должном уровне, нам не удалось, поэтому пришлось создавать систему своими силами. В результате получился уникальный продукт PerfExpert, который позволил автоматизировать и поставить на поток процессы оптимизации IT-систем. Программу отличают плотная интеграция с 1С, отсутствие сколь-нибудь заметной дополнительная нагрузки и многократно проверенная пригодность для практического использования в боевых ситуациях.

Возвращаясь к нашему примеру – наиболее вероятный исход: Администратор говорит «Виноваты программисты, которые писали конфигурацию», Программисты в ответ – «У нас всё написано хорошо – это сервер плохо работает». А воз, как говорится, и ныне там. В итоге 1С тормозит, зависает или работает медленно.

В любом случае для решения проблем производительности 1С мы рекомендуем для начала приобрести и использовать мониторинг производительности PerfExpert , это позволит Вам принять правильное управленческое решение и сэкономить деньги. Продукт подходит как для небольших ИС 1С:Предприятие – до 50 пользователей, так и для систем – от 1000 пользователей. С июля 2015 года мониторинг производительности PerfExpert получил сертификат 1С:Совместимо, прошел тестирование в Microsoft и помогает решать проблемы производительности не только для систем 1С, но и для других информационных систем на базе MS SQL Server (Axapta , CRM Dynamics , Doc Vision и прочие).

Если Вам понравилась информация, рекомендуемые дальнейшие действия:

- Если Вы хотите самостоятельно разбираться с техническими проблемами производительности 1С (1С 7.7, 1С 8.1, 1С 8.2, 1С 8.3) и других информационных систем , то для Вас уникальный список технических статей в нашем Альманахе (Блокировки и взаимоблокировки, большая нагрузка на CPU и диски, обслуживание баз данных и индексный тюнинг - лишь малая часть технических материалов, которые Вы там найдете).
.
- Если Вы хотите обсудить с нашим экспертом проблемы производительности или заказать решение мониторинг производительности PerfExpert , то оставьте заявку и мы свяжемся с Вами в кратчайшие сроки.

2. Особенность работы программы. Часто даже при оптимальных настройках 1С работает очень медленно. Особенно сильно быстродействие падает, когда количество одновременно работающих с базой превышает 4-5 пользователей.

Кто вы в компании?

Решение проблемы медленной работы 1С зависит от того, кто вы в компании. Если вы технический специалист - просто читайте дальше. Если вы директор или бухгалтер, переходите по специальной ссылке ↓

Пропускная способность сети

Как правило, с одной информационной базой (ИБ) работает не один, а несколько пользователей. При этом, постоянно идет обмен данными между компьютером, на котором установлен клиент 1С и компьютером, на котором расположена ИБ. Объем этих данных достаточно существенный. Часто возникает ситуация, когда локальная сеть работающая на скорости 100 Мбит/с, а это наиболее часто встречающаяся скорость, просто не справляется с нагрузкой. И снова пользователь жалуется на тормоза в программе.

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

Теперь давайте рассмотрим несколько решений проблемы с низкой скоростью работы 1С и их стоимость, на примере локальной сети из 10 средних компьютеров.

Решение первое. Модернизация инфраструктуры

Это, пожалуй, самое очевидное решение. Рассчитаем его минимальную стоимость.

Как минимум, на каждый компьютер нам понадобиться планка оперативной памяти на 2 Гб, стоит, в среднем, 1500 руб, сетевая карта с поддержкой скорости 1 Гбит/c, стоит около 700 руб. Дополнительно понадобиться как минимум 1 маршрутизатор, поддерживающий скорость работы 1 Гбит/с, который обойдется примерно 4000 руб. Итого, стоимость - 26000 рублей на оборудование, без учета работ.

В принципе, скорость может существенно вырасти, однако, теперь покупать в офис недорогие компьютеры уже не получится. Кроме того, данное решение не применимо для тех, кто использует Wi-Fi или хочет работать через интернет - в их случае скорость сети может быть в десятки раз ниже. Напрашивается мысль: «А нельзя ли реализовать работу программы целиком на одном мощном сервере, чтобы пользовательский компьютер не участвовал в сложных расчетах, а служил просто для передачи изображения?» Тогда можно работать даже на очень слабых компьютерах, даже в сетях с низкой пропускной способностью. Естественно такие решения существуют.

Решение второе. Сервер терминалов

Получил большую популярность еще во времена 1С 7. Реализован на серверной версии Windows и прекрасно справляется с нашей задачей. Однако, имеет свои подводные камни, а именно - стоимость лицензий.

Сама операционная система обойдется где-то в 40000 руб. Дополнительно к этому нам понадобиться для каждого, кто планирует работать в 1С еще лицензия Windows Server CAL, стоимостью примерно в 1700 руб и лицензия Windows Remote Desktop Services CAL, которая стоит около 5900 руб.

Посчитав стоимость для сети из 10 компьютеров, мы получим в итоге 116 000 руб. только на одни лицензии. Добавьте к этому стоимость самого сервера (минимум 40 000 руб) и стоимость работ по внедрению, впрочем, даже без этого, цена на лицензии получилась внушительная.

Решение третье. Сервис 1С Предприятия

Фирма 1С разработала свой решение данной проблемы, способное серьезно повысить скорость программы. Но и тут есть нюанс.

Дело в том, что стоимость такого решения составляет от 50 000 до 80 000 руб., в зависимости от редакции. Для компании до 15 пользователей получается дороговато. Большие надежды возлагались на «мини-сервер 1С предприятия», который, по заявлениям фирмы 1С, ориентирован на малый бизнес и стоит в районе 10000 - 15000 руб.

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

Как написал на форуме один программист 1С: «До сих пор не понятно, почему 1С выбрала именно 5 подключений! От 4 пользователей проблемы только начинаются, а тут на пяти все заканчивается. Хочешь подключить шестого - доплати еще 50 тыс. Сделали бы хоть на 10 подключений…»

Конечно, мини-сервер тоже нашел своего потребителя. Однако для компаний, где с 1С работают от 5 человек, так и не появилось простого и недорогого решения.

Помимо описанных выше методов ускорения программы, существует еще один, идеально подходящий для сегмента 5 - 15 пользователей, а именно - web-доступ для 1С в файловом режиме.

Решение четвертое. Web-доступ для 1С в файловом режиме

Принцип работы следующий: на компьютере поднимается дополнительная роль web-сервера, на котором происходит публикация ИБ.

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

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

Данный вариант уступает серверу 1С предприятия по скорости работы, но разница эта до 15-20 пользователей визуально практически не заметна. Кстати, для реализации web-сервера можно использовать IIS (для Windows) и Apache (для Linux) и оба этих решения бесплатны!

Несмотря на очевидные преимущества, данный способ оптимизации работы 1С не получил большой популярности.

Не берусь утверждать наверняка, но скорее всего, это связано с двумя причинами:

• Довольно слабое описание в технической документации
• Находится на стыке ответственности системного администратора и программиста 1С

Обычно, когда с проблемой низкой скорости работы обращаются к сисадмину, он предлагает модернизацию инфраструктуры или сервер терминалов, если к специалисту 1С - предлагается сервер 1С предприятия. Так что, если в вашей компании, специалист отвечающий за инфраструктуру и специалист, отвечающий за 1С работают «рука об руку», то смело можете воспользоваться решением на базе web-сервера.

Ускорим 1С. Дистанционно, быстро и без вашего участия

Мы умеем ускорять 1Ски и при этом не дергать заказчика. Мы вникаем в проблему, делаем свою работу и уходим. Если вам хочется, чтобы программа просто нормально работала - обратитесь к нам. Мы разберемся.

Оставьте заявку - и получите бесплатную консультацию по ускорению программы.