Специфика запросов 1С под MS-SQL сервер   

Для начала нужно сказать несколько слов об используемой архитектуре. Во время развития двухуровневых систем (клиент-серверных) распространение получили два варианта размещения бизнес-логики – на клиенте (клиентоцентричная модель) и на сервере (сервероцентричная модель). Остановимся подробнее на клиентоцентричной модели, используемой 1С 7.7. Эта модель клиент-серверной архитектуры была изначально основана на двух предпосылках:

  • Персональные компьютеры являются достаточно дешевыми (это явилось основной движущей силой в развитии клиент-серверной архитектуры);
  • Максимальная производительность достигается с помощью распределения вычислений между сервером и клиентом.

В классической версии клиентоцентричной клиент-серверной модели на сервере выполняются только сервисы данных. Этому в полной мере соответствует модель доступа 1С 7.7.

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

1C-Предприятие может работать с SQL-серверами различных версий. Поддерживается работа с версиями 6.5, 7.0, 2000. Тем не менее, рекомендуется работать именно с версией SQL-2000, так как данная версия является последней на сегодняшний день, обеспечивает наиболее высокую скорость работы и удобство администрирования. Для работы с данной версией SQL-сервера требуется релиз платформы 1C-предприятия не ниже 15-го. Рекомендуется 23-й релиз, как самый новый и не имеющий очевидных ошибок.

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

1C работает с SQL с использованием ODBC (Open Database Connectivity) SQL драйвера. Как правило, большинство обращений к базе данных идет через хранимые процедуры. Используются как собственные хранимые процедуры (пользовательские), так и системные, в том числе расширенные процедуры из базы данных Master , например, exec sp_executesql. Как правило, обработка результатов работы процедуры заключается в выборке данных из курсора.

Еще одна особенность работы 1С с SQL заключается в том, что при внесении изменений в данные какой-то из таблиц происходит блокировка всей таблицы целиком, при этом используются длительные блокировки (HoldLock). Соответственно, пока процесс внесения изменений не будет закончен, другие пользователи не смогут работать с данной таблицей, а если таблица достаточно часто используется, то пользователи не могут не только работать с данной таблицей, но и вообще с базой.

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

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

Отдельно нужно остановиться на работе SQL-запросов в 1С. 1С в своих типовых запросах не использует в полной мере возможности SQL-2000. Это связано с тем, что первый релиз 1С 7.7 мог работать с SQL 6.5, в котором не поддерживались те средства, которые есть в SQL-2000. же пошла по принципу неизменности платформы, не добавляя в новые релизы технологической платформы новые средства с целью совместимости.

Таким образом, можно наблюдать несовершенство работы механизма SQL-запросов 1С на сервере. При работе запроса на серверной части обрабатывается просто запрос на выборку данных. Затем эти данные считываются клиентской частью (опять используется курсор *.CDX *.DBF на компьютере ) и обрабатываются в паре временных файлов клиентской части. В этот момент происходит обработка группировок и подсчитывание функций по группировкам. Это не позволяет ставить клиентские машины минимальной конфигурации в дополнение к мощному серверу. Приходится создавать клиентские места из довольно мощных машин, в то время как серверная часть занята лишь в части работы с выдачей данных. То есть простые функции: записать данные в базу, получить данные из базы – отдать клиенту и т.д.

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

Еще хуже ситуация обстоит при выполнении сложных запросов – не по одному регистру, например, а по нескольким. 1С:Предприятие в этом случае выполняет столько отдельных SQL-запросов, сколько используется регистров в тексте запроса 1С. При этом данные, полученные в результате выполнения этих запросов, перекачиваются на клиентский компьютер путем выборки из курсора, и агрегирование происходит именно на клиенте. Эта конструкция значительно "тормозит" работу 1С, чем при оптимальном выполнении запросов.

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

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

  • Выполнение запроса 1С на SQL-сервере (обычно это делается через процедуру sp_executesql).
  • Выборка данных из получившегося курсора.
  • Создание пары файлов (*.CDX, *.DBF) для размещения результатов запроса и, собственно, размещение в них результатов запроса.
  • Обработка результатов запроса (в этот момент на экране компьютера пользователя отображается соответствующее сообщение). Идет создание группировок с накоплением итогов для запросов. Для временного расчета – эта фаза пропускается.
  • Выборка данных из файла в соответствии с порядком группировок (для запроса).
  • После уничтожения объекта запроса или временного расчета – удаление данных временных файлов.

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

Как видно из описанной процедуры – идет нагрузка на жесткий диск локального компьютера пользователя. А что если в соответствии с общепринятыми понятиями о работе сервероцентричной клиент-серверной архитектуры у пользователя стоит компьютер Celeron-400, ОЗУ-64 и старый медленный винчестер, не поддерживающий DMA режимы? Тогда мы получаем интересные результаты. Стоит мощный многопроцессорный сервер, с большим объемом памяти, мощной SCSI системой ввода-вывода на основе дисковых массивов с аппаратным режимом Raid. При этом совокупная нагрузка на процессоры колеблется в районе 10-15%, дисковая подсистема спокойно отдыхает, достаточно свободной памяти, сеть тоже не показывает перегрузки. И при попытке поиска узкого места на сервере мы сталкиваемся с тем, что с ним (сервером) все в порядке. И, тем не менее, база «тормозит». Спрашивается, в чем дело? А дело в том самом медленном винчестере, процессоре, малом объеме памяти на том самом компьютере пользователя, которому, в соответствии с требованиями сервероцентричной клиент-серверной архитектуры, не требуется быть мощным. Но мы забываем о том, что 1С использует клиентоцентричную модель! Вот такие дела.

Проблема заключается в том, что во время проведения блокируются важные таблицы базы данных. Понятно, что чем меньше длительность блокировки ресурсов, тем скорее другие пользователи смогут к ним обратиться. А так как происходит временный расчет фактически на машине пользователя – то и все остальные пользователи ждут окончания этого процесса, "тормозящего" работу 1С. Чтобы понять порядки задержки – можно просто сравнить производительность дисковой подсистемы сервера (скажем, SCSI RAID-10, состоящий из 4-х дисков на 10-15 тысяч оборотов) и компьютера пользователя – один диск стандарта IDE, на 5400, в лучшем случае на 7200. Мне в практике попадались также и винчестеры Quantum серии 1ct. Это винчестеры на 4500 оборотов в минуту с размером буфера 128 килобайт. И этот винчестер использовался для работы с большой базой данных!

Как известно, правильно поставленный вопрос содержит половину решения. Поэтому, когда возникает вопрос, почему 1С «тормозит» – следует помнить, что слово "клиент-серверный" – содержит в себе понятия и "клиент" и "сервер". Так что не нужно зацикливаться только анализе производительности сервера, а стоит повнимательнее приглядеться и к клиентам.

 


 

Перепечатка, воспроизведение в любой форме, распространение, в том числе в переводе, любых материалов с сайта www.softpoint.ru возможны только с письменного разрешения компании "СофтПоинт". Это правило действует для всех без исключения случаев, кроме тех, когда в материале прямо указано разрешение на копирование (основание: Закон Российской Федерации "Об авторском праве и смежных правах").