Как обеспечить необходимое быстродействие систем «1С:Предприятие»

Роман Марков

Как обеспечить необходимое быстродействие систем «1С:Предприятие»

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

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

Подробнее о проблеме

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

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

Общие модели доступа к БД «1С:Предприятие»

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

Файл-серверная версия использует файлы в формате DBF. Основное ее преимущество заключается в том, что не требуется дополнительного программного обеспечения для организации работы, так как для подключения к базе данных достаточно предоставить папку с ее файлами в общий доступ, что достигается средствами любой сетевой операционной системы. Этот формат разрабатывался прежде всего для работы с БД небольшого размера при малой нагрузке. Поэтому при активной работе нескольких пользователей с базой данных наблюдается значительное замедление работы программы. Особенно если кто-нибудь из пользователей запустит построение масштабных отчётов за большой период времени. О причинах этого замедления я расскажу немного позже, так как именно они мотивируют переход к использованию терминального решения в файл-серверной версии системы «1С:Предприятие».

Второй тип организации доступа к базе данных системы «1С:Предприятие» – клиент-серверная модель. В клиент-серверной версии таблицы хранятся в базе данных под управлением Microsoft SQL Server, и клиентское приложение не открывает файлы базы данных при каждом новом подключении, а посылает запрос серверу баз данных (SQL server). Запрос обрабатывается самим SQL-сервером, который считывает данные из своей базы и выдает клиентскому приложению только необходимую их часть. Таким образом взаимодействие «клиент-сервер» сводится к отправке на сервер запроса и получения ответа, содержащего уже отсортированные данные вместо самостоятельного считывания клиентом файлов БД по сети. Это уменьшает сетевой трафик и увеличивает быстродействие в сравнении с файл-серверной моделью при большом количестве активных пользователей и значительном объеме БД. То есть для клиент-серверной версии время реакции на запросы пользователей при возрастании количества активных пользователей не возрастает так резко, как это происходит с файл-серверной моделью. Однако не стоит забывать, что SQL-версия изначально ориентирована именно на надежность обработки больших объемов данных, хранение которых в файл-серверной модели чревато разрушением БД, а не на увеличение скорости работы с приложением (во всяком случае, это относится к сочетанию «1С:Предприятие» – Microsoft SQL Server). Поэтому при малых размерах БД или небольшом количестве активных пользователей SQL-версия проигрывает по скоростным показателям файл-серверной. Это можно увидеть на примерном графике соотношения.

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

График зависимости времени реакции системы от количества активных пользователей

SQL-сервер хранит данные в другом формате. Главное принципиальное отличие состоит в том, что при необходимости SQL-сервер обеспечивает откат транзакций, аварийно завершившихся по каким-либо причинам. То есть в начале любой операции по внесению изменений в БД SQL-сервер записывает состояние изменяемого объекта до проведения изменения и отслеживает успех операции. В случае аварийного завершения этой операции объект не изменяется и возвращается в предыдущее стабильное состояние. В случае аварийного завершения операции по изменению файла DBF информация в нем остается «как есть», что может привести к неработоспособности БД.

Поэтому для обеспечения максимальной надежности хранения больших БД и исключения возникновения транзакций рекомендуется использовать клиент-серверную модель.

В «1С:Предприятии 8.0» используется трёхуровневая архитектура «клиент-сервер», при которой клиентская часть обращается к серверу приложений 1С, а он в свою очередь обращается к серверу баз данных Microsoft SQL Server, который и обрабатывает запросы к информационной базе. Сервер приложений 1С сосредотачивает на себе выполнение объемных и сложных операций, при этом клиентская часть будет получать необходимую ей выборку. Ресурсы современных серверов позволяют расположить и сервер приложений и сервер БД на одном физическом сервере, что, несомненно, ускоряет обработку запросов, однако создает двойную нагрузку на ресурсы. К сожалению, именно к этому нас вынуждают схемы взаимодействия клиентов систем «1С:Предприятие» с их серверами.

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

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

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

