Имя: Пароль:
1C
 
Обновление 1С:УХ 3.0 -> 3.2, обработчики не успевают за выходные
0 GANR
 
30.11.25
19:53
Решили обновить 1С:УХ после 5-летней паузы с 3.0 на 3.2. Обработчики обновления 3.2.6.72 не успевают выполниться за выходные. Идут массовые записи в регистр накопления "Операции бюджетов" 200000 раз где-то.

Идеи по ускорению от простого к сложному. Отключить итоги по регистру куда запись идет, втиснуть несколько операций записи в 1 транзакцию, раскидать операцию с объектами на несколько фоновых заданий.

Что ещё тут можно сделать? Делитесь идеями.
1 Бычье сердце
 
30.11.25
20:09
ждать не предлагать?
2 GANR
 
30.11.25
20:15
(1) Ждать чего? Если с пятницы 17:00 до понедельника 9:00 не успели отработать обработчики придется из бэкапа возвращать 3.0 на которой были. Работу 100 пользователей останавливать нельзя. Промежуточные конфигурации годятся только для прохождения обработчиков - работать на них невозможно.
3 Бычье сердце
 
30.11.25
20:39
(2)
Ждать результатов работы обработчиков!!!
Отключать итоги, пробовать втиснуть несколько операций в одну транзакцию - баловство, если совсем нечем заняться.
4 GANR
 
30.11.25
20:46
(3) "Ждать" значит либо останавливать работу 100 человек в 1С, чего не позволят сделать. Либо придется встречать Новый Год в этом кресле глядя в конфигуратор. Вы когда-нибудь встречали Новый Год сидя в конфигураторе?
5 Бычье сердце
 
30.11.25
20:48
(4)
Вот вы и нашли решение)))
6 shuhard
 
30.11.25
20:49
(4)[ Вы когда-нибудь встречали Новый Год сидя в конфигураторе?]
неоднократно
для перехода на ERP окно с 31.12 по 5-7.01
7 shuhard
 
30.11.25
20:52
(0)[Что ещё тут можно сделать?]
Для начала на копии базы на сервере с близкими к продуктиву ТТХ определить длительность процедуры

варианты для не хватает 1-2 дней и займёт 2-3 недели разные
8 Kongo2019
 
30.11.25
21:28
(0) Добудь машину с быстрым процом. 1С так и не научилась в параллель.
9 GANR
 
30.11.25
21:31
(8) скорость процессора очень хорошая 12 ядер, 128 Гб ОЗУ, а сервер чилит - недоиспользует мощности явно
10 Kongo2019
 
30.11.25
21:42
(9) Xeon какой нибудь, да еще на виртуалке скорей всего.
Не, 1С любит частоту и монопольность.
Файловая вообще летает.
11 GANR
 
30.11.25
21:47
https://infostart.ru/1c/articles/2508120 - вот этой штукой ещё можно записать движения 200000 документов за ОДНУ операцию.
12 d4rkmesa
 
30.11.25
22:16
(0) Изменение количества потоков обновления не дает какого-либо эффекта?
13 GANR
 
30.11.25
22:18
(12) как проверили?
14 d4rkmesa
 
30.11.25
22:29
(13) Субъективно, пробным обновлением. ) Поставил 24 потока и в обработке "Результаты обновления программы" или отчете по результатам понаблюдал, как обработчики пролетают (можно сеансы еще помониторить с фоновыми заданиями).
Однако, например, при переходе на 2.5 был единственный однопоточный обработчик, который работал больше суток.
15 Гость из Мариуполя
 
гуру
30.11.25
22:58
(9) скорость процессора очень хорошая 12 ядер, 128 Гб ОЗУ
вот жеж очередная жертва цифр :)) тебе уже пара человек сказали - для того, чтобы уложиться в отведенные сроки, нужно другое железо.
как бы тебе попроще объяснить, на пальцах...

вот прикинь, КАМАЗ влёгкую тащит 15 тонн, а сраная ВАЗовская восьмерка летает по трассе в два раза быстрее груженного КАМАЗА. Так вот твой сервер - это КАМАЗ, и он влегкую тянет 100 пассажиров. Но всем при этом сильно уступает сраной ВАЗовской восьмерке в однопотоке с одним пассажиром. Но при этом 15 тонн сраную ВАЗовскую восьмерку просто расплющат.
Нафик при однопотоке в монопольном режиме не нужны аж цельных 12 ядер. От слова вообще нафик.
В этой твоей задаче 1С нужно одно, но очень быстрое ядро и быстрый NVME Диск.

а сервер чилит - недоиспользует мощности явно не-а.
Одно дело тащить 100 юзеров, именно под это сервер со своей кучей ядер и заточен. Ну и естественно по надежности нормальный сервер не сравнить с обычным дескотопом.
И другое дело везти "в одного", вот при этом твой сервер, как ты выражаешься - "чилит". А на самом деле нет у него (у сервера) таких ресурсов, а у рядового десктопа - есть.

Давай я попробую угадать, что ты подразумеваешь под словами "чилит" и "недоиспользует мощности". Может быть загрузка ЦП показывает в районе 9 плюс минус процентов. Это как раз и говорит о том, что одно ядро молотит на 100%, а остальные 11 ядер простаивают. И получяается загрузка ЦП в районе 8-10%

Это просто разные задачи - обеспечивать работу 100 юзеров или выполнять в монопольном режиме обновление. В этом плане хороший сервер может оказаться не таким уж и хорошим.
16 GANR
 
01.12.25
11:07
Итак какие идеи:

- отключение итогов
- транзакции
- многопоточка
- запись проводок по 200000 документам за 1 раз https://infostart.ru/1c/articles/2508120
- файловая база
- процессор с повышенной тактовой частотой
- Новый Год в Конфигураторе

Какие ещё пути?
17 Timon1405
 
01.12.25
11:11
можно так, но там команда специалистов на переход нужна
https://rarus.ru/publications/20230831-ot-ekspertov-1c-obnovlenie-bazy-erp-cherez-kopiu-614723/
18 scanduta
 
01.12.25
11:13
(0) студентики из 1с опять сделали очень плохую архитектуру , на сей раз видимо в бюджетной части. Здесь только остается посочувствовать.
19 Bigbro
 
01.12.25
11:37
"Какие ещё пути?"
можно еще глазами посмотреть по обработчикам что там выполняется. если много релизов перешагиваете - есть шанс что какие то из обработчиков уже ненужные, а что-то выполняется повторно.
20 d4rkmesa
 
01.12.25
11:46
(17) Это целый проект, особенно забавный пункт "Подготовка правил обмена для выгрузки данных из эталонной базы в обновленную копию.". Т.е. нужно просто взять "старый советский ..." и создать правила, чтобы при выгрузке любых объектов данные остались консистентными. В общем, на ИС писали, что это полная хрень, вроде в более новых версиях методики там уже есть специальный план обмена РИБ для этой цели.
21 shuhard
 
01.12.25
11:48
(16)[Какие ещё пути?]
обновление на копии базы и с переносом наработанного в продуктив по завершению процесса
22 ZloyBrawler
 
01.12.25
11:49
(0) что мешает обновлять базу всегда при выходе обновлений, а не затягивать до такой ситуации
Всегда обновляем свою ERP оперативно разгребая проблемы постепенно, а не обрушивая их все одним разом установкой нового релиза длительной поддержки


Да в приходилось встречать новый год с конфигуратором но это релиз 2.5.7 такой веселый был
23 d4rkmesa
 
01.12.25
11:52
(22) Вы же, кажется, пробовали обновление через копию (читал статью на ИС)? По описанию похоже на лечение проблемы при помощи русской рулетки.

(16) >>- Новый Год в Конфигураторе

Наше все, хотя я уже лет 8+ не практиковал. )
24 ZloyBrawler
 
01.12.25
12:00
(23) вопрос решился при помощи кампа i9 12900k, 128gb ddr4, система на samsung 980 pro 1tb, база на m.2 2tb
1.5 дня и норм
Камп мой домашний)))
Накачал в настройках базы 64 потока и смотрел как проц жрал как не в себя 200+ ватт и грел квартиру))) то была прошлая работа и то базу я обновил им по отдельному договору уже уволившись на тот момент как два месяца


Сейчас 2tb уже мало.
Но благо есть ssd больших размеров.
Пока на работе текущей сервера вывозяи
25 maxab72
 
01.12.25
12:03
а если сделать прыжок за два раза? УХ 3.0 - УХ 3.1 - УХ 3.2?
26 Anton1307
 
01.12.25
13:13
(4)
Вы когда-нибудь встречали Новый Год сидя в конфигураторе?

Неоднократно
27 GANR
 
01.12.25
15:10
(17) Звездолет. Объемы данных не те, да и окна побольше - 2 выходных целых да ещё и праздники.
(22) Банально. Заказчик первоначально задумывал базу без прицела на обновления. Однако сейчас все-таки приспичило привести её в легко обновляемое состояние и обновлять впредь регулярно.
(25) В 2 разных окна по 2 выходных то? Тогда придется 3.1 доводить до рабочего состояния, а это долго. Лучше Новый Год в Конфигураторе.