После обновления платформы каждый день у пользователей появляется ошибка: "Ошибка СУБД: 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. Ошибка уходит после рестарта. Кто сталкивался? В чем может быть проблема?
(3) Увеличьте шаг роста базы до 515мб, на файл журнала транзакций тоже самое, ограничений на максимальный размер лога быть не должно.
Далее в локальных политиках безопасности найдите строку локальные политики\назначение прав пользователей\выполнение задач по обслуживанию томов и добавьте в свойствах пользователя от которого запускается служба MS SQL Server. По дефолту это "NT Service\MSSQLSERVER"
Эта настройка позволит MS SQL Server мгновенно инициализировать место под создание новой базы и мгновенно расширять размер существующих.
Дополнительно можно системную базу temp разбить на несколько файлов (4 рекомендуется для крупных внедрений) и установите для каждого файла начальный размер 1024 и шаг роста 512.
Далее в локальных политиках безопасности найдите строку локальные политики\назначение прав пользователей\выполнение задач по обслуживанию томов и добавьте в свойствах пользователя от которого запускается служба MS SQL Server. По дефолту эт
(7) Память у SQL Сервера обязательно ограничивать. Иначе процедурный кэш забьёт всю память в сервере, которая есть.
Вопрос про разрядность сервера 1С очень хороший, кстати.
(4) а можно немного подробнее, про рекомендацию разбиения. Встречал пару раз такое, но толком никто не смог объяснить что это дает и почему 4, а не 2 или 5.
или может есть занимательно чтиво на эту тему?
(19)Это делается для ускорения ввода/вывода. Когда с tempdb работают несколько сессий возникает внутренняя конкуренция за ресурсы - соединения с файлом.
Лучше ставить от 2 до 8 в зависимости от количества ядер процессора (логичестких). Больше 8 ставить не нужно.
Минимальный размер выставляется 1024 для базы и 512мб лог для небольших баз - в большинстве случаев этих цифр более чем достаточно, если конечно у вас база измеряется не сотнями ГБ
толком никто не смог объяснить что это дает и почему 4, а не 2 или 5.
Выше параллельность и скорость работы, в общем случае.
Смысл рекомендации такой же как и у MaxDoP = 1 для MS SQL - потому что, в большинстве случаев, 4 (по количеству физических ядер процессора) лучше чем 1 и имеет больший смысл чем 9-10.
На самом деле оптимальное значение необходимо подбирать экспериментальным путём, проводя тестирование после каждого изменения настроек. Но, это дорого, долго и не все это умеют.
В общих чертах описано и на итс, и в библиотеке типовых вопросов крупных внедрений. А на подробное описание в разделе MS SQL ссылку уже дали.
Ваш случай это 2я половина текста. Основная суть процесс х32 не может работать с адресным пространством достаточным для обработки массива информации. Соответственно - это переполнение. Совет перейти на х64 севрер 1с или ниже, есть вариант как пофиксить таблицы конфигурации.
Вот сам текст.
Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 1С — это не достаточно оперативной памяти. А еще точнее неэффектиное использование ресурсов памяти. Отсюда косвенные способы победить проблему: путем рестарта сервера (на некотрое время становиться больше доступной памяти) или перейти на 64-разрядный сервер приложений.
1С:Предприятие 8.2. Лицензия на сервер (x86-64)
По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.
Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):
1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель «запрет на фоновые задания» в
момент создания базы.
Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском — вещь в себе — и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять — возможно проблема «уйдет».
2. Перезапустить сервер
Второй шаг является частным случаем для вашего случая и после него тоже
есть смысл проверять работоспособность. Однако поскольку существуют утечки памяти http://www.gilev.ru/1c/memleak, то через некоторое время после рестарта пролема может вернуться.
3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться «возврат» к предыдущему состоянию данных
4) снимаем базу с поддержки, выгружаем cf
убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение) убиваем в менежмент консоли базе данных в таблице config запись более 120Мб, делаем «загрузить конфигурацию» (не объединение)
1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FR OM dbo.Config WH ERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.
(14)Не помогли и эти действия, все равно примерно раз в день выдает ошибку. При чем создается впечатление, что проблемы с объемными операциями. После завершения которых, память как будто не освобождается, хотя если смотреть на загрузку и "съедаемую" процессами память все стандартно.
ь на загрузку и "съедаемую" процессами память все стандартно.
Да если честно - ожидаемо) Проблемы не столько в объемных операциях сколько в суммарном использовании "виртуального адресного пространства" для 32 битного процесса. Как правило эти проблемы решает сервер х64. Можно конечно пробовать выкручиваться например попробовать почаще обновлять статистику и очистку процедурного кеша - но как и способ выше далеко не всем помогает.
та же песня... УТ 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, не совсем свежая).
(18)Мне помогло, тьфу 3 раза. Получается, что чем больше баз одновременно работающих, тем меньше памяти выделяется для каждой в рамках единственного процесса?
(18)У меня количество ИБ на процесс 8, а количество соединений на процесс 256, это правильные настройки? Они стояли по умолчанию и каждый день выходит "Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Ошибка выделения памяти HRESULT=80004005". Если установить как у вас на скрине параметры это не повлияет негативно на работу?
31.
user629927_designer_79
24.10.23 11:08 Сейчас в теме
(18) Спасибо, мне помогло. Не получится ли так, что завтра все это дело грохнется? Насколько живуча данная настройка?
Было
Количество ИБ на процесс 8,
Количество соединений на процесс 256,
Стало
Количество ИБ на процесс 1,
Количество соединений на процесс 20
После обновления на новую платформу 8.3.25.1374 стало выкидывать из баз из-за ошибки "Microsoft OLE DB Provider for SQL Server: Ошибка выделения памяти HRESULT=80004005"
В моем случае резко возрасла нагрузка на ЦП до 100% из-за процесса rphost. В сеансах было большое количество фоновых задач.
Мне помогло в свойствах каждой базы установка галочки напротов "Блокировка регламентных заданий включена" День прошел, ни одного вылета, загрузка процессора 5-10%.
После обновления на новую платформу 8.3.25.1374 стало выкидывать из баз из-за ошибки "Microsoft OLE DB Provider for SQL Server: Ошибка выделения памяти HRESULT=80004005" В моем случае резко возрасла нагрузка на ЦП до 100% из-за процесса rphost. В сеансах было большое количество фоновых задач. Загрузка ОЗУ 45%.
Мне помогло в свойствах каждой базы установка галочки напротов "Блокировка регламентных заданий включена" День прошел, ни одного вылета, загрузка процессора 5-10%.