1. Увеличение размера информационных БД: это естественное следствие штатной работы с БД, размер которой зависит от количества введенных документов, однако есть некоторые нюансы. Если компания ведет непрерывный учет всех документов за весь период работы БД, то ее размер при интенсивном документообороте может вырасти до критического за очень небольшой период. Напоминаю, что мы рассматриваем условную величину «критичности» размера БД в файл-серверном варианте, равную 2 Гб. Для клиент-серверной модели это понятие (в разумных пределах), в общем-то, не имеет значения. В случае если компания не собирается переходить к клиент-серверному варианту доступа к БД, ей приходится принимать меры по свертке таких баз, путем закрытия отчетных периодов и переноса остатков на начало нового периода. При этом все документы, предшествующие началу нового периода, из базы удаляются. Именно на это я и хотел бы обратить ваше внимание. Даже после удаления неактуальных документов из БД ее размер не изменится! Причина заключается в структуре данных, используемой для хранения БД. При удалении документов из базы на физическом уровне происходит только удаление ссылок на эти документы. Само место, зарезервированное под эти записи, в файлах БД остается занятым. Из-за этого и не меняется размер БД сразу после очистки всех помеченных на удаление записей. Для физического сжатия файлов БД необходимо выполнить «Упаковку таблиц БД». Для системы «1С:Предприятие 7.7» это можно сделать из конфигуратора, выбрав в меню «Администрирование» пункт «Тестирование и исправление ИБ». Будьте осторожны с этой процедурой! Ее необходимо проводить только после того, как вы сделали архивную копию БД и провели ее полное тестирование и исправление. Для больших БД данный процесс продолжителен и в зависимости от быстродействия компьютера может занимать до 3-5 суток!
2. Увеличение количества активных пользователей БД: тут таких советов, как в предыдущем пункте, дать не получится, так как «Упаковку пользователей» производить запрещено законом… Так что с этим остается только смириться и следовать другим советам по увеличению производительности системы.
3. Недостаточная производительность серверов и рабочих станций: особых хитростей здесь нет, кроме того, что вы должны быть уверены, что замедление работы является следствием недостаточности ресурсов, а не других причин, о которых будет сказано в разделе организации терминального доступа к БД.
4. Низкая пропускная способность локальной сети: для обеспечения достаточного быстродействия необходимо, чтобы пропускная способность сети составляла 100 мегабит от клиента до сервера БД (это требование не относится к варианту с сервером терминалов – там достаточно 50-100 килобит(!) в сек. для каждого из клиентов. Для 3-уровневой системы обработки «1С:Предприятие» при разнесении сервера приложений 1С и SQL-сервера по физически разным серверам рекомендуется максимально увеличить скорость их взаимодействия между собой. Нелишним окажется установить в каждый сервер по два и более гигабитных сетевых адаптера и соединить их через гигабитный коммутатор, объединив сетевые адаптеры в транк с поддержкой балансировки нагрузки.
5. Зависимость от уровня профессионализма программистов: нередко встречаются случаи, когда отдельные нестандартные процедуры, написанные программистами вручную, работали медленно из-за нерационального подхода к анализу данных и затормаживали работу остальных пользователей с БД. И наоборот – вручную переписанные талантливым программистом обработки давали неимоверную производительность даже в простом файл-серверном варианте. При использовании клиент-серверной модели максимальной производительности можно достичь, обрабатывая записи БД непосредственно средствами SQL. Однако не все программисты умеют это делать, а признаться в этом не решаются.
6. Некорректная настройка IT-инфраструктуры техническими специалистами и отсутствие у техперсонала знаний о возможностях оптимизации информационной системы: здесь все зависит от глубокого понимания IT-специалистами происходящих в сети процессов. Помимо общих канонов настройки локальной сети, необходимо учитывать множество факторов. Например, частой ошибкой технических специалистов является отсутствие тонкой настройки антивирусных мониторов. Чаще всего оставляют настройки по умолчанию, что для многих антивирусных продуктов означает постоянную проверку всех подключенных сетевых ресурсов, а также абсолютно всех файлов. Рекомендуется исключать из проверки файлы БД, так как наличие в них вирусов – очень маловероятное событие. А вот постоянная проверка файлов метаданных (*.md), структуры метаданных (*.dd) и файлов БД 1С *.dbf и *.cdx замедлят работу всей вашей системы в несколько раз.

Замедление работы файл-серверной модели БД на серверах с Windows

Итак, мы добрались до рассмотрения технологии терминального доступа, ее преимуществ и причин, по которым ее применение позволяет максимально ускорить работу с БД.

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

Итак, в чем же заключается эта особенность, из-за которой резко замедляется работа с сетевой БД при одновременной работе с ней более чем одного пользователя? То есть при работе в однопользовательском режиме, даже по сети, скорость работы оказывается приемлемой, однако стоит хотя бы еще одному пользователю начать работу с БД, как скорость формирования отчетов и проведения документов падает в несколько раз, а то и на порядок. Это происходит из-за того, что система Windows отключает кэширование дисковых операций при подключении к сетевому ресурсу более чем 1 пользователя. Делается это во избежание потери данных из-за взаимных блокировок, однако сильно страдает производительность системы.

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

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

На компьютеры пользователей устанавливается только терминальный клиент, задача которого инициировать и поддерживать сеанс связи со сервером терминалов. Именно поэтому не имеет значения, какой компьютер установлен у клиента – единственная его задача – запустить клиентскую часть, которая будет нормально работать даже на 486-м компьютере с 16 Мб памяти и любой ОС, для которой существует клиент сервера терминалов Windows.

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

Серьезным расширением возможностей стандартного сервера терминалов Windows является продукт Citrix Metaframe. Он предоставляет возможность сделать работу с терминальным приложением абсолютно прозрачным для пользователя и для удобства позволяет подключить и собственные ресурсы компьютера. Например, подключение к сеансу пользователя его локальных принтеров, на мой взгляд, в Citrix Metaframe организован более удобно. Однако следует учитывать что Citrix Metaframe является только дополнением к стандартному серверу терминалов MS, а не самостоятельным продуктом. Да и стоимость данного «расширения» велика по сравнению с применением стандартного сервера терминалов от Microsoft. К слову, саму технологию Terminal Services компания Microsoft купила именно у компании Citrix.

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

Помимо ускорения работы с БД неоспоримым преимуществом терминал-сервера является сжатие передаваемой по сети информации, что позволяет работать с программой через медленные каналы связи. Именно такая модель доступа позволяет организовать удаленную работу филиальных отделов с единой БД в режиме online – ведь для каждого клиента достаточно канала передачи данных шириной 40-60 Кбит/сек. Таким образом, при необходимости предоставить филиальным представительствам доступ к центральной БД (или наоборот) достаточно обладать сервером необходимой мощности для организации на нем сервера терминалов и каналом связи с указанной выше пропускной способностью.

Сколько стоит такое терминальное решение?

Итак, принимая решение о переходе на терминальную схему работы системы «1С:Предприятие», необходимо учитывать, что для организации работы сервера в режиме сервера приложений необходимо приобрести лицензии клиентского доступа к нему. Каждая лицензия «на устройство» (MS TS CAL) обойдется вам около 80 $. Сам сервер терминалов входит в стоимость лицензии Windows Server.

Расширение Citrix Metaframe стоит от 2000 USD за стартовый пакет из 5 лицензий. Каждые последующие 5 лицензий будут стоить около 1500 $.

Поэтому (это мое субъективное мнение) покупка MS TS CAL – абсолютно оправдана, так как ускорение работы системы при этом предоставит новые возможности расширения бизнеса.

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

Комментарии могут оставлять только зарегистрированные пользователи