1с sql жрет память
Столкнулся с тем что РПхост на пару с СКУЛЬ-сервантом отъели всю память. Почти 48 гигов. Не знаю, как определить причину такого поведения. На все что хватило мозгов - это запустить счетчик в консоли администрирования сервера 1С. Но по счетчику видно, что отъедается якобы около 5 гигов. Не подскажите как можно диагностировать утечку?
Что можно сделать:
В диспетчере задач посмотреть ИД процесса рпхост.
По ИД найти рабочий процесс, соответствующий рпхосту.
В соединениях посмотреть номера сеансов.
А зная номер сеанса, можно проанализировать текущие сеансы в консоли, либо журнал регистрации в конкретной базе.
(10) За совет спасибо. на случай нескольких рабочих процессов - хорошая подсказка. Но у меня все сеансы на одном рабочем процессе висят. Позже сделаю как предложили ниже: для каждой базы свой рабочий процесс.
(12) раз один рабочий процесс, то должно же быть видно в списке сеансов, какой захватил много ресурсов?
или даже там не видно?
(19) К сожалению, не обратил внимание, что в "сеансах" отображается такая развернутая аналитика. Возможно там что-то бы и показало. Но посмотреть уже не могу - "решил" вопрос (возможно временно) перезагрузив сервер. На будущее, если столкнусь с подобным снова, буду иметь ввиду. спасибо!
(20) Ага. В консоли видно практически все, что нужно для оперативного исправления ситуации.
Плюс еще журнал регистрации, чтобы понять, например, что пользователь запустил какой-то отчет, потом ему надоело ждать, он снял через диспетчер задач процесс 1С и заново зашел.
А отчет все формируется и формируется, сервак чето тормозит.
И никто ничего не делает уже, ни у кого ничего не запущено, а сервак тормозит.
С одним рабочим процессом конечно проще.
Но с несколькими устойчивее ситуация получается.
Если надо грохнуть уже сам процесс рпхоста на сервере, то с одним рабочим процессом отвалятся все. А с несколькими только те, кто на этом рабочем процессе висит.
Т.е. негатива от пользователей будет меньше.
До 2019 все было хорошо, пока 1С не изменила политику по лицензиям. Настройки сервера по политике вернули по умолчанию и теперь нам приходится раз в неделю перезагружать сервер. Через полдня уже опять 90%, через неделю доходит до 98 и зависает.
Системные администраторы предлагают обновить скул, но это не поможет на мой взгляд.
У кого-нибудь были такие проблемы? как решали?
Грузит память 1С, а админы предлагают обновить скуль?
Хм. Интересное предложение.
Так какой процесс отжирает память?
(0) Давай подробности. 1С x64 ? Админы могу предполагать как гадить в туалете , а без анализа тратить деньги не надо. Пусть смотрят performance и поставят счетчики нужные.
то есть получается можно посмотреть в сторону КОРП и вернуть настройки?
про неправильный запрос думала, но не знаю как выловить, память растет постепенно
(20) 1С рекомендует настройки SQL-сервера совместно с сервером 1С.
Обещают, что даже 1С будет быстрее работать при правильной настройке обслуживания баз 1С.
(22) да, раньше было несколько процессов и завершались автоматически проблемные, после возврата настроек так не происходит.
поэтому предложили попробовать настроить сервер
попробовать килять старые сеансы вручную в админке (особенно фоновые), помотреть в сторону системы взаимодействия по отключению пользователей из 1с
но не знаю насколько это будет эффективно выгружать неиспользуемую память
(19) нет смысла смотреть в сторону КОРП на таком числе пользователей. Хотя. посмотреть можно. только, когда увидите стоимость этого решения, то сразу же от него откажетесь.
+(20) плюс как настроен вакуум ну скуле? В админке севера скуля посмотрите к каким таблицам больше всего обращений и сколько они размером и ресурсов сколько едят. Найдите эти таблицы в 1с. Посмотрите какие запросы/обработчики с этими таблицами работают, замерьте время работы и т.д. Возможно обрезать базы на начало прошлого года или даже этого. Вариантов куча.
Но в моем случае помогло одно, полная очистка сервера от 1с и скуля. Оставалось много мусора от предыдущих версий платформ и серверов.
Плюс граммотно настроили конфиг скуля и вуаля все летают, а оперативка больше 36 не хавается никогда
(28) я бы на вашем месте попробовал другие релизы платформы. Вот у нас, когда начали появляться 16-ые, то держались на одном 14-м релизов, пока не появился 8.3.17.1549
А у вас на этом сервере баз БП вероятно нет?
(32) по моему вакуум всего раз делали вручную.
про таблицы спасибо!
свертка базы запланирована на следующий год
(36) просто базы БП 3 заставляют сейчас всех заменять платформу.
А "утечки памяти" на разных релизах платформы все-таки неодинаковые.
Очень может быть, что вся проблема будет снята просто переходом на другой релиз и все.
(38) ну вот в списке рекомендованных для актуальных БП 3 этого релиза уже нет. Если в виртуалке у вас БП 3 актуальные, то и релиз там будет другой.
(0) Так поставьте КОРП, вы же купили раньше 2019г. Если программный - должно было автоматом примениться, если HASP - надо получить в личном кабинете (можно ли сейчас - не знаю, откройте письмо).
Запускаем сервер 1С и внимательно ждем меньше суток.
В памяти висят несколько rphost.
Почти всегда из 16 гигов оперативы какой-нибудь отдельно взятый rphost жрет памяти в размере "16Гб - занятая_остальными_приложениями_память - так_и_быть_оставлю_тебе_крохи_на_бедную_старость".
Кроме того, по какой-то причине как правило он же жрет и процессор, примерно по тому же принципу "Сожру_все_что_свободно_оставлю_процентов_пять_на_милостыню_нищим".
Гуглил гуглил, яндексил яндексил, нихрена не нашел адекватного решения, везде только перезапуск сервера 1С ну или снятие rphost.
Так что, нет цивилизованного решения, кроме как резать по-живому?
(1) Это я в курсе.
Но во-первых, бывает так, что и в течение дня уже сожрано все, что можно.
Во-вторых, это как бы рубит сеансы, что не очень хорошо.
В-третьих, не совсем понятно, почему так жестко.
(2) Заметил, правда, что и вырубание rphost и перезапуск службы сервера 1С рубит сеансы не гарантированно, бывают выжившие и часто.
Но гарантий, что кто-то выживет, нет никаких.
(3) А я при перезапуске еще temp пользователя, от имени которого запущен сервис Агента 1С:Предприятие, чищу и удаляю snccntx из каталога кластера. Не выживает никто.
(6) периодически фиксят баги, стараемся обновляться оперативно на последние релизы, часто шлем вопросы в поддержку, иногда решают. Из последних - был поднятый но не подключенный сетевой интерфейс, за счёт этого сносило башню серверу и не корректно поднимался кластер (не видел лицензии с другого сервака) отослали журнал регистрации - дали совет отключить и все заработало более стабильно. А вообще при переезде с 16 на 32 г сервер значительно выросла отзывчивость и уменьшилась падучесть.
аптайм сервера 1C-Предприятие небольшой. порядка 10 дней.
(9) Ну вот у кого как.
У кого-то жрет у кого-то не жрет.
У всех разные винды, платформы, даже сервер у кого-то 32, а у кого-то 64.
Не говоря уже о количестве баз, регламентных заданиях и пр.
Характерная деталь. Тут ни когда, почти, обсуждение вариантов решения проблемы не начинается с публикации определения, трактовки термина и т.п., т.е. сути того, что составляет проблему.
В компании для работы сервера 1С Предприятия 8.2.19.83 используется MSSQL Server 2008 R2 SP3. Баз достаточно много — начиная с Документооборота, заканчивая Кадрами.
Оба сервера (1С Предприятие и MSSQL) находятся на одном и том же физическом сервере.
Проблема в том, что за 1-2 полных рабочих дня сервер MSSQL "съедает" всю выделенную для него память. Такое чувство, что происходит утечка памяти.
Вот что показывает диспетчер задач:
У сервера 64Gb RAM. Стоит Windows Server 2008 R2 Enterprise.
Максимальный размер памяти для MSSQL выставил в 38Gb:
Свойства кластера сервера 1С Предприятия:
Пользователей 1С Предприятия около 95. Среди них есть много тех, кто работает через терминальный доступ.
Что делать? Как предотвратить утечку? Помогите с советом. Спасибо.
- Вопрос задан более трёх лет назад
- 3271 просмотр
Это разве проблема? Это нормальное поведение для MSSQL.
А вот то, что на одном сервере сервер БД, сервер 1с, и еще и терминальный сервер - это да, проблема.
Кирилл: У каких пользователей?
У тех кто подключается к серверу, или у тех кто работает на этом сервере в терминале?
Подтверждаю слова АртемЪ: захапать все что есть, или до предела указанного в настройках, это нормальное поведение MS SQL Server'а (сам раньше этим озадачивался). Так что не волнуйтесь, это не баг, это фича.
UPD по поводу зависаний: опять же, одну из причин (нехватка ресурсов между программами) уже назвал АртемЪ, но может быть еще и другая. "Поиграйте" с количеством соединений на процесс в свойствах сервера 1С. У нас тоже со временем вдруг появлялись непонятные зависания и никто не мог нормально работать (и я тоже поначалу грешил на SQL-сервер). Помогло уменьшение количества соединений. Точно уже не помню (у нас уже 8.3, а там автоматическое управление процессами), но можно еще с количеством самих процессов поэкспериментировать, добавить резервный и т.п. (информации на эту тему полно в гугле).
Полностью согласен с предыдущими ораторами.
Отъедать всю доступную память - нормальная политика MS SQL. У меня, например, вся память отъедается в течение получаса после запуска SQL.
Терминалу не место на сервере баз данных.
Вообще сервер баз данных плохо совмещается с другими ролями, т.к. при более менее приличной нагрузке, как вы сами заметили, SQL отъедает всю доступную память, кроме того в пиках обычно довольно высокая дисковая нагрузка что то же не комильфо для других ролей. А так же, если другие роли начнуть так же отъедать ресурсы - это очень плохо скажется на производительности SQL.
Если со временем SQL не займет вообще всю память, значит утечек нет.
Пока думаете над переносом терминала на другую железку, можно заняться стандартной оптимизацией базы: создать недостающие индексы, вычислить особо тормозные выборки и попробовать их оптимизировать, настроить регламентные задания (дефрагментация индексов, обновление статистики и т.п.), разнести на разные диски файл базы данных и лог файл.
При размещении 1С в облачной инфраструктуре и среде виртуализации наиболее важными и непростыми задачами являются повышение скорости работы платформы «1С» и настройка СУБД. Для достижения максимальной производительности инфраструктуры 1С рекомендуется правильно выбирать архитектуру инфраструктуры, режимы работы, проверить и выполнить ряд важных настроек.
В зависимости от количества пользователей, размера баз данных и ограничений бюджета (с учетом стоимости дополнительных лицензий на сервер «1С:Предприятие 8» и лицензий на СУБД) платформа «1С» может работать в файловом и клиент-серверном вариантах (на основе трехуровневой архитектуры «клиент-сервер» (рис. 1): клиентское приложение, кластер серверов «1С:Предприятия 8», СУБД).
Рис. 1
Как правильно выбрать вариант/режим работы 1С: файловый или SQL?
Обычно для 1-10 пользователей выбирается файловый режим
От 10 и более пользователей выбирается режим работы с использованием SQL
В файловом варианте все пользователи могут работать на одной виртуальной машине в облаке, например на терминальном сервере.
Для клиент-серверного варианта лучше выбрать не менее двух виртуальных машин:
Сервер с клиентским приложением, например терминальный сервер с клиентской частью «1С» (толстый клиент)
Сервер «1С» и СУБД (MS SQL или PostgreSQL)
Как рассчитать мощности сервера для 1С в файловом режиме работы?
В обоих вариантах: файловом и SQL, для работы с пользовательским приложением 1С в классическом режиме, например, «удаленного рабочего стола» (так называемый «толстый клиент»), необходимы следующие минимальные ресурсы виртуального сервера:
Количество виртуальных ядер CPU = 1 или 2 для ОС + 0,25 * количество пользователей
Объем памяти RAM = 1 или 2 ГБ для ОС + 0,5 ГБ * количество пользователей
Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (0,1-10) ГБ * количество пользователей. Для ОС и 1С рекомендуется использовать самые быстрые диски
Как рассчитать мощности сервера для 1С в варианте работы с SQL?
В клиент-серверном варианте работы 1С, в котором используется СУБД SQL, рекомендуется разместить 1С Сервер и сервер SQL на отдельном виртуальном сервере в общей с клиентским сервером локальной подсети. Необходимы следующие минимальные мощности для этого виртуального сервера:
Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (10-1000) ГБ в зависимости от объема и количества баз данных. Для ОС и СУБД рекомендуется использовать самые быстрые диски
------------
ОС - операционная система, например, Windows Server
Здесь Сервер 1С - ПО "сервер "1С:Предприятия 8"
Наиболее важными и непростыми задачами являются повышение продуктивности использования платформы «1С» в облаке и настройка СУБД. Типичные проблемы при развертывании и эксплуатации облачной инфраструктуры для «1С» следующие:
Неправильный выбор мощностей
Неквалифицированная настройка сервисов виртуальной инфраструктуры
Недостаточное внимание к тестированию производительности платформы «1С»
Для достижения максимальной производительности рекомендуется проверить и выполнить ряд настроек. Прежде всего необходимо исключить свопинг, для чего с помощью системы мониторинга следует обязательно удостовериться в том, что объем оперативной памяти достаточен для работы ВМ. Кроме того, файл подкачки ОС, профили пользователей, файлы баз данных, файлы логов транзакций (SQL) и tempDB (SQL) лучше разместить на дополнительных SSD-дисках, а для файла подкачки установить фиксированный размер.
На SQL-сервере необходимо выключить все ненужные службы, например FullText Search и Integration Services, установить максимально возможный объем оперативной памяти, максимальное количество потоков (Maximum Worker Threads) и повышенный приоритет сервера (Boost Priority), задать ежедневную дефрагментацию индексов и обновление статистики, настроить автоматическое увеличение файла базы данных (не менее 200 Мбайт) и файла лога (не менее 50 Мбайт), а также полную реиндексацию не реже одного раза в неделю. При размещении серверов SQL и «1С:Предприятие» на одной ВМ следует включить протокол Shared Memory.
Следуя перечисленным выше рекомендациям, можно добиться увеличения быстродействия платформы «1С» в облаке в 1,5–2 раза.
Квалифицированное размещение ИТ-сервисов, в том числе «1С», на облачной платформе позволяет:
Существенно сократить расходы
Повысить уровни безопасности (доступ к данным, резервное копирование, антивирусная защита и др.) и технического обслуживания
Обеспечить централизованное администрирование и мониторинг
Организовать эффективную и безопасную удаленную работу
Воспользоваться гибкими возможностями масштабирования, лицензирования и оперативного перехода на необходимые версии конфигураций «1С»
ЧЕК-ЛИСТ ПО ОПТИМИЗАЦИИ ИНФРАСТРУКТУРЫ 1С С MS SQL
1. Включить возможность мгновенной инициализации файлов (Database instant file initialization)
Это позволяет ускорить работу таких операций как:
Создание базы данных
Добавление файлов, журналов или данных в существующую базу данных
Увеличение размера существующего файла (включая операции автоувеличения)
Восстановление базы данных или файловой группы
Для включения настройки:
На компьютере, где будет создан файл резервной копии, откройте приложение Local Security Policy (secpol.msc)
Разверните на левой панели узел Локальные политики, а затем кликните пункт Назначение прав пользователей
На правой панели дважды кликните Выполнение задач по обслуживанию томов
2. Включить параметр «Блокировка страниц в памяти» (Lock pages in memory)
Эта настройка определяет, какие учетные записи могут сохранять данные в оперативной памяти, чтобы система не отправляла страницы данных в виртуальную память на диске, что может повысить производительность.
Для включения настройки:
В меню Пуск выберите команду Выполнить. В поле Открыть введите gpedit.msc
В консоли Редактор локальных групповых политик разверните узел Конфигурация компьютера, затем узел Конфигурация Windows
Разверните узлы Настройки безопасности и Локальные политики
Выберите папку Назначение прав пользователя
Политики будут показаны на панели подробностей
На этой панели дважды кликните параметр Блокировка страниц в памяти
В диалоговом окне Параметр локальной безопасности — блокировка страниц в памяти выберите «Добавить» пользователя или группу
В диалоговом окне Выбор: пользователи, учетные записи служб или группы добавьте ту учетную запись, под которой у вас запускается служба MS SQL Server
Чтобы изменения вступили в силу, перезагрузите сервер или зайдите под тем пользователем, под которым у вас запускается MS SQL Server
3. Включить каталоги с файлами базы данных в правила исключения для антивируса.
Если антивирус будет сканировать файлы базы, это может сильно замедлить работу СУБД.
Для опытных администраторов: антивирус на сервер СУБД лучше не устанавливать.
4. Включить каталоги с файлами базы данных в список исключений для системы автоматического копирования.
Если на сервере установлена система автоматического копирования файлов, то, когда она будет копировать файлы базы, это может привести к замедлению работы. Копии базы необходимо делать средствами самой СУБД.
5. Отключить механизм DFSS для дисков.
Механизм Dynamic Fair Share Scheduling отвечает за балансировку и распределение аппаратных ресурсов между пользователями. Иногда его работа может негативно сказываться на производительности 1С.
Чтобы отключить его только для дисков, нужно:
Найти в реестре ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk
Установить значение параметра EnableFairShare в 0
6. Отключить сжатие данных для каталогов, в которых лежат файлы базы.
При включенном сжатии ОС будет пытаться дополнительно обрабатывать файлы при модификации, что замедлит сам процесс записи, но сэкономит место.
Чтобы отключить сжатие файлов в каталоге, необходимо:
Открыть свойства каталога
На закладке Общие нажать кнопку Другие
Снять флаг «Сжимать» содержимое для экономии места на диске
7. Установить параметр «Максимальная степень параллелизма» (Max degree of parallelism) в значение 1.
Данный параметр определяет, во сколько потоков может выполняться один запрос. По умолчанию параметр равен 0, это означает, что сервер сам подбирает число потоков. Для баз с характерной для 1С нагрузкой рекомендуется поставить данный параметр в значение 1, т.к. в большинстве случаев это положительно скажется на работе запросов.
Для настройки параметра необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Дополнительно
Установить значение параметра равное единице
8. Ограничить максимальный объем памяти сервера MS SQL Server.
Необходимо ограничить максимальный объем памяти, потребляемый MS SQL Server, особенно это критично, если роли сервера 1С и сервера СУБД совмещены. Максимальный объем памяти, рекомендуемый для MS SQL Server, можно рассчитать по следующей формуле:
Память для MS SQL Server = Память всего – Память для ОС – Память для сервера 1С
Например, на сервере установлено 64 ГБ оперативной памяти, необходимо понять, сколько памяти выделить серверу СУБД, чтобы хватило серверу 1С.
Для нормальной работы ОС в большинстве случаев более чем достаточно 4 ГБ, обычно – 2-3 ГБ.
Чтобы определить, сколько памяти требуется серверу 1С, необходимо посмотреть, сколько памяти занимают процессы кластера серверов в разгар рабочего дня. Этими процессами являются ragent, rmngr и rphost, подробно данные процессы рассматриваются в разделе, который посвящен кластеру серверов. Снимать данные нужно именно в период пиковой рабочей активности, когда в базе работает максимальное количество пользователей. Получив эти данные, необходимо прибавить к ним 1 ГБ – на случай запуска в 1С «тяжелых» операций.
Чтобы установить максимальный объем памяти, используемый MS SQL Server, необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Память
Указать значение параметра Максимальный размер памяти сервера
9. Включить флаг «Поддерживать» приоритет SQL Server (Boost SQL Server priority).
Данный флаг позволяет повысить приоритет процесса MS SQL Server над другими процессами.
Имеет смысл включать флаг только в том случае, если на компьютере с сервером СУБД не установлен сервер 1С.
Для установки флага необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства сервера и выбрать закладку Процессоры
Включить флаг «Поддерживать приоритет SQL Server (Boost SQL Server priority)» и нажать Ок
10. Установить размер авто увеличения файлов базы данных.
Автоувеличение позволяет указать величину, на которую будет увеличен размер файла базы данных, когда он будет заполнен. Если поставить слишком маленький размер авторасширения, тогда файл будет слишком часто расширяться, на что будет уходить время. Рекомендуется установить значение от 512 МБ до 5 ГБ.
Для установки размера авторасширения необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства нужной базы и выбрать закладку Файлы
Напротив каждого файла в колонке Автоувеличение поставить необходимое значение
Данная настройка будет действовать только для выбранной базы. Если вы хотите, чтобы такая настройка действовала для всех баз, нужно выполнить эти же действия для служебной базы model. После этого все вновь созданные базы будет иметь те же настройки, что и база model.
11. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.
В этом случае работа с файлами может идти не последовательно, а практически параллельно, что повышает скорость работы дисковых операций. Лучше всего для этих целей подходят диски SSD.
Для переноса файлов необходимо:
Запустить Management Studio и подключиться к нужному серверу
Открыть свойства нужной базы и выбрать закладку Файлы
Запомнить имена и расположение файлов
Отсоединить базу, выбрав через контекстное меню Задачи – Отсоединить
Поставить флаг Удалить соединения и нажать Ок
Открыть Проводник и переместить файл данных и файл журнала на нужные носители
В Management Studio открыть контекстное меню сервера и выбрать пункт Присоединить базу
Нажать кнопку Добавить и указать файл mdf с нового диска
В нижнем окне сведения о базе данных в строке с файлом лога нужно указать новый путь к файлу журнала транзакций и нажать Ок
12. Вынести файлы базы TempDB на отдельный диск.
Служебная база данных TempDB используется всеми базами сервера для хранения, промежуточных расчетов, временных таблиц, версий строк при использовании RCSI и многих других вещей. Обычно обращений к этой базе очень много, и если она будет лежать на медленных дисках, это может замедлить работу системы.
Рекомендуется хранить базу TempDB на отдельном диске для повышения производительности работы системы.
Для переноса базы TempDB на отдельный диск необходимо:
Запустить Management Studio и подключиться к нужному серверу
Создать окно запроса и выполнить скрипт:
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'Новый_Диск:\Новый_Каталог\tempdb.mdf')
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'Новый_Диск:\Новый_Каталог\templog.ldf')
Перезапустить MS SQL Server
13. Включить Shared Memory, если сервер 1С расположен на том же компьютере, что и сервер СУБД.
Протокол Shared Memory позволит общаться приложениям через оперативную память, а не через протокол TCP/IP.
Для включения Shared Memory необходимо:
Запустить диспетчер конфигурации SQL Server
Зайти в пункт SQL Native Client – Клиентские протоколы – Общая память – Включено
Поставить значение Да и нажать Ок
Протокол Именованные каналы нужно выключить аналогичным образом
14. Перезапустить службу MS SQL Server
Внимание! Когда все настройки выполнены, необходимо перезапустить службу MS SQL Server
Читайте также: