v8: Оптимизация скорости работы в 1С 8| Данные операции проводились на базе конфигурации УПП. Структура компании – центральный офис и куча филиалов, пользователи которых работают с серверами по терминалу (VPN). На момент написания статьи средней число активных пользователей – 200, зарегистрированных – 300. | | Автор статьи: vasyaabr | Редакторы:
Последняя редакция №2 от 11.04.08 | История
URL: http://kb.mista.ru/article.php?id=657 | |
Ключевые слова: УПП, оптимизация, скорость, скорость работы, SQL, блокировки, транзакции
Disclaimer (сиречь отмазка):
1. Можете пробовать все, что в этой статье предлагается, но автор за то, что вы можете натворить, ответственности не несет.
2. Автор – программист, вопросами оборудования не занимающийся, т.к. для этого у него всегда были другие люди. Поэтому оборудование может быть освещено довольно слабо, но можно задавать вопросы.
Постараюсь расписать основные вещи, которые нами делались для того, чтобы 200 пользователей комфортно работали в одной базе УПП. Для начала – краткая история проекта.
Структура компании – центральный офис и куча филиалов, пользователи которых работают с серверами по терминалу (VPN). На момент написания статьи средней число активных пользователей – 200, зарегистрированных – 300. Используются практически все подсистемы УПП, за вычетом планирования и бюджетирования.
Вначале всей работы было следующее: связка 1С 7.7 Бухгалтерия (по одной базе для каждого филиала) + 1С 8.0 Управление Торговлей, на всю компанию. Было решено (по разным причинам, одна из которых – дикие трудозатраты на перенос данных в Бухгалтерию 7.7) перейти на одну общую базу – УПП 8.0. Было принято решение работать с аутсорсером, о котором впоследствии не пожалели – работа была проведена грамотно, и хотя ляпы были – но в удовлетворительном количестве. Затем с аутсорсинга слезли, и на данный момент система поддерживается своими силами, привлекая, в сложных с точки зрения налогового и бухгалтерского учета, консалтинговые компании. Соответственно, ряд решений, которые я упомяну – результат помощи аутсорсера, прочие – наши личные эксперименты, решения и находки после вдумчивого чтения форумов и users.v8.1c.ru.
1. Аппаратная часть.
Начинали со следующей структуры: терминальные сервера + основной сервер, на котором был установлен сервер приложений 1С 8.0 и Microsoft SQL Server 2000. Минусов у такой структуры хватает, и основной – то, что сервер приложений и сервер баз данных – на одной машине. Также, несмотря на кажущееся слабое различие между версиями SQL 2000 и 2005 по итогам тестирования производительности выявили, что 2005-й сервер работает с 8-кой – быстрее, хоть и не очень значительно.
В итоге, серверная структура выглядела так:
SQL-сервер: 64-х разрядный, 2 4-х ядерных процессора Xeon 1.6, 8 гигов оперативки, RAID-5, MS SQL-2005 Enterprise 64-bit.
Сервер приложений: 2 2-х ядерных процессора Xeon 3.4, 4 гига оперативки.
Терминальные сервера (на данный момент 6 штук): 1 двуядерный процессор Xeon 3.4,8 гигов оперативки.
OS – Ms Windows 2003 Enterprise Server – на всех серверах. О последних сервис-паках и обновлениях на все ПО я даже и не говорю – это обязательно.
Все это увязано между собой гигабитным соединением.
Пользователи - все через терминал, в основном – на тонких клиентах.
Как эта конфигурация просчитывалась:
1. Мощность SQL-сервера подсказали аутсорсеры – по примеру одного из своих клиентов. Мы, правда, поставили на него в два раза меньше оперативной памяти, чем нам советовали, но пока не жалуемся – 16 гигов должно было хватить на 500-800 пользователей, мы же столько не закладывали на тот момент.
2. Сервер приложений взят на авось – основываясь на рекомендациях 1С и собственных фантазиях.
3. С терминальными серверами проще, основное там – оперативная память. Сначала надо сосчитать, сколько памяти использует один подключившийся пользователь, а потом умножить на прогнозируемое количество пользователей, получим общий пул памяти. Этот пул делим на количество серверов, и получаем количество памяти на 1 сервер (грубо). Терминальные сервера объединяем в кластер.
Проблемы, желания и идеи:
1. Система балансирования нагрузки терминальных серверов работает слабо, бывает что на одном сервере – 30 человек, на другом – 5. То ли у нас руки кривые, то ли надо искать подобное ПО стороннего производителя.
2. С RAID-5 перейти RAID-10. Отдача дисковой системы должна заметно повыситься.
3. Удвоить оперативную память SQL-сервера, чтобы больше не думать о ней.
4. Добавить файл-сервер для хранения бэкапов (уже купили, но еще не доехал).
2. Логическое размещение данных.
Маленький, но важный пункт. Для еще большей отдачи дисковой системы, желательно поместить файл лога транзакций рабочей базы SQL-сервера на отдельный физический диск монопольно, чтобы на этом диске больше ничего не было, и ничего туда/оттуда не копировалось кроме данных из базы. С файлом данных это проделывать не обязательно, т.к. основная работа идет с файлом транзакций. К сожалению, мы не смогли достаточно долго мерить результаты этой операции, т.к. пришлось забить этот диск некоторыми данными, и продолжим эксперимент по приезде файл-сервера
Проблемы, желания и идеи:
Воспользовавшись механизмом файловых групп (File Groups) Ms SQL, можно попробовать разбить файл данных на части, и в эти части поместить самые востребуемые таблицы. Если разнести эти составные файлы на разные физические диски – то можно добиться прироста в производительности. Идея еще очень сырая, возможно, я неправильно выразился.
3. Оперативная память.
Совсем короткая ремарка: как мы думаем, проблемы с сервером приложений возникают из-за сильной фрагментации оперативной памяти. Помимо просто понижения быстродействия, сюда же можно отнести сбои при обновлении / резервировании и восстановлении данных / динамическом обновлении / создании файлов поставки и пр. Решения два:
1. Регулярно физически перезагружать сервер. Перезапуск процесса не помогает. В нашем случае – хватает раза в двое-трое суток.
2. Использовать софт для дефрагментации оперативной памяти. Это мы только планируем тестировать и внедрять.
4. Настройка SQL-сервера.
Не буду здесь касаться настроек базы данных и сервера – мы их практически не меняли, использовали как есть. Скажу пару слов о регулярных процедурах.
Помимо бэкапов, важно проводить и другие процедуры на SQL-сервере – пересоздание и дефрагментацию индексов, обновление статистики, урезание базы. Наиболее заметное улучшение результатов работы дала ежедневная дефрагментация индексов: помимо ускорения, она еще и высвобождает свободное место в базе, занимаемое «лишними» индексами. Единственный минус – лог транзакций в результате этой процедуры растет.
Пример расписание задач нашего SQL-сервера:
00:00
Каждый понедельник - полный бэкап, удаление устаревших дифференциальных бэкапов (старше двух недель), обрезание файлов базы, проверка базы на целостность.
Ежедневно кроме понедельника - дифференциальный бэкап, удаление устаревших транзакционных бэкапов (старше недели), обрезание файлов базы.
02:00
Пересоздание индексов.
04:00
Обновление статистики.
06:00 - 21:00
Каждый час - создание транзакционного бэкапа.
13:05
Полная дефрагментация индексов.
Если график работы компании не позволяет делать в середине рабочего дня полную дефрагментацию (т.к. она, пусть и незначительно, но замедляет работу, и может продолжаться полчаса-час), то можно делать выборочную дефрагментацию самых загруженных таблиц. Об этом немного сказано на users.v8.1c.ru (http://users.v8.1c.ru/Adm1794.aspx).
5. Перепрограммирование УПП.
Здесь мы вели оптимизацию тремя путями:
1. Разбор и устранение имеющихся блокировок.
Сошлюсь снова на статью «Анализ блокировок с помощью SQL Trace» (http://users.v8.1c.ru/Adm1738.aspx) – там все доступно и понятно. Мы слегка дописали предложенный запрос, чтобы сразу видеть название конфликтной таблицы:
USE <имя_вашей_базы_данных>
SELECT OBJECT_NAME(ObjectID)
FROM
(SELECT locks.ObjectID
FROM [TechnicalAnalysis].[dbo].[locks] AS locks
GROUP BY locks.ObjectID) AS locks
База [TechnicalAnalysis] – создана для хранения результатов трассировки.
А проассоциировать имя таблицы в SQL с конкретным объектом конфигурации можно, например, с помощью Enterprise Manager – там можно просмотреть список объектов и их имена в SQL-базе.
По поиску и устранению причины блокировки готовых рецептов нет, возможные способы - упрощать и оптимизировать запросы, менять структуру регистров, добавлять новые индексы. Совсем радикально – писать прямой запрос к базе, но до такого мы еще не доходили. Обычно все заканчивается на обработке запросов и добавлении индексов.
Приведу пример: есть такой регистр «Права доступа пользователей к объектам». В результате настройки доступа к справочнику контрагентов для каждого пользователя, он разбух до 4 миллионов строк, а так как обращения к нему идут очень часто – начались постоянные блокировки. Решить проблему удалось без переписывания конфигурации – просто настроили права доступа через справочник «Группы пользователей».
2. Поиск и устранение потенциальных «узких» мест.
Здесь мы проглядываем таблицы с большим количеством записей (более 1 миллиона), и таблицы, обращение к которым идет очень часто. Методика такая же: упрощать и оптимизировать запросы, менять структуру регистров, добавлять новые индексы.
Возможно, с помощью SQL Trace, можно более удобно определить, какие таблицы наиболее часто читаются / записываются, но пока что мы делаем это исходя из знания конфигурации и наиболее используемых документов.
Выбирать самые крупные таблицы удобно с помощью отчета Ms SQL “Disk Usage by Top Tables”.
3. Отключение не нужного функционала.
В нашем случае, т.к. не использовались характеристики, серии номенклатуры, качество – мы прошлись по всем процедурам контроля остатков и урезали запросы и алгоритмы их составления. Была сильно урезана процедура запуска конфигурации и отключены практически все висящие обработчики (подобные же рекомендации даны фирмой 1С в статье по переходу с 8.0 на 8.1). Проведение по некоторым регистрам можно отключить вовсе – если данные из этих регистров не требуются и не затронут другие подсистемы и механизмы.
Послесловие.
Мы не использовали "модных" сейчас механизмов, вроде нагрузочного тестирования, управляемых блокировок, и т.д., все делалось на живой базе в рабочем режиме и жуткой спешке.
Во время начала работы проблемы были достаточно серьезные - тысячи блокировок в день, иногда - очерердь из блокировок, которую удавалось убрать только перезапуском сервера 1С. Крайне медленная реакция УПП на некоторые действия, проведение документов по несоколько минут на штуку.
Как итог наших действий: отсутствие блокировок (иногда можно поймать 3-4, но не каждый день), среднее время проведения документа 5-10 секунд.
Я надеюсь, что эта статья поможет вам достичь успехов не меньших и приумножить их. Спасибо за прочтение.
Абросимов Василий. |