Падение конфигуратора по памяти при переходе с ERP 2.0 на 2.1
Доброго времени суток. Мое разочарование не знает границ. Осуществляем переход с хорошенько доработанной ERP редакции 2.0 на 2.1, и при попытке смерджить изменения конфигуратор вылетает по памяти, т.к. процесс отжирает около 2.5 гигов оперативы (видимо 1с-ники компилируют конфиг с ключом позволяющим процессу жрать больше 2- ух гигов). Около недели длилось это хождение по мукам, после чего мы плюнули на этот переход. Сколько будет длиться это мучение с большими конфигурациями на 32x-ух битном толстом клиенте? Есть ли какие-то подвижки в этом направлении со стороны 1с, и можно ли как-то ускорить появление конфигуратора x64? Надежда дожить до нормальной версии EDT угасает с каждым днем.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) Чёрт, старайтесь более понятно изъяснятся. Если мы говорим о 1С то и употребляете те термины которые 1С предлагает, что бы вас понимали однозначно.
По проблеме: попробуйте очистить программный кэш (это я имею ввиду папки в профиле с именами "Config" и "ConfigSave"), поставьте последнюю платформу. Ещё я бы попробовал удалить конфигурацию поставщика - в "Настройки поддержки" кнопка "Снять с поддержки".
Ничего не помогло - тогда, мне кажется, остаётся только писать в поддержку 1С, отправлять cf файл на анализ. Это не быстро, но других вариантов не вижу.
По проблеме: попробуйте очистить программный кэш (это я имею ввиду папки в профиле с именами "Config" и "ConfigSave"), поставьте последнюю платформу. Ещё я бы попробовал удалить конфигурацию поставщика - в "Настройки поддержки" кнопка "Снять с поддержки".
Ничего не помогло - тогда, мне кажется, остаётся только писать в поддержку 1С, отправлять cf файл на анализ. Это не быстро, но других вариантов не вижу.
(8) Если вы хотите бить по рукам за терминологию то мердж (англ. merge - объединять, сливать, соединять), мерджить, смерджить применяется как руссифицированная версия в русскоязычной IT-среде и в 1С в том числе. Я наверное поверхностно объясняю. Проделывалось это на разных машинах, на конфиуграции с пустой базой, если объединять без изменения настроек объединения, когда доработанные объекты, измененные в новой конфигурации поставщика заменяются, по возможности, на новые, то обновление конфигурации поставщика и основной конфигурации происходит нормально. Перетаскивать весь код руками мы пока не готовы.
(9)В 2.1 наменяли столько, что треть ваших доработок, наверняка, уже не актуальна, а треть придется переделывать. Как вариант выгрузить cfU(между типовой текущей конфой и изменной конфой), накатить типовое обновление без сохранения изменений, мерджить с полученным cfu. Памяти на такое сравнение-объединение надо на порядок меньше.
Делать все, офк, в тестовой базе, чтобы при первом обновлении(типовом) не слетели добавленные объекты/реквизиты.
И вообще, есть же Переопределяемые общие модули. В типовых обновлениях они всегда пустые. Самое время для рефакторинга изменений.
Делать все, офк, в тестовой базе, чтобы при первом обновлении(типовом) не слетели добавленные объекты/реквизиты.
И вообще, есть же Переопределяемые общие модули. В типовых обновлениях они всегда пустые. Самое время для рефакторинга изменений.
(10) Совершенно верно, некоторая часть кода, около 30% потеряла актуальность, или требует серьезной переработки из-за изменения зависимых механизмов. Да, ваш вариант можно попробовать, количество используемой памяти должно уменьшится (сейчас в память идут около 2 Гб только на конфигуратор с диалогом сравнения\объединения, при объединении к этому прибавляется еще и память для обработки действий объединения), но придется проделывать то-же самое что и при обычном объединении, только без трехстороннего сравнения, без него с сильно доработанными вещами бороться это боль.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот