После обновления 1С:Бухгалтерия КОРП до версии 3.0.121.23 вы можете столкнуться с существенным снижением производительности всей системы. Например, формирование отчета «Оборотно-сальдовая ведомость» может занимать от 10 до 40 секунд, а проведение документов — заметно дольше обычного. При этом на SQL-сервере наблюдается практически постоянная загрузка процессора на уровне 90-98%. Давайте рассмотрим эту ситуацию подробнее и разберем, какие шаги можно предпринять для устранения проблем.
Исходные данные по системе:
_AccRg561): порядка 28 миллионов.SIMPLE.Первоначально проблемы производительности часто связаны с недостатком или некорректной настройкой аппаратных ресурсов. Рассмотрим ключевые компоненты.
Процессоры Intel Xeon Silver 4215 @ 2.50GHz (два процессора) могут оказаться недостаточными для сервера 1С с высокой нагрузкой (150-220 активных сеансов и база данных объемом 370 ГБ). 1С-запросы часто требовательны к тактовой частоте процессора, и даже при наличии множества ядер, низкая базовая частота может стать узким местом. Мы рекомендуем рассмотреть процессоры с более высокой тактовой частотой и большим количеством ядер, чтобы обеспечить лучшую обработку параллельных запросов.
Для объективной оценки производительности вашего процессора мы можем использовать бенчмарки, например, утилиту CPU-Z. Это позволит сравнить текущую производительность с эталонными значениями и определить, является ли ЦПУ действительно слабым звеном.
Изначально выделенные 64 ГБ оперативной памяти для двух крупных баз данных (370 ГБ 1С:Бухгалтерия КОРП и 45 ГБ 1С:ЗУП) при 170-220 активных пользователях — это явно недостаточно. SQL Server активно использует оперативную память для кэширования данных и планов запросов. Нехватка памяти приводит к тому, что SQL Server вынужден гораздо чаще обращаться к дисковой подсистеме, что является значительно более медленной операцией и приводит к общему замедлению работы.
Мы выяснили, что увеличение оперативной памяти с 64 ГБ до 128 ГБ на SQL-сервере привело к немедленному улучшению ситуации. Это подтверждает, что ОЗУ было серьезным узким местом. Однако, даже 128 ГБ может быть недостаточно, чтобы все активно используемые таблицы поместились в оперативную память. Мы рекомендуем постоянно мониторить использование ОЗУ и, при необходимости, рассмотреть дальнейшее увеличение, если ресурсы позволяют.
Использование дисков SAS 10k для базы данных объемом 370 ГБ и интенсивной пользовательской работы (150-220 сеансов) является критически важным узким местом. Для обеспечения оптимальной производительности 1С+SQL Server крайне необходима быстрая дисковая подсистема. Медленные диски вызывают рост очередей к диску, что приводит к значительному замедлению работы, даже если процессор и память достаточны.
Мы настоятельно рекомендуем перейти на SSD-накопители. Для максимальной производительности лучше использовать NVMe SSD для файлов данных и логов SQL Server. Мы также можем рассмотреть возможность разнесения файлов данных (.mdf) и файлов журналов транзакций (.ldf) на разные физические диски/массивы SSD для повышения параллелизма операций ввода-вывода. Проверить реальную производительность дисковой подсистемы можно с помощью бенчмарка CrystalDiskMark, особенно обращая внимание на скорость работы с 4k блоками.
Если сервер является виртуальной машиной, это накладывает дополнительные требования к компетенции системных администраторов в тонкой настройке гипервизора и самой виртуальной машины. Мы должны убедиться, что для виртуальной машины выделены эксклюзивные, не разделяемые с другими ВМ, ресурсы (CPU, RAM). Также крайне важно, чтобы дисковая подсистема виртуальной машины не являлась общим ресурсом, перегруженным другими виртуальными машинами. Настройки паравиртуализации для дисков и сети могут также существенно влиять на производительность. Подробные рекомендации по настройке виртуальных машин для 1С и SQL Server можно найти в специализированных статьях, посвященных оптимизации виртуализации.
Правильная настройка SQL Server критична для производительности 1С.
Параметр MAXDOP определяет максимальное количество ядер процессора, которое SQL Server может использовать для распараллеливания выполнения одного запроса. Для 1С часто рекомендуется устанавливать MAXDOP=1. Почему так? Многие запросы 1С неэффективно используют распараллеливание на большое количество ядер, а иногда могут работать даже медленнее из-за накладных расходов на координацию между ядрами.
Мы видим, что эксперименты с MAXDOP на вашем сервере показали, что установка значения 16 привела к полному зависанию, а 8 ядер улучшило ситуацию, но не до конца. Мы предлагаем попробовать установить MAXDOP=1. Это может значительно улучшить производительность для некоторых типов запросов, поскольку один сложный запрос будет обработан одним ядром максимально быстро, избегая накладных расходов, связанных с распределением задачи между многими ядрами. Например, один отчет от одного пользователя может загрузить одно ядро эффективно, вместо того чтобы пытаться распределить нагрузку по множеству ядер, где каждый поток будет ждать данных от другого. Дополнительную информацию и обоснование этого параметра можно найти на портале ИТС 1С.
Мы выяснили, что ваша база данных использует модель восстановления SIMPLE. Это крайне не рекомендуется для продуктивных баз данных. Модель SIMPLE позволяет восстанавливать базу данных только к моменту последнего полного или разностного резервного копирования. В случае сбоя мы рискуем потерять все данные за период между последним бэкапом и моментом сбоя. Для критически важных баз данных, таких как 1С:Бухгалтерия КОРП, рекомендуется использовать модель восстановления FULL. С моделью FULL и регулярным копированием журналов транзакций мы можем восстановить базу данных к любой произвольной точке во времени (Point-in-Time Recovery), минимизируя потери данных.
Если модель SIMPLE была выбрана администраторами для предотвращения разрастания лог-файлов, то это является некорректным решением. Вместо этого, мы должны настроить регулярное резервное копирование журналов транзакций, которое и будет управлять их размером. После перехода на модель FULL, обязательно настройте регулярное копирование журнала транзакций (например, каждые 15-30 минут) помимо ежедневных полных бэкапов. Это позволит контролировать размер лог-файла и обеспечить надежное восстановление.
Используемая версия SQL Server 2012 является устаревшей. Обновление SQL Server до более новой версии (например, SQL Server 2016, 2019 или 2022) может принести существенные улучшения производительности. Новые версии SQL Server содержат оптимизации в работе оптимизатора запросов, улучшения производительности для определенных типов запросов, а также лучшую работу с современным оборудованием. Мы можем рассмотреть этот шаг как часть общего плана по повышению производительности.
Даже с мощным оборудованием и правильно настроенным SQL Server, проблемы могут быть в самой базе данных 1С.
_AccRg561 (Регистр бухгалтерии)Таблица регистра бухгалтерии _AccRg561 с 28 миллионами записей является одной из самых больших и часто используемых. Само по себе это количество записей не является аномально большим для SQL Server, при условии, что индексы правильно настроены и эффективно используются. Мы выяснили, что именно запросы к этой таблице оказываются самыми "тяжелыми".
Если SQL Server сообщает об отсутствии индексов или их неиспользовании, это критично. Кластерный индекс в таблице должен быть всегда, а SQL Server сам решает, использовать его или другие индексы при выполнении запроса, основываясь на статистике, наличии достаточной оперативной памяти и параметрах запроса. Если индексы не используются, SQL Server вынужден выполнять полное сканирование таблицы, что очень медленно.
Регламентные задания по переиндексации и обновлению статистики должны выполняться регулярно и корректно. Однако, если после переиндексации база всё равно показывает отсутствие индексов (как было в вашем случае с запросом на MissingIndexes), это может указывать на проблему с самим процессом обслуживания или на некорректную работу оптимизатора запросов SQL Server в данных условиях.
Для детальной диагностики мы можем использовать следующий SQL-запрос, чтобы найти наиболее ресурсоемкие запросы и их планы выполнения. Этот запрос поможет нам понять, почему индексы не используются или какие индексы еще могут быть полезны:
SELECT TOP 100 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.text)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC
А также запрос, специально разработанный для выявления запросов, использующих пропущенные индексы:
SELECT
qs_cpu.total_worker_time / 1000 AS total_cpu_time_ms,
q.[text],
p.query_plan,
qs_cpu.execution_count,
q.dbid,
q.objectid,
q.encrypted AS text_encrypted
FROM
(SELECT TOP 500 qs.plan_handle,
qs.total_worker_time,
qs.execution_count FROM sys.dm_exec_query_stats qs ORDER BY qs.total_worker_time DESC) AS qs_cpu
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS q
CROSS APPLY sys.dm_exec_query_plan(plan_handle) p
WHERE p.query_plan.exist('declare namespace
qplan = "http://schemas.microsoft.com/sqlserver/2004/07/showplan"; //qplan:MissingIndexes')=1
Эти запросы помогут нам проанализировать планы выполнения и выявить конкретные индексы, которые SQL Server считает необходимыми, но не обнаруживает или не использует эффективно.
Свертка базы данных, особенно старых данных (например, свернуть 7 лет из 10), может значительно уменьшить размер базы и ускорить работу, поскольку SQL Server будет обрабатывать меньший объем данных. Мы можем рассмотреть этот вариант как потенциальное долгосрочное решение.
Существуют "лайт-версии" свертки, которые затрагивают только движения регистров, оставляя документы проведенными. Например, можно обрабатывать регистр бухгалтерии Хозрасчетный частями (помесячно) в ночное время, удаляя движения по организациям до определенного года (например, 2020) и вводя остатки операцией вручную. Однако, это сложная и рискованная операция, требующая тщательного планирования и тестирования на копии базы, так как проведенный документ без движений может вызвать проблемы при попытке его изменить или перепровести вручную.
Прежде чем приступать к свертке регистра Хозрасчетный, мы рекомендуем начать с менее болезненных методов оптимизации. Например, мы можем посмотреть другие крупные регистры и таблицы, которые могут быть "замусорены" старыми или некорректными данными (например, "зависшие" товары или остатки из давних периодов). Затем мы можем выполнить полный пересчет итогов, при этом в некоторых случаях, для таблиц итогов, рекомендуется предварительно выполнить команду TRUNCATE TABLE. Убедитесь, что ваши регламентные задания по пересчету итогов настроены и выполняются регулярно.
Также важно обратить внимание на данные, которые могут быть некорректно введены или не закрыты бухгалтерами (например, остатки по счетам с лохматых времен, или добавленные вручную субконто, которые не заполняются при расходах). Такие данные могут значительно утяжелять запросы.
В ходе диагностики было проведено эксперимент на копии базы: выгрузка DT, загрузка в пустую базу, выполнение SHRINK, а затем повторная загрузка DT. Это позволило уменьшить размер базы с 357 ГБ до 287 ГБ. Такой подход может быть полезен, так как он позволяет перестроить внутреннее хранилище данных и освободить неиспользуемое место. Мы можем рассмотреть аналогичные действия на рабочей базе, но с обязательным предварительным полным резервным копированием и в нерабочее время. Стоит отметить, что небольшой эффект от сжатия таблиц можно получить и просто командой SHRINK DATABASE без выгрузки/загрузки DT, однако это не решает проблемы фрагментации данных внутри самих таблиц.
Для системной борьбы с проблемами производительности нам понадобятся эффективные инструменты диагностики.
Инструмент 1С:ЦУП является мощным инструментом для комплексного анализа производительности систем 1С, но его установка и настройка требуют времени и знаний. Для оперативной диагностики многие проблемы можно выявить с помощью технологического журнала 1С и встроенных инструментов SQL Server (DMVs – динамические административные представления, планы выполнения запросов, SQL Server Profiler). Мы можем самостоятельно настроить технологический журнал 1С для записи событий, связанных с производительностью (например, DBMSSQL, CALL, EXCP), что позволит идентифицировать самые ресурсоемкие запросы, определить причины их медленной работы (сканирование таблиц, блокировки, неэффективные индексы) и получить общую картину загрузки ресурсов.
Настройка технологического журнала 1С включает в себя создание файла logcfg.xml с необходимыми фильтрами и размещение его в соответствующей директории сервера 1С. После сбора данных, мы можем анализировать их с помощью специализированных утилит или вручную, выявляя самые "долгие" события и запросы.
Мы уже упоминали SQL-запросы для поиска самых "тяжелых" запросов и запросов с пропущенными индексами (см. раздел 3.1). Регулярный анализ планов выполнения запросов в SSMS (SQL Server Management Studio) для этих "тяжелых" запросов поможет нам определить, как SQL Server обрабатывает данные, и выявить узкие места, такие как сканирование больших таблиц вместо использования индексов, некорректное соединение таблиц или высокие затраты на сортировку.
Ошибка "SQL Server Native Client 11.0: Invalid object name '#tt1'" обычно указывает на проблему с временными таблицами в SQL Server. Она может возникать по нескольким причинам:
DBCC FREEPROCCACHE, которая уже выполняется у вас ночью.Для решения этой проблемы мы можем проанализировать технологический журнал 1С и журнал ошибок SQL Server в момент возникновения ошибки, чтобы выявить конкретный запрос или контекст, при котором она появляется. Мы также можем проверить права пользователя 1С на базу данных SQL Server.
Платформа 1С версии 8.3.20.1674, хоть и работала стабильно раньше, может стать источником проблем после существенных обновлений конфигурации 1С:Бухгалтерия КОРП, которые могли включать повышение режима совместимости. При повышении режима совместимости конфигурации, функциональность, реализованная на старых версиях платформы, может работать некорректно или медленно. Мы настоятельно рекомендуем рассмотреть обновление платформы 1С до более актуальной стабильной версии, например, 8.3.22.хххх. Перед обновлением платформы всегда проводите тестирование на копии базы, чтобы убедиться в отсутствии регрессий и появлении новых ошибок.
Для снижения нагрузки на текущий SQL Server мы можем предпринять следующие шаги:
Таким образом, для комплексного решения проблемы зависания 1С:Бухгалтерия КОРП мы предлагаем провести многостороннюю работу, включающую как аппаратные улучшения, так и тонкую настройку программного обеспечения, а также оптимизацию самой базы данных. Мы будем работать поэтапно, отслеживая результаты каждого изменения, чтобы добиться стабильной и быстрой работы вашей системы.