Начнем с анализа первоначальной ситуации, описанной автором: сервер 1С, на котором менее чем за сутки память съедается до 98%. Мы имеем дело с платформой 1С версии 8.3.24.1758 и MS SQL Server, обслуживающими около 10 пользователей, работающих с конфигурациями "Зарплата и Управление Персоналом" (ЗУП 3.1.32.17) и "Бухгалтерия Предприятия" (БП 3.0.171.16). Все это развернуто на одном сервере, оснащенном 64 ГБ оперативной памяти.
Мы выяснили, что первоначальная гипотеза об исключительном потреблении памяти процессом rphost не совсем верна, так как автор уточнил, что rphost не является единственным "пожирателем" памяти. Это указывает на необходимость комплексного анализа, включающего как настройки SQL Server, так и особенности работы платформы 1С.
Если SQL Server и 1С кластер расположены на одном физическом сервере, это является критическим моментом. SQL Server по умолчанию стремится использовать максимально доступный объем оперативной памяти, что может привести к ее полному исчерпанию, оставляя недостаточно ресурсов для операционной системы и других процессов, включая 1С.
Мы можем выяснить, сколько памяти SQL Server использует в данный момент, выполнив следующий запрос:
SELECT physical_memory_in_use_kb/1024/1024 AS memory_in_use_Gb
FROM sys.dm_os_process_memory;
Этот запрос покажет объем физической памяти в гигабайтах, используемый процессом SQL Server. Это позволит нам точно оценить, какая часть из 64 ГБ используется СУБД.
Крайне важно установить максимальный объем памяти, который может использовать SQL Server. Это делается с помощью параметра конфигурации max server memory (MB) (максимальный объем памяти сервера в МБ). При этом также рекомендуется обратить внимание на параметр min server memory (MB) (минимальный объем памяти сервера в МБ).
Для сервера с 64 ГБ оперативной памяти и совместным размещением 1С, мы рекомендуем выделить SQL Server объем памяти, равный размеру активных данных базы данных плюс 10-15%. При этом необходимо оставить 2-4 ГБ оперативной памяти для операционной системы и других служб. Например, если база данных интенсивно использует 30 ГБ данных, можно выделить SQL Server около 35-40 ГБ, оставляя порядка 20-25 ГБ для процессов 1С и ОС. Мы должны тщательно балансировать эти значения, чтобы обеспечить стабильную работу всех компонентов.
Эти параметры настраиваются в свойствах SQL Server через SQL Server Management Studio (SSMS) в разделе "Memory".
Эта опция позволяет службе SQL Server удерживать данные в физической памяти, предотвращая их выгрузку в файл подкачки Windows. Это значительно улучшает производительность, так как SQL Server сможет быстрее получать доступ к данным. Для включения этой опции необходимо предоставить учетной записи службы SQL Server соответствующие права в локальных политиках безопасности Windows ("Lock pages in memory"). Мы должны удостовериться, что эта настройка применена корректно, особенно на серверах с большим объемом ОЗУ.
max degree of parallelism (MDOP):
Для серверов 1С с SQL Server рекомендуется устанавливать значение max degree of parallelism (MDOP) равным 1. Платформа 1С не рассчитана на распараллеливание запросов внутри СУБД, и более высокие значения могут приводить к излишней нагрузке и накладным расходам, а не к улучшению производительности. Мы должны убедиться, что этот параметр настроен оптимально для нашей среды.
Если SQL Server и 1С расположены на одном сервере, мы рекомендуем убедиться, что для соединения используется протокол Shared Memory. Это самый быстрый способ подключения, так как данные передаются через оперативную память, минуя сетевые интерфейсы. Мы можем проверить и настроить порядок использования протоколов в SQL Server Configuration Manager.
Даже при корректной настройке SQL Server и наличии достаточного объема памяти, процессы rphost (рабочие процессы 1С) могут потреблять значительные объемы ресурсов. Это может быть связано с особенностями платформы, конфигурации или активностью пользователей. Мы должны тщательно проанализировать поведение rphost.
Технологический журнал является мощным инструментом для выявления причин повышенного потребления памяти и поиска узких мест. Мы настраиваем его для сбора следующих событий, чтобы получить максимально полную картину:
MEM и LEAKS: Эти события помогут нам отслеживать выделение и освобождение памяти процессами 1С, а также выявлять потенциальные утечки. Утечки памяти могут быть причиной постепенного "съедания" ресурсов и являются частой проблемой в долго работающих приложениях.CALL: Эти события регистрируют вызовы клиент-серверного взаимодействия. Особое внимание обращаем на свойства Memory и MemoryPeak, которые показывают объем памяти, потребляемой конкретным вызовом. Это позволяет нам выявить "тяжелые" вызовы, потребляющие много памяти, и определить, какие операции или пользователи являются их инициаторами.EXCP, ATTN, PROC: Эти события помогут выявить ошибки, внимание (например, обрывы соединений или длительные ожидания) и длительные процедуры. Хотя они напрямую не связаны с потреблением памяти, они могут указывать на проблемы в логике работы, которые косвенно приводят к неэффективному использованию ресурсов или "зависанию" сеансов.Анализируя записи ТЖ, мы можем определить конкретные сеансы, фоновые задания или участки кода конфигурации, которые вызывают проблему. Это позволяет точечно работать над устранением причин, а не следствий.
Консоль администрирования сервера 1С Предприятия позволяет нам в реальном времени мониторить состояние кластера 1С и его рабочих процессов. Это визуальный инструмент, дополняющий данные ТЖ, хотя в некоторых случаях эффективнее использовать детализированный менеджер процессов.
rphost) и отсортировать их по объему потребляемой памяти. Это сразу выделит наиболее "прожорливые" процессы.rphost, мы можем просмотреть активные соединения. Это поможет нам выяснить, какой пользователь, внешний отчет/обработка или фоновое задание является источником проблемы. Мы можем увидеть длительные сеансы, которые удерживают много памяти.Оптимизация настроек кластера 1С является важным шагом для стабилизации потребления памяти и обеспечения устойчивости работы. Мы рассмотрим следующие параметры:
Автор темы уже установил интервал перезапуска 86400 секунд (раз в сутки). Однако, если утечки памяти происходят быстрее, этого может быть недостаточно. Регулярный перезапуск rphost помогает освобождать накопленную память и сбрасывать состояние процессов. Мы можем попробовать уменьшить этот интервал, например, до 12 часов, 8 часов или даже чаще, если проблема быстро возвращается. Мы должны протестировать различные интервалы, чтобы найти оптимальный баланс между стабильностью и доступностью.
Мы можем установить максимальный объем памяти, который может использовать один рабочий процесс rphost. При превышении этого лимита, процесс будет принудительно перезапущен. Это помогает предотвратить "съедание" всей памяти одним процессом и изолировать проблемы, не допуская деградации всего сервера. Этот параметр очень полезен для систем с известными утечками или тяжелыми операциями. Мы должны установить это значение с учетом общего объема ОЗУ и количества рабочих процессов.
Для 64-разрядной системы, иногда рекомендуется использовать один рабочий процесс, но это не универсальное правило. В зависимости от нагрузки, количества пользователей и типа выполняемых операций, нам может потребоваться настроить большее количество рабочих процессов для равномерного распределения нагрузки. Мы должны оптимизировать количество соединений на процесс, чтобы избежать перегрузки одного rphost. Например, если у нас 10 пользователей, мы можем настроить 2-3 рабочих процесса, распределяя соединения между ними.
Мы выяснили, что после последних обновлений БП и ЗУП, процессы rphost стали потреблять больше памяти. Это может быть связано с возросшим количеством фоновых заданий или изменениями в логике конфигураций. Мы должны внимательно изучить этот аспект.
Внимательно просмотрите список всех регламентных операций в каждой информационной базе. Часто здесь накапливаются неоптимизированные задания.
Мы настоятельно рекомендуем сделать скриншоты или задокументировать текущие настройки регламентных заданий перед внесением каких-либо изменений, чтобы иметь возможность вернуться к исходному состоянию в случае непредвиденных проблем.
Неоптимальный код, некорректное управление памятью, циклические ссылки или неверное размещение переменных и объектов в конфигурации могут приводить к значительному расходу памяти рабочими процессами rphost. Анализ ТЖ поможет выявить такие участки кода. Мы должны просмотреть код, который был изменен или добавлен в последних обновлениях, особенно если он касается обработки больших объемов данных.
Механизм полнотекстового поиска в 1С может быть очень требовательным к ресурсам, особенно если индекс часто обновляется или пользователи активно его используют. Мы должны проверить его настройки, интенсивность использования и, при необходимости, пересмотреть расписание обновления индекса или даже временно отключить, чтобы проверить влияние на потребление памяти.
Использование внешних компонент (например, для печати штрихкодов, работы с торговым оборудованием) может вызывать утечки памяти, если они содержат ошибки или являются неоптимальными. Мы должны проверить актуальность версий внешних компонент и отсутствие проблем в их работе, по возможности обновить их или протестировать без них.
Сеансы, находящиеся в длительных клиент-серверных вызовах, могут удерживать память на протяжении всего времени выполнения. Мы должны использовать Консоль администрирования 1С для их выявления и анализа причин задержек.
Накопленный неактуальный кэш на сервере и у пользователей также может влиять на производительность и потребление памяти. Периодический перезапуск сервера 1С и очистка кэша пользователей (удаление файлов из папок %LOCALAPPDATA%\1C\1CE\ и %LOCALAPPDATA%\1C\1Cv8\) могут временно снизить потребление памяти и улучшить работу.
Фирма "1С" постоянно выпускает обновления платформы и конфигураций, которые включают исправления ошибок, оптимизации производительности и устранение утечек памяти. Мы должны учитывать, что текущая версия платформы 8.3.24.1758 является одной из последних, но даже в ней могут быть обнаружены новые нюансы.
Мы рекомендуем поддерживать актуальные версии платформы 1С и используемых конфигураций (ЗУП, БП). В частности, с выходом версии 8.3.20 обещалось решение проблемы повышенного потребления памяти, и последующие версии продолжают включать улучшения. Регулярные обновления могут помочь решить уже известные проблемы с производительностью и утечками памяти, без необходимости глубокого анализа кода.
Убедитесь, что файл подкачки на сервере настроен корректно и имеет достаточный размер. Хотя физическая память является приоритетом, правильно настроенный файл подкачки является важной частью стабильной работы сервера. Обычно рекомендуется устанавливать его в 1.5-2 раза больше объема оперативной памяти. Мы должны проверить, что файл подкачки расположен на быстром диске и имеет фиксированный размер, а не динамически изменяемый.
Мы рассмотрели комплексный подход к диагностике и решению проблемы высокого потребления оперативной памяти на сервере 1С. Важно подходить к этой задаче системно: сначала убедитесь в правильности настройки SQL Server, ограничивая его потребление памяти. Затем мы должны глубоко анализировать поведение процессов rphost с помощью Технологического журнала и Консоли администрирования 1С, выявляя конкретные операции, пользователей или фоновые задания, вызывающие проблемы. Регулярное обновление платформы и оптимизация конфигурации, а также регламентных заданий, являются ключевыми факторами стабильной и производительной работы системы 1С. Только такой последовательный и детальный подход позволит нам найти истинную причину и эффективно устранить ее.