После обновления платформы каждый день у пользователей появляется ошибка: "Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Ошибка выделения памяти HRESULT=80004005". Система Windows Server 2008, 20гб ОЗУ, стоит Microsoft SQL Server Standard (64-bit). Платформу сначала установила 8.3.9, сейчас 8.3.2197, основная база - УТ11.1. Ошибка уходит после рестарта. Кто сталкивался? В чем может быть проблема?
По теме из базы знаний
- Практика применения DevOps. Работа с SonarQube
- Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками
- Переход на Clickhouse для анализа метрик
- Проблемы на ровном месте, или рассказ о том, как у нас каждое утро стабильно подвисал dev-сервер 1С
- Экспертный кейс. Недостаточно памяти для получения результата запроса: что это такое и как с этим бороться?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) Увеличьте шаг роста базы до 515мб, на файл журнала транзакций тоже самое, ограничений на максимальный размер лога быть не должно.
Далее в локальных политиках безопасности найдите строку локальные политики\назначение прав пользователей\выполнение задач по обслуживанию томов и добавьте в свойствах пользователя от которого запускается служба MS SQL Server. По дефолту это "NT Service\MSSQLSERVER"
Эта настройка позволит MS SQL Server мгновенно инициализировать место под создание новой базы и мгновенно расширять размер существующих.
Дополнительно можно системную базу temp разбить на несколько файлов (4 рекомендуется для крупных внедрений) и установите для каждого файла начальный размер 1024 и шаг роста 512.
Далее в локальных политиках безопасности найдите строку локальные политики\назначение прав пользователей\выполнение задач по обслуживанию томов и добавьте в свойствах пользователя от которого запускается служба MS SQL Server. По дефолту это "NT Service\MSSQLSERVER"
Эта настройка позволит MS SQL Server мгновенно инициализировать место под создание новой базы и мгновенно расширять размер существующих.
Дополнительно можно системную базу temp разбить на несколько файлов (4 рекомендуется для крупных внедрений) и установите для каждого файла начальный размер 1024 и шаг роста 512.
(4)
- Спасибо. Попробую.
Далее в локальных политиках безопасности найдите строку локальные политики\назначение прав пользователей\выполнение задач по обслуживанию томов и добавьте в свойствах пользователя от которого запускается служба MS SQL Server. По дефолту эт
- Спасибо. Попробую.
(19)Это делается для ускорения ввода/вывода. Когда с tempdb работают несколько сессий возникает внутренняя конкуренция за ресурсы - соединения с файлом.
Лучше ставить от 2 до 8 в зависимости от количества ядер процессора (логичестких). Больше 8 ставить не нужно.
Минимальный размер выставляется 1024 для базы и 512мб лог для небольших баз - в большинстве случаев этих цифр более чем достаточно, если конечно у вас база измеряется не сотнями ГБ
Лучше ставить от 2 до 8 в зависимости от количества ядер процессора (логичестких). Больше 8 ставить не нужно.
Минимальный размер выставляется 1024 для базы и 512мб лог для небольших баз - в большинстве случаев этих цифр более чем достаточно, если конечно у вас база измеряется не сотнями ГБ
(19)
Выше параллельность и скорость работы, в общем случае.
Смысл рекомендации такой же как и у MaxDoP = 1 для MS SQL - потому что, в большинстве случаев, 4 (по количеству физических ядер процессора) лучше чем 1 и имеет больший смысл чем 9-10.
На самом деле оптимальное значение необходимо подбирать экспериментальным путём, проводя тестирование после каждого изменения настроек. Но, это дорого, долго и не все это умеют.
В общих чертах описано и на итс, и в библиотеке типовых вопросов крупных внедрений. А на подробное описание в разделе MS SQL ссылку уже дали.
толком никто не смог объяснить что это дает и почему 4, а не 2 или 5.
Выше параллельность и скорость работы, в общем случае.
Смысл рекомендации такой же как и у MaxDoP = 1 для MS SQL - потому что, в большинстве случаев, 4 (по количеству физических ядер процессора) лучше чем 1 и имеет больший смысл чем 9-10.
На самом деле оптимальное значение необходимо подбирать экспериментальным путём, проводя тестирование после каждого изменения настроек. Но, это дорого, долго и не все это умеют.
В общих чертах описано и на итс, и в библиотеке типовых вопросов крупных внедрений. А на подробное описание в разделе MS SQL ссылку уже дали.
(13)
У Вас уже стоит ограничение по памяти.
Вообще судя по всему у вас происходит переполнение. Выше Вам давали ссылку на статью
Ваш случай это 2я половина текста. Основная суть процесс х32 не может работать с адресным пространством достаточным для обработки массива информации. Соответственно - это переполнение. Совет перейти на х64 севрер 1с или ниже, есть вариант как пофиксить таблицы конфигурации.
Вот сам текст.
Возвращалась, не помогло. На сколько ограничить?
У Вас уже стоит ограничение по памяти.
Вообще судя по всему у вас происходит переполнение. Выше Вам давали ссылку на статью
Ваш случай это 2я половина текста. Основная суть процесс х32 не может работать с адресным пространством достаточным для обработки массива информации. Соответственно - это переполнение. Совет перейти на х64 севрер 1с или ниже, есть вариант как пофиксить таблицы конфигурации.
Вот сам текст.
Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 1С — это не достаточно оперативной памяти. А еще точнее неэффектиное использование ресурсов памяти. Отсюда косвенные способы победить проблему: путем рестарта сервера (на некотрое время становиться больше доступной памяти) или перейти на 64-разрядный сервер приложений.
1С:Предприятие 8.2. Лицензия на сервер (x86-64)
По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.
Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):
1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель «запрет на фоновые задания» в
момент создания базы.
Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском — вещь в себе — и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять — возможно проблема «уйдет».
2. Перезапустить сервер
Второй шаг является частным случаем для вашего случая и после него тоже
есть смысл проверять работоспособность. Однако поскольку существуют утечки памяти , то через некоторое время после рестарта пролема может вернуться.
3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться «возврат» к предыдущему состоянию данных
4) снимаем базу с поддержки, выгружаем cf
убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение) убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение)
вот пример работоспособности этого приема
или
1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FR OM dbo.Config WH ERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.
Взято с
можно попробывать и более радикальный шаг здесь:
удаляем (в менежмент консоли) в базе данных таблицу «config»
DR OP TABLE [dbo].[Config]
5) делаем «загрузить конфигурацию» (не объединение) из cf
после этого проверяем, проблема уходит.
Показать1С:Предприятие 8.2. Лицензия на сервер (x86-64)
По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.
Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):
1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель «запрет на фоновые задания» в
момент создания базы.
Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском — вещь в себе — и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять — возможно проблема «уйдет».
2. Перезапустить сервер
Второй шаг является частным случаем для вашего случая и после него тоже
есть смысл проверять работоспособность. Однако поскольку существуют утечки памяти , то через некоторое время после рестарта пролема может вернуться.
3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться «возврат» к предыдущему состоянию данных
4) снимаем базу с поддержки, выгружаем cf
убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение) убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение)
вот пример работоспособности этого приема
или
1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FR OM dbo.Config WH ERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.
Взято с
можно попробывать и более радикальный шаг здесь:
удаляем (в менежмент консоли) в базе данных таблицу «config»
DR OP TABLE [dbo].[Config]
5) делаем «загрузить конфигурацию» (не объединение) из cf
после этого проверяем, проблема уходит.
(14)Не помогли и эти действия, все равно примерно раз в день выдает ошибку. При чем создается впечатление, что проблемы с объемными операциями. После завершения которых, память как будто не освобождается, хотя если смотреть на загрузку и "съедаемую" процессами память все стандартно.
(15)
Да если честно - ожидаемо) Проблемы не столько в объемных операциях сколько в суммарном использовании "виртуального адресного пространства" для 32 битного процесса. Как правило эти проблемы решает сервер х64. Можно конечно пробовать выкручиваться например попробовать почаще обновлять статистику и очистку процедурного кеша - но как и способ выше далеко не всем помогает.
ь на загрузку и "съедаемую" процессами память все стандартно.
Да если честно - ожидаемо) Проблемы не столько в объемных операциях сколько в суммарном использовании "виртуального адресного пространства" для 32 битного процесса. Как правило эти проблемы решает сервер х64. Можно конечно пробовать выкручиваться например попробовать почаще обновлять статистику и очистку процедурного кеша - но как и способ выше далеко не всем помогает.
17.
Гость
10.04.17 14:44
та же песня... УТ 11. сервер 64! GB RAM (из них 32 съел SQL(x64)). процессы rphost - 2-3 ГБ, платформа 8.3.8.2054 (х32) (замечаю, что их не бывает больше 2-3)
Раньше перезапускал процессы: агента сервера 1С и SQL. Сейчас обратил внимание, что перезапуска ТОЛЬКО Сервера 1С достаточно, проблема уходит. Вывод - проблема в сервере 1С. Может конфигурацию попробовать обновить (сейчас 11.2.3.185, не совсем свежая).
Очистка процедурного кэша - без результата.
Раньше перезапускал процессы: агента сервера 1С и SQL. Сейчас обратил внимание, что перезапуска ТОЛЬКО Сервера 1С достаточно, проблема уходит. Вывод - проблема в сервере 1С. Может конфигурацию попробовать обновить (сейчас 11.2.3.185, не совсем свежая).
Очистка процедурного кэша - без результата.
Решили увеличением количества рабочих процессов на сервере 1С, см. скриншот. Проблема ушла полностью!
Прикрепленные файлы:
(18)У меня количество ИБ на процесс 8, а количество соединений на процесс 256, это правильные настройки? Они стояли по умолчанию и каждый день выходит "Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Ошибка выделения памяти HRESULT=80004005". Если установить как у вас на скрине параметры это не повлияет негативно на работу?
(18) Спасибо, мне помогло. Не получится ли так, что завтра все это дело грохнется? Насколько живуча данная настройка?
Было
Количество ИБ на процесс 8,
Количество соединений на процесс 256,
Стало
Количество ИБ на процесс 1,
Количество соединений на процесс 20
Было
Количество ИБ на процесс 8,
Количество соединений на процесс 256,
Стало
Количество ИБ на процесс 1,
Количество соединений на процесс 20
После обновления на новую платформу 8.3.25.1374 стало выкидывать из баз из-за ошибки "Microsoft OLE DB Provider for SQL Server: Ошибка выделения памяти HRESULT=80004005"
В моем случае резко возрасла нагрузка на ЦП до 100% из-за процесса rphost. В сеансах было большое количество фоновых задач.
Мне помогло в свойствах каждой базы установка галочки напротов "Блокировка регламентных заданий включена"
День прошел, ни одного вылета, загрузка процессора 5-10%.
В моем случае резко возрасла нагрузка на ЦП до 100% из-за процесса rphost. В сеансах было большое количество фоновых задач.
Мне помогло в свойствах каждой базы установка галочки напротов "Блокировка регламентных заданий включена"
День прошел, ни одного вылета, загрузка процессора 5-10%.
После обновления на новую платформу 8.3.25.1374 стало выкидывать из баз из-за ошибки "Microsoft OLE DB Provider for SQL Server: Ошибка выделения памяти HRESULT=80004005"
В моем случае резко возрасла нагрузка на ЦП до 100% из-за процесса rphost. В сеансах было большое количество фоновых задач. Загрузка ОЗУ 45%.
Мне помогло в свойствах каждой базы установка галочки напротов "Блокировка регламентных заданий включена"
День прошел, ни одного вылета, загрузка процессора 5-10%.
В моем случае резко возрасла нагрузка на ЦП до 100% из-за процесса rphost. В сеансах было большое количество фоновых задач. Загрузка ОЗУ 45%.
Мне помогло в свойствах каждой базы установка галочки напротов "Блокировка регламентных заданий включена"
День прошел, ни одного вылета, загрузка процессора 5-10%.
Прикрепленные файлы:
(36) Это временное решение лишь для того, чтобы стабилизировать на время поиск лучшего пути. Я его нашел.
1. Настроил во всех базах регламентные задания, чтобы они выполнялись гораздо реже и в разное время (это убрало частые загрузки процессора rphost-ом под 70-100%).
2. Уменьшил в свойствах рабочего сервера количества ИБ на процесс с 8 до 4 и больше ни одного вылета уже три недели.
Если кратко, как я понял, каждый процесс занимает 4 гигабайта памяти в 32-х битной 1С. Когда в одном процессе открыто много баз, чаще происходит переполнение этого процесса (например бух начал делать какой-то отчет) и сервер не успевает запустить новый процесс и всё падает. В свойствах даже есть параметр "Интервал превышения допустимого объема памяти". Но надо ориентироваться на размер ОЗУ.
У меня на серваке 32 гига, и так как баз 15, то максимум это 4 одновременных процесса по 4 гига. Запас по памяти для остальных нужд остается с избытком.
1. Настроил во всех базах регламентные задания, чтобы они выполнялись гораздо реже и в разное время (это убрало частые загрузки процессора rphost-ом под 70-100%).
2. Уменьшил в свойствах рабочего сервера количества ИБ на процесс с 8 до 4 и больше ни одного вылета уже три недели.
Если кратко, как я понял, каждый процесс занимает 4 гигабайта памяти в 32-х битной 1С. Когда в одном процессе открыто много баз, чаще происходит переполнение этого процесса (например бух начал делать какой-то отчет) и сервер не успевает запустить новый процесс и всё падает. В свойствах даже есть параметр "Интервал превышения допустимого объема памяти". Но надо ориентироваться на размер ОЗУ.
У меня на серваке 32 гига, и так как баз 15, то максимум это 4 одновременных процесса по 4 гига. Запас по памяти для остальных нужд остается с избытком.
Прикрепленные файлы:
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот