1с захвачено субд в чем измеряется
Перейти к содержимому

1с захвачено субд в чем измеряется

  • автор:

Блокировки данных на уровне 1С и СУБД

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

Разбираемся в терминологии

Если простыми словами – то блокировка данных в 1С – это запись о том, что какой-то ресурс захвачен кем-то для выполнения каких-то действий.
Часть блокировок реализовано средствами самой платформы 1С – они называются объектные блокировки. Другая часть ложится на плечи СУБД – это транзакционные блокировки. Наличие этих двух видов блокировок обусловлено подходами к представлению данных. 1С рассматривает данные в первую очередь как неделимые объекты, которые редактируются целиком – например, карточка конкретного товара, или конкретный документ. А для СУБД все данные – это набор связанных между собой таблиц.

Зачем вообще нужны блокировки в 1С?

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

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

Транзакционные блокировки контролируются СУБД – например MS SQL сервером или PostgreSQL. Любая СУБД должна обеспечивать целостность и непротиворечивость хранящихся в ней данных. Для того, чтобы данные изменялись согласованно в разных таблицах, используются транзакции. А для обеспечения конкурентного доступа в свою очередь – транзакционные блокировки.

Стакан наполовину пуст?

Объектные блокировки делятся на пессимистические и оптимистические.

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

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

Почему объектные блокировки так называются?
мне попалась такая версия, и я в целом с ней согласен:
– объект-оптимист считает, что ничего не изменится, пока вы его читаете;
-объект-пессимист думает, что будет что-то нехорошее, и поэтому блокирует попытки изменения на время редактирования.

Транзакционные блокировки

Как очевидно из названия, данные блокировки тесно связаны с понятием “Транзакция”. Транзакция работает по принципу “все или ничего” – либо все действия в рамках транзакции успешно и без ошибок записываются, либо происходит “откат транзакции”, и в этом случае никаких изменений в базу не вносится.

Транзакционные блокировки 1С делятся на два вида – автоматические и управляемые.

Автоматические транзакционные блокировки управляются полностью средствами СУБД, и повлиять на них разработчик средствами языка 1С не может. Автоматические блокировки иногда приводят к избыточному блокированию данных. Например, мы хотим заблокировать данные только по покупателю Иванов, чтобы записать поступление оплаты, а СУБД полностью блокирует всю таблицу взаиморасчетов, и в этом случае другой пользователь вынужден ждать, пока будут записаны данные об оплате Иванова, чтобы записать оплату, к примеру, от Петрова. Поэтому если к системе предъявляются высокие требования к параллельности работы, автоматические блокировки – не лучший вариант. В то же время, они позволяют значительно упростить разработку прикладного решения, т.к. все управление блокировками лежит на СУБД.

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

Ошибки из-за неправильной работы транзакционных блокировок

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

  • Проблема потерянных изменений
  • Проблема неповторяющегося чтения
  • Проблема чтения грязных данных
  • Проблема чтения фантомов

Более подробно вы можете ознакомиться например, в статье Википедии.

И еще кое-что о блокировках на уровне СУБД

Из статьи в статью, с сайта на сайт кочует текст про “физическое расположение блокировок” и про виды блокировок:
S – разделяемая блокировка для чтения
X – исключительная блокировка для записи
U – блокировка для обновления.

И все бы хорошо, но только почти нигде не указывается, что речь идет только о блокировках конкретной СУБД, а именно – MS SQL Server. Так вот. Видов блокировок, которые существуют в этой СУБД, более 20. Но 1С использует только эти три. Далее, для других СУБД названия блокировок будут другие, хотя и с тем же смыслом. Например. в Oracle это будут RS, RX, TX и другие.
Я думаю, широкое распространение текстов именно про блокировки S, X и U связаны с тем что для 1С СУБД MS SQL Server занимает очень значительную долю среди остальных.
Поэтому призываю читателей критически воспринимать информацию, проводить самостоятельные исследования и глубже вникать в материал. Кто знает, вдруг однажды вы блеснете приобретенными знаниями на собеседовании?

Как я диагностировал проблемы блокировок

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

Очевидно, что здесь нет проблемы взаимоблокировок, здесь просто какой-то сеанс поставил блокировку и «забыл» убрать. При этом проблема грозила серьезными последствиями — не проводился документ Реализации товаров и услуг. В базе единовременно работает около 100 человек, и невозможно выполнить типовую и частую операцию!

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

Первый день — проблема появилась днем, поначалу казалось, что проблема в удаленном пользователе, который засел в Конфигураторе. Было похоже, что просто выполнение остановилось на точке, и блокировка, естественно, не снялась. Через пару часов удалось освободить конфигуратор, но проблема не ушла. Убивать принудительно конфигуратор было крайне нежелательно, возможно, в нем работали. После этого в ход пошел гугл. Нашел статью на этом сайте, в которой пишется, как найти блокировки в СУБД MS SQL, проверил, блокировок на уровне СУБД не было. Странно. Далее были попытки настроить тех. журнал. Настроил, а дальше что? За 15 минут пара гигов логов! Как их читать, что искать? Неизвестно.

Нашел статью, как посмотреть, что заблокировано через SQL Trace. Да даже если найду, дальше что? Мне нужен сеанс!

Ближе к 16:00, когда я понял, что дальше тянуть нельзя, я сделал ребут. В надежде, что такого больше не повторится (а это был первый случай за полгода работы), вздохнул с облегчением, все заработало. А зря… Второй день — та же ситуация. Копался часа полтора, опять непонятные попытки гуглить и прочее. Без результатов. Ребут. Под конец дня произошло еще раз. Ну, думаю, замечательно, спокойно приеду домой и посижу, поковыряюсь. Приезжаю домой, все уже нормально. Печально.

На третий день глянул вебинар, рассказали про интересный и эффективный способ поиска проблемы. Запомнил, но проблема больше не возникала. Прошла неделя и вот оно — опять блокировки! Потираю руки и начинаю действовать.

Первое — настраиваем журнал. Да, без него никак, но теперь я умею его читать. Ставим два события: первое TLOCK, второе TTIMEOUT. Первое отображает все события блокировки, второе показывает блокировки, которые не смогли установиться в отведенное им время. На самом деле, скорее всего, достаточно только TTIMEOUT.

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

Переходим в папку rphost_PID, находим текстовые файли и делаем поиск по слову TTIMEOUT. Видим строку:

К слову, папок rphost_PID может быть несколько, все зависит от того, сколько рабочих процессов запущено на сервере.

А дальше все просто: смотрим в конец строки — WaitConnections = 8239, это наш номер СОЕДИНЕНИЯ. Заходим в консоль сервера, переходим в Соединения, находим этот номер и смотрим номер сеанса. В моем случае на одного пользователя было два сеанса — сбойный и какой-то другой. Грохнул сеанс, на который указывал техжурнал. И о чудо! Все заработало, радости нет предела! Но, как выяснилось позже, сеанс был не зависший :), в нем работали. Поэтому на будущее — желательно связываться с пользователем и предупреждать.

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

Настройка 1С и MS SQL. Оптимизация работы 1C. Настройка сервера MS SQL

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

  • Интервал перезапуска — отвечает за частоту перезапуска рабочих процессов кластера. Этот параметр необходимо выставлять при круглосуточной работы сервера. Рекомендуется частоту перезапуска связывать с технологическим циклом информационных баз кластера. Обычно это каждые 24 часа (86400 сек). Как известно, рабочие процессы серверов 1С обрабатывают и хранят рабочие данные.
  • Автоматический перезапуск был разработан в платформе «для минимизации отрицательных последствий фрагментации и утечки памяти в рабочих процессах». На ИТС есть даже информация о том, как организовать перезапуск рабочих процессов по другим параметрам (объем памяти, занимаемые ресурсы и т.п.).
  • Допустимый объем памяти — защищает сервера 1С от перерасхода памяти. При превышении процессом этого объема в интервале превышения допустимого объема, процесс перезапускается. Можно рассчитать, как максимальный размер памяти, занимаемый процессами «rphost» в периоды пиковой нагрузки серверов. Также стоит установить небольшой интервал превышения допустимого объема.
  • Допустимое отклонение количества ошибок сервера. Платформа рассчитывает среднее количество ошибок сервера по отношению к числу обращений к серверу в течение 5 минут. Если это отношение превысит допустимое, то рабочий процесс считается «проблемным», и может быть завершен системой, если установлен флаг «Принудительно завершать проблемные процессы».
  • Выключенные процессы останавливать через. При превышении допустимого объема памяти, рабочий процесс не завершается сразу, а становится «выключенным», чтобы было время «перенести» рабочие данные без потери на новый запущенный рабочий процесс. Если указан этот параметр, то «выключенный» процесс в любом случае завершится по истечении этого времени. Если наблюдаются «зависшие» рабочие процессы в работе сервера 1С, то можно стоит этот параметр на 2-5 минут.

Эти настройки устанавливаются для каждого сервера 1С индивидуально.

  • Максимальный объем памяти рабочих процессов — это объем совокупной памяти, которую могут занимать рабочие процессы (rphost) на текущем кластере. Если параметр установлен в «0», то занимает 80% оперативной памяти сервера. «-1» — без ограничений. Когда на одном сервере работают СУБД и сервер 1С, им нужно делить между собой оперативную память. Если в процессе эксплуатации обнаружится, что серверу СУБД не хватает памяти, то можно ограничить память, выделяемую серверу 1С с помощью этого параметра. Если СУБД и 1С разделены по серверам, то имеет смысл рассчитать этого параметр по формуле:
    «Max объем» = «Общая оперативная память» — «Оперативная память ОС»;
    «Оперативная память ОС» рассчитывается по принципу 1 Гб на каждые 16 Гб оперативной памяти сервера
  • Безопасный расход памяти за один вызов. В общем случае, отдельные вызовы не должны занимать всю оперативную память, выделенную рабочему процессу. Если параметр установлен в «0», то объем безопасного расхода будет равен 5 % от «Максимального объема памяти рабочих процессов». «-1» — без ограничения, что крайне не рекомендуется. В большинстве случаев этот параметр лучше оставлять «0».
  • С помощью параметров «Количество ИБ на процесс» и «Количество соединений на процесс» можно управлять распределением работы сервера 1С по рабочим процессам. Например, запускать под каждую информационную базу отдельный «rphost», чтобы в случае «падений» процесса, отключались только пользователи одной базы. Эти параметры стоит подбирать индивидуально под каждую конфигурацию сервера.

Рекомендации по настройке СУБД MS SQL

Ограничение на использование оперативной памяти сервером СУБД — У сервера СУБД MS SQL есть одна замечательная особенность — он любит загружать базы, с которыми ведется активная работа в оперативную память полностью. Если его не ограничивать, то он заберет себе всю оперативную память, какую только сможет.

  • Если сервер 1С установлен вместе с Microsoft SQL Server, то верхний порог памяти необходимо уменьшить на величину, достаточную для работы сервера 1С.
  • Если на сервере работает только СУБД, то для СУБД по формуле:
    «Память СУБД» = «Общая оперативная память» — «Оперативная память ОС»;
  • Shared memory — об этом параметре известно много, но до сих пор встречается, что про него забывают. Выставляем в «1», если сервер 1С и СУБД работают на одном физическом или виртуальном сервере.
  • Max degree of parallelism — определяет, сколько процессоров используется при выполнении одного запроса. СУБД распараллеливается получение данных при выполнении сложных запросов на несколько потоков. Для 1С рекомендуется устанавливать в «1», то есть одним потоком.
  • Авторасширение файлов БД — определяем шаг в МБ, с которым «расширяется» файл базы данных. Если шаг будет маленький, то при активном росте БД, частые расширения приведут к дополнительной нагрузке на дисковую систему. Лучше установить в 500 — 1000 МБ.
  • Реиндексация и дефрагментация индексов — рекомендуется делать дефрагментацию/реиндексацию хотя бы раз в неделю. Реиндексация блокирует таблицы, поэтому лучше запускать в нерабочее время или периоды минимальной нагрузки. Нет смысла делать дефрагментацию после перестроения индекса (реиндексации). По рекомендации Microsoft дефрагментацию делают в том случае, если фрагментация индекса не превышает 30 %. Если выше, рекомендуется сделать реиндексацию.
  • Обновление статистики — рекомендуется обновлять статистику хотя бы 1 раз в день. Статистика отвечает за производительность выполнения запросов.
  • План электропитания — в настройках электропитания операционной системы установить на высокую производительность.

Включить возможность мгновенной инициализации файлов (Database instant file initialization)

Это позволяет ускорить работу таких операций как:

Создание базы данных.

Добавление файлов, журналов или данных в существующую базу данных.

Увеличение размера существующего файла (включая операции автоувеличения).

Восстановление базы данных или файловой группы.

Для включения настройки:

Откроть Local Security Policy (secpol.msc).

Локальные политики — Назначение прав пользователей

Выполнение задач по обслуживанию томов

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

Включить «Блокировка страниц в памяти» (Lock pages in memory)

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

Пуск — Выполнить — gpedit.msc.

Конфигурация компьютера — Конфигурация Windows

Настройки безопасности и Локальные политики

Назначение прав пользователя

«Блокировка страниц в памяти»

В диалоговом окне Параметр локальной безопасности — блокировка страниц в памяти выбрать «Добавить» пользователя или группу

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

Чтобы изменения вступили в силу, перезагрузите сервер.

Отключить механизм DFSS для дисков

Механизм Dynamic Fair Share Scheduling отвечает за балансировку и распределение аппаратных ресурсов между пользователями. Иногда его работа может негативно сказываться на производительности 1С. Чтобы отключить его только для дисков, нужно

  • Найти в реестре ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk
  • Установить значение параметра EnableFairShare в 0

Отключить сжатие данных для каталогов, в которых лежат файлы базы

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

Чтобы отключить сжатие файлов в каталоге, необходимо

  • Открыть свойства каталога
  • На закладке Общие нажать — Другие
  • Снять флаг «Сжимать» содержимое для экономии места на диске

Установить параметр «Максимальная степень параллелизма» (Max degree of parallelism) в значение 1

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

  • Запустить Management Studio и подключиться к нужному серверу
  • Свойства сервера — Дополнительно
  • Установить значение параметра равное единице

Ограничить максимальный объем памяти сервера MS SQL Server

Необходимо ограничить максимальный объем памяти, потребляемый MS SQL Server, особенно это критично, если роли сервера 1С и сервера СУБД совмещены. Максимальный объем памяти, рекомендуемый для MS SQL Server, можно рассчитать по следующей формуле:

Память для MS SQL Server = Память всего — Память для ОС — Память для сервера 1С

Например, на сервере установлено 64 ГБ оперативной памяти, необходимо понять, сколько памяти выделить серверу СУБД, чтобы хватило серверу 1С.

Для нормальной работы ОС в большинстве случаев более чем достаточно 4 ГБ, обычно — 2-3 ГБ.

Чтобы определить, сколько памяти требуется серверу 1С, необходимо посмотреть, сколько памяти занимают процессы кластера серверов в разгар рабочего дня. Этими процессами являются ragent, rmngr и rphost, подробно данные процессы рассматриваются в разделе, который посвящен кластеру серверов. Снимать данные нужно именно в период пиковой рабочей активности, когда в базе работает максимальное количество пользователей. Получив эти данные, необходимо прибавить к ним 1 ГБ — на случай запуска в 1С «тяжелых» операций.

Чтобы установить максимальный объем памяти, используемый MS SQL Server, необходимо

  • Запустить Management Studio и подключиться к нужному серверу
  • Свойства сервера, Память
  • Указать значение параметра Максимальный размер памяти сервера

Включить флаг «Поддерживать» приоритет SQL Server (Boost SQL Server priority)

Данный флаг позволяет повысить приоритет процесса MS SQL Server над другими процессами.

Имеет смысл включать флаг только в том случае, если на компьютере с сервером СУБД не установлен сервер 1С

Для установки флага:

  • Запустить Management Studio и подключиться к нужному серверу
  • Свойства сервера — Процессоры
  • Включить флаг «Поддерживать приоритет SQL Server (Boost SQL Server priority)» и Ок.

Установить размер авто увеличения файлов базы данных

Автоувеличение позволяет указать величину, на которую будет увеличен размер файла базы данных, когда он будет заполнен. Если поставить слишком маленький размер авторасширения, тогда файл будет слишком часто расширяться, на что будет уходить время. Рекомендуется установить значение от 512 МБ до 5 ГБ.

Для установки размера авторасширения необходимо:

  • Запустить Management Studio и подключиться к нужному серверу
  • Свойства нужной базы — Файлы
  • Напротив каждого файла в колонке Автоувеличение поставить необходимое значение

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

Разнести файлы данных mdf и файлы логов ldf на разные физические диски

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

Для переноса файлов:

  • Запустить Management Studio и подключиться к нужному серверу
  • Открыть свойства нужной базы — Файлы
  • Запомнить (записать) имена и расположение файлов
  • Отсоединить базу.
  • Поставить флаг Удалить соединения и нажать Ок
  • Открыть Проводник и переместить файл данных и файл журнала на нужные носители
  • В Management Studio открыть контекстное меню сервера и «Присоединить базу».
  • Нажать кнопку Добавить и указать файл mdf с нового диска
  • В нижнем окне сведения о базе данных в строке с файлом лога нужно указать новый путь к файлу журнала транзакций и нажать Ок

Вынести файлы базы TempDB на отдельный диск

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

Рекомендуется хранить базу TempDB на отдельном диске для повышения производительности работы системы

Для переноса базы TempDB на отдельный диск:

  • Запустить Management Studio и подключиться к нужному серверу
  • выполнить скрипт

ALTER DATABASE tempdb

MODIFY FILE (NAME = tempdev, FILENAME = ‘Новый_Диск:\Новый_Каталог\tempdb.mdf’)

ALTER DATABASE tempdb

MODIFY FILE (NAME = templog, FILENAME = ‘Новый_Диск:\Новый_Каталог\templog.ldf’)

  • Перезапустить MS SQL Server

Включить Shared Memory, если сервер 1С расположен на том же компьютере, что и сервер СУБД

Протокол Shared Memory позволит общаться приложениям через оперативную память, а не через протокол TCP/IP.

Для включения Shared Memory необходимо

  • Запустить диспетчер конфигурации SQL Server
  • Зайти в SQL Native Client — Клиентские протоколы — Общая память — Включено
  • Поставить значение Да и нажать Ок

Протокол Именованные каналы нужно выключить аналогичным образом.

Когда все настройки выполнены, необходимо перезапустить службу MS SQL Server

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

Ваш адрес email не будет опубликован.