При реструктуризации данных вылет по ошибке. Нужно понять в чем причина
Всем доброе время суток !
Ситуация следующая.
База Бухгалтерии 3.0 релиз 3.0.41.64
Размер базы большой(более 100 Гб)
Релиз 1С 8.3 (8.3.8.1964)
При обновлении на релиз Бухгалтерии 3.0.42.33 происходит длительная реструктуризация данных (несколько часов) с вылетом в конце по ошибке
Сигнатура проблемы:
Имя события проблемы: APPCRASH
Имя приложения: 1cv8.exe
Версия приложения: 8.3.8.1964
Отметка времени приложения: 578f26ee
Имя модуля с ошибкой: MSVCR110.dll
Версия модуля с ошибкой: 11.0.51106.1
Отметка времени модуля с ошибкой: 5098858e
Код исключения: 40000015
Смещение исключения: 000a327c
Версия ОС: 6.1.7601.2.1.0.272.7
Код языка: 1049
Дополнительные сведения 1: 656b
Дополнительные сведения 2: 656b4bae5952f4a37ac9bf700ed2dd98
Дополнительные сведения 3: 86d2
Дополнительные сведения 4: 86d2eb43be4029537c284414bc2a17a3
Ознакомьтесь с заявлением о конфиденциальности в Интернете:
Если заявление о конфиденциальности в Интернете недоступно, ознакомьтесь с его локальным вариантом:
C:\Windows\system32\ru-RU\erofflps.txt
Реструктуризация проходит долго из за объема базы (несколько часов) так что просто быстро прогнать обновление и увидеть где происходит вылет не получится.
В свойствах кластера сервера 1С стоит "Перезапускать рабочие процессы при превышении памяти в 2 Гб" (процессы чуть выходят за 1 Гб)
Места на диске много.
Тестирование и исправление средствами 1С делал - все нормально.
Тестирование базы средствами SQL (DBCC) делал - все нормлаьно
Процесс 1Сv8.exe в процессе реструктуризации не выходит за 700 Мб по памяти
Падение происходит при реструктуризации РегистрБухгалтерии.Хозрасчетный (либо в процессе реструктуризации его (до конца не доходит) либо при переходе к следующему шагу - не успеваю заметить.
Кто сталкивался с подобной проблемой - просьба подсказать как ее можно решить.
Ситуация следующая.
База Бухгалтерии 3.0 релиз 3.0.41.64
Размер базы большой(более 100 Гб)
Релиз 1С 8.3 (8.3.8.1964)
При обновлении на релиз Бухгалтерии 3.0.42.33 происходит длительная реструктуризация данных (несколько часов) с вылетом в конце по ошибке
Сигнатура проблемы:
Имя события проблемы: APPCRASH
Имя приложения: 1cv8.exe
Версия приложения: 8.3.8.1964
Отметка времени приложения: 578f26ee
Имя модуля с ошибкой: MSVCR110.dll
Версия модуля с ошибкой: 11.0.51106.1
Отметка времени модуля с ошибкой: 5098858e
Код исключения: 40000015
Смещение исключения: 000a327c
Версия ОС: 6.1.7601.2.1.0.272.7
Код языка: 1049
Дополнительные сведения 1: 656b
Дополнительные сведения 2: 656b4bae5952f4a37ac9bf700ed2dd98
Дополнительные сведения 3: 86d2
Дополнительные сведения 4: 86d2eb43be4029537c284414bc2a17a3
Ознакомьтесь с заявлением о конфиденциальности в Интернете:
Если заявление о конфиденциальности в Интернете недоступно, ознакомьтесь с его локальным вариантом:
C:\Windows\system32\ru-RU\erofflps.txt
Реструктуризация проходит долго из за объема базы (несколько часов) так что просто быстро прогнать обновление и увидеть где происходит вылет не получится.
В свойствах кластера сервера 1С стоит "Перезапускать рабочие процессы при превышении памяти в 2 Гб" (процессы чуть выходят за 1 Гб)
Места на диске много.
Тестирование и исправление средствами 1С делал - все нормально.
Тестирование базы средствами SQL (DBCC) делал - все нормлаьно
Процесс 1Сv8.exe в процессе реструктуризации не выходит за 700 Мб по памяти
Падение происходит при реструктуризации РегистрБухгалтерии.Хозрасчетный (либо в процессе реструктуризации его (до конца не доходит) либо при переходе к следующему шагу - не успеваю заметить.
Кто сталкивался с подобной проблемой - просьба подсказать как ее можно решить.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(6) да сервер 1С 32bit
Стоит условие перезапускать рабочие процессы при превышении по памяти в 2 Гб
На выходных пробовал на тестовой базе обновлять.
Сеансов не было никаких (ни пользователей ни фоновых заданий).
До лимита и близко не доходило.
Процесс 1с8с.exe максимум до 1.5 Гб доходил.
Стоит условие перезапускать рабочие процессы при превышении по памяти в 2 Гб
На выходных пробовал на тестовой базе обновлять.
Сеансов не было никаких (ни пользователей ни фоновых заданий).
До лимита и близко не доходило.
Процесс 1с8с.exe максимум до 1.5 Гб доходил.
(8) Переполнение скорее всего. Процессу х32 не хватает адресного пространства для обработки массива информации. Переход на х64 сервер нужен. Ну либо обновите разово на пк где есть сервер 1с х64 и обратно загрузите. Есть вероятность что не при каждом обновлении будет вываливатсья при реструктуризации.
(9) сейчас в базе ведется учет по 2 организациям.
вы хотите сказать что если я на тестовой базе оставлю данные только по одной организации (остальные удалю) то с большой долей вероятности обновление пройдет нормально - при реструктуризации меньше проводок нужно будет пересчитывать и превышения адресного пространства не будет (если дело в нем)
вы хотите сказать что если я на тестовой базе оставлю данные только по одной организации (остальные удалю) то с большой долей вероятности обновление пройдет нормально - при реструктуризации меньше проводок нужно будет пересчитывать и превышения адресного пространства не будет (если дело в нем)
(8)
Это много на самом деле. Ведь user mode space = 2gb в win х86. Вполне может и вылететь по нехватке памяти.
В этом ли причина - не знаю.
З.Ы.
(8)
Настройки рабочих процессов в данном случае не причем. Это же клиент.
Upd:
А клиент то x64 стоит?
Процесс 1с8с.exe максимум до 1.5 Гб доходил.
Это много на самом деле. Ведь user mode space = 2gb в win х86. Вполне может и вылететь по нехватке памяти.
В этом ли причина - не знаю.
З.Ы.
(8)
Стоит условие перезапускать рабочие процессы при превышении по памяти в 2 Гб
Настройки рабочих процессов в данном случае не причем. Это же клиент.
Upd:
А клиент то x64 стоит?
К тому же у ПО написанных на разных языках этот порог разный, например e С++ около 2гб, у .Net еще меньше. Какой этот порог у 1С не знаю, но похоже еще меньше :D
Хотя я на файловых базах встречал х32 процессы больше 2,5 Гб. Тут скорее всего при реструктуризации попадается какой то большой объект(файл) в таблице.
Можно попробовать из этой статьи советы выполнить
Хотя я на файловых базах встречал х32 процессы больше 2,5 Гб. Тут скорее всего при реструктуризации попадается какой то большой объект(файл) в таблице.
Можно попробовать из этой статьи советы выполнить
Суть проблемы: важно, что под это сообщение об ошибке могут подпадать разные причины, но у них есть общая часть для 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
(11) Если я правильно понимаю перезапуск сервера 1С можно сделать когда конфигурация уже объединена с обновлением (когда в ней стоит восклицательный знак).
То есть
1. Выключить все фоновый задачи у всех баз (чтобы память сервера 1С не расходовалась на другие задачи)
2. Конфигурация - Поддержка - Обновить конфигурацию. Выбрать нужную.
Сравнить, объединить конфигурации.
Сохранить конфигурацию.
Выйти из Конфигуратора
3. Перезапустить сервер
4. Зайти в Конфигуратор и запустить реструктуризацию
Можно еще сделать лучше - падает только на реструктуризации ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные и ПланыСчетов.Хозрасчетный
В таком случае можно взять из конфигурации поставщика при сравнении, объединении все кроме этого, Сохранить конфигурацию. Применить (провести реструктуризацию).
Не запуская Предприятие (чтобы не пошла обработка данных после реструктуризаии) сравнить с конфигурацией поставщика и взять из нее только ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные и ПланыСчетов.Хозрасчетный
Сохранить конфигурацию
До этого момента доходил - все проходит нормально - проверял.
Но перезапуск сервера 1С после этого не делал.
После этого выйти из Конфигуратора, перезапустить сервер 1С и после этого зайти в Конфигуратор и начать реструктуризацию.
То есть
1. Выключить все фоновый задачи у всех баз (чтобы память сервера 1С не расходовалась на другие задачи)
2. Конфигурация - Поддержка - Обновить конфигурацию. Выбрать нужную.
Сравнить, объединить конфигурации.
Сохранить конфигурацию.
Выйти из Конфигуратора
3. Перезапустить сервер
4. Зайти в Конфигуратор и запустить реструктуризацию
Можно еще сделать лучше - падает только на реструктуризации ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные и ПланыСчетов.Хозрасчетный
В таком случае можно взять из конфигурации поставщика при сравнении, объединении все кроме этого, Сохранить конфигурацию. Применить (провести реструктуризацию).
Не запуская Предприятие (чтобы не пошла обработка данных после реструктуризаии) сравнить с конфигурацией поставщика и взять из нее только ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные и ПланыСчетов.Хозрасчетный
Сохранить конфигурацию
До этого момента доходил - все проходит нормально - проверял.
Но перезапуск сервера 1С после этого не делал.
После этого выйти из Конфигуратора, перезапустить сервер 1С и после этого зайти в Конфигуратор и начать реструктуризацию.
Попробовал поставить сервер 1С 64bit и поставить обновление на нем.
Что получается в итоге.
База падает при реструктуризации ПланыСчетов.Хозрасчетный
Отдельно добавлял изменения в ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные,
делал сохранение с реструктуризацией - все отлично проходит.
Но стоит добавить изменения по Плану счетов - идет длительная реструктуризация (примерно 4,5 миллиона) и падение.
При этом ПланыСчетов.Хозрасчетный стоит на поддержке (только на тестовой базе чтобы понять на чем падало делал возможным редактировать с сохранением поддержки).
Отличия Планов счетов между тем что используется и тем что в демонстрационной базе нового релиза
1. В текущей базе в режиме Предприятия добавлен счет 44.3.0 Расходы на продажу
В конфигурации Поставщика его нет.
Есть счета
44 Расходы на продажу
44.01 Издержки обращения в организациях, осуществляющих торговую деятельность
44.02 Коммерческие расходы в организациях, осуществляющих промышленную и иную производственную деятельность
2. По некоторым счетам в конфигурации нового релиза есть детализация по Партиям
(в текущей базе не используется) (эта детализация включается и выключается в режиме Предприятия)
3. По некоторым счетам в текущей базе есть детализация по Способы учета НДС
(эта детализация включается и выключается в режиме Предприятия)
На чем может падать ?
Что получается в итоге.
База падает при реструктуризации ПланыСчетов.Хозрасчетный
Отдельно добавлял изменения в ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные,
делал сохранение с реструктуризацией - все отлично проходит.
Но стоит добавить изменения по Плану счетов - идет длительная реструктуризация (примерно 4,5 миллиона) и падение.
При этом ПланыСчетов.Хозрасчетный стоит на поддержке (только на тестовой базе чтобы понять на чем падало делал возможным редактировать с сохранением поддержки).
Отличия Планов счетов между тем что используется и тем что в демонстрационной базе нового релиза
1. В текущей базе в режиме Предприятия добавлен счет 44.3.0 Расходы на продажу
В конфигурации Поставщика его нет.
Есть счета
44 Расходы на продажу
44.01 Издержки обращения в организациях, осуществляющих торговую деятельность
44.02 Коммерческие расходы в организациях, осуществляющих промышленную и иную производственную деятельность
2. По некоторым счетам в конфигурации нового релиза есть детализация по Партиям
(в текущей базе не используется) (эта детализация включается и выключается в режиме Предприятия)
3. По некоторым счетам в текущей базе есть детализация по Способы учета НДС
(эта детализация включается и выключается в режиме Предприятия)
На чем может падать ?
Прикрепленные файлы:
Бухгалтерия предприятия _ 3.0.41.64 _ План счетов.mxl
Бухгалтерия предприятия _ 3.0.42.33 _ План счетов.mxl
Вопрос с обновлением конфигурации победил просто не обновляя план счетов (мне изменения в нем не нужны).
Возник еще один вопрос.
Можно ли программно найти объекты конфигурации которые сняты с поддержки (или для которых включена возможность редактирования) ? Глазами подобные объекты искать сложно и неудобно.
При сравнении с конфигурацией поставщика если в сравниваемых объектах нет различий то различия не отображаются. А хотелось бы видеть эти объекты. В том числе вот для чего.
Например стоит замочек на корневом уровне документа а ниже есть его подчиненные объекты (реквизиты, модули) в режиме "Редактирование с сохранением поддержки"
Возник еще один вопрос.
Можно ли программно найти объекты конфигурации которые сняты с поддержки (или для которых включена возможность редактирования) ? Глазами подобные объекты искать сложно и неудобно.
При сравнении с конфигурацией поставщика если в сравниваемых объектах нет различий то различия не отображаются. А хотелось бы видеть эти объекты. В том числе вот для чего.
Например стоит замочек на корневом уровне документа а ниже есть его подчиненные объекты (реквизиты, модули) в режиме "Редактирование с сохранением поддержки"
1 ) сгенерируйте тестовую базу из рабочей путем копирования 1000 записей из каждой таблицы данных и все системные таблицы.
воспроизведите реструктурицацию (с настроиным ТЖ)
если ошибка воспроизведется то узнаете причину из ТЖ.
2) если ошибка не воспроизвелась значит ошибка в данных или их размере.
обновляйтесь по частям
воспроизведите реструктурицацию (с настроиным ТЖ)
если ошибка воспроизведется то узнаете причину из ТЖ.
2) если ошибка не воспроизвелась значит ошибка в данных или их размере.
обновляйтесь по частям
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот