Разнесение сервера приложений 1С и сервера систем управления базами данных (СУБД) на разные физические компьютеры — стандартный шаг при масштабировании ИТ-инфраструктуры. Однако довольно часто эта схема преподносит неприятный сюрприз в виде резкого падения производительности. Типичный симптом: проведение документов начинает занимать слишком много времени, а при одновременной работе двух баз одна из них работает приемлемо, тогда как вторая начинает «жестко тупить». При этом монитор ресурсов СУБД может показывать минимальную загрузку дисков и процессора.
В этой статье мы подробно разберем, почему возникает этот эффект, проанализируем неочевидные «узкие места» в архитектуре MS SQL Server и платформы 1С, а также по шагам настроим систему для достижения максимального быстродействия без дорогостоящей покупки нового оборудования.
Давайте проанализируем поведение СУБД, когда на одном сервере крутятся две базы данных объемом 65 ГБ и 92 ГБ (суммарно 157 ГБ), а под нужды MS SQL Server выделено всего 78 ГБ оперативной памяти. В такой конфигурации мы неизбежно сталкиваемся с критической проблемой — вымыванием буферного пула (Buffer Pool Thrashing).
Рассмотрим детально, как СУБД работает с оперативной памятью:
Этот процесс называется «штормом кэша». В результате дисковая подсистема постоянно занята бесполезным чтением и записью страниц памяти туда-обратно, а показатель Page Life Expectancy (PLE) — ожидаемое время жизни страницы памяти в секундах — падает практически до нуля. Это парализует работу обеих баз данных.
Проверить состояние PLE на вашем сервере СУБД можно с помощью следующего запроса в MS SQL Server Management Studio:
SELECT [object_name], [counter_name], [cntr_value]
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Buffer Manager%'
AND [counter_name] = 'Page life expectancy';
Если полученное значение во время активной работы пользователей опускается ниже 300–500 секунд, это явный сигнал о критическом дефиците памяти под кэш СУБД.
Обратим внимание на модель процессора СУБД. Например, четырехъядерный Intel Xeon E5-2407 имеет базовую частоту всего 2.2 ГГц и полностью лишен технологии Turbo Boost. Это критически важное узкое место для СУБД, обслуживающей базы 1С.
Специфика работы платформы 1С такова, что транзакционные операции (включая проведение документов) выполняются строго в один поток. Следовательно, скорость проведения документов напрямую зависит от производительности одного ядра процессора (Single-Thread Performance). Низкая тактовая частота процессора 2.2 ГГц физически не способна быстро обрабатывать тяжелые математические расчеты и транзакции СУБД в современных конфигурациях 1С (особенно в отраслевых решениях по расчету квартплаты ЖКХ, где за один месяц в регистры записываются миллионы строк).
При этом общий показатель загрузки процессора в диспетчере задач может выглядеть безобидно (например, 25% на 4-ядерном процессоре), однако это означает, что одно ядро загружено на все 100% выполнением одной тяжелой транзакции, а остальные ядра простаивают.
Для исправления ситуации выполним комплекс настроек на уровне операционной системы, MS SQL Server, локальной сети и кластера серверов 1С.
По умолчанию база временных таблиц tempdb часто располагается на системном диске С вместе с операционной системой. Платформа 1С генерирует колоссальное количество временных таблиц при проведении документов и формировании отчетов. Работа tempdb на одном диске с ОС приводит к огромным задержкам.
Выполним перенос базы tempdb на отдельный физический диск (желательно SSD) и оптимизируем количество ее файлов:
tempdb должно быть строго равно числу логических ядер процессора (в нашем случае — 4 файла). Это предотвратит взаимные блокировки при записи во временные таблицы (allocation bottlenecks).Применим изменения с помощью SQL-скрипта:
USE master;
GO
-- Переносим основной файл данных
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'D:\SQL_TempDB\tempdb.mdf', SIZE = 1024MB, FILEGROWTH = 256MB);
GO
-- Переносим лог транзакций
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'D:\SQL_TempDB\templog.ldf', SIZE = 512MB, FILEGROWTH = 128MB);
GO
-- Добавляем дополнительные файлы данных (для 4-ядерного процессора создаем еще 3 файла)
ALTER DATABASE tempdb ADD FILE (NAME = tempdev_2, FILENAME = 'D:\SQL_TempDB\tempdb_2.ndf', SIZE = 1024MB, FILEGROWTH = 256MB);
ALTER DATABASE tempdb ADD FILE (NAME = tempdev_3, FILENAME = 'D:\SQL_TempDB\tempdb_3.ndf', SIZE = 1024MB, FILEGROWTH = 256MB);
ALTER DATABASE tempdb ADD FILE (NAME = tempdev_4, FILENAME = 'D:\SQL_TempDB\tempdb_4.ndf', SIZE = 1024MB, FILEGROWTH = 256MB);
GO
Для вступления изменений в силу потребуется перезапустить службу MS SQL Server.
Для MS SQL Server 2008 критически важно прописать в параметрах запуска службы флаги трассировки -T1117 (одновременное расширение всех файлов в группе) и -T1118 (выделение полных экстентов вместо смешанных). Это полностью решит проблему конкуренции за SGAM-страницы распределения памяти.
В отраслевых базах 1С пользователи часто сталкиваются с взаимными блокировками при проведении документов. По умолчанию MS SQL Server использует классический режим блокировок, при котором читающие запросы (например, построение отчета) блокируют запись новых данных, а пишущие транзакции (проведение документа) заставляют читателей ждать.
Переведем базы данных в режим Read Committed Snapshot Isolation (RCSI). В этом режиме читающие транзакции будут получать согласованную версию данных из базы tempdb, не накладывая блокировок на таблицы. Это кардинально ускорит проведение документов при параллельной работе пользователей.
Для включения режима RCSI выполним следующий скрипт (предварительно монопольно отключив всех пользователей от базы данных):
-- Переводим базу в однопользовательский режим, сбрасывая активные соединения
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
-- Включаем режим версионирования строк
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
GO
-- Возвращаем многопользовательский режим обратно
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
GO
Внимание: использование RCSI повышает нагрузку на базу tempdb, поэтому выполнение первого шага по оптимизации и переносу tempdb на быстрый SSD является обязательным условием!
Проанализируем состояние сервера приложений 1С. По умолчанию кластер 1С может направлять запросы к разным информационным базам в один и тот же рабочий процесс rphost.exe. Это приводит к тому, что кэш метаданных и оперативная память разных баз смешиваются в рамках одного процесса. База, запущенная первой, захватывает ресурсы процесса, а сеансы второй базы начинают ожидать своей очереди.
Настроим изоляцию информационных баз на сервере приложений 1С:
Благодаря этой настройке сервер 1С будет принудительно создавать индивидуальные процессы rphost.exe под каждую информационную базу. Это исключит взаимное влияние баз друг на друга на уровне сервера приложений.
Когда сервер 1С и СУБД разнесены по разным компьютерам, сетевые задержки (Network Latency) начинают оказывать колоссальное влияние на производительность. При проведении одного документа 1С может отправлять к СУБД десятки тысяч мелких SQL-запросов. Если сетевая задержка на один пакет составляет даже 1 миллисекунду, суммарное время ожидания сети при проведении документа составит десятки секунд!
Для минимизации задержек выполним следующие действия:
Выполнив указанные шаги, мы решим проблему производительности на системном уровне:
rphost.exe на сервере 1С, чтобы базы не мешали друг другу.tempdb, устранив дисковые задержки СУБД.Эти действия позволят выжать максимум из имеющегося серверного оборудования и обеспечат комфортную работу пользователей без затрат на покупку дорогостоящего железа.