Запустил обработку - пишет дофига в регистр сведений никем не используемый

заметно снизилась скорость записи в БД у других пользователей,
ЦП и память в норме, не 100% загрузки

В простой модели восстановления такого не наблюдал

это мне кажется, или модель восстановления повлияла?

Лог растёт, наверное. Прирост поставил по 1К?

Если разве что распух лог транзакций (в простой модели место в нем освобождается к переиспользованию после каждого чекпоинта, которых несколько десятков в час происходит)

Разбивай длительную операцию на несколько транзакций - они хоть и не для ускорения предназначены, но сайд-эффект такой дают

(1) https://dl.dropboxusercontent.com/s/ecmbqao7prar076/2020-10-01_09h31_11.png?dl=0
это?

(4) Темпдб тоже прирост посмотри, поставь по 512 Мб хотя бы

(3) сейчас вопрос - это именно из-за смены модели восстановления?
если из-за неё, то уже вопрос, что можно сделать чтобы ...

Была ветка про разницу производительности БД в разных моделях восстановления. Симпл экономит на bulk-операциях с таблицами (меньше записывая в лог). А так при обычной работе 1С разницы вроде быть не должно. Так что скорее всего дело именно в тормозах растущего лога (выделение доп-места на диске - это дорогая операция). Когда лог выйдет на стабильный размер (если ты вовремя делаешь бэкапы лога), то по-идее производительность должна стабилизироваться...

(6) Надежный ответ на этот вопрос ты сможешь получить только эмпирически и только в чистом (изолированном) эксперименте

(0) >> это мне кажется, или модель восстановления повлияла?

Скорее всего, кажется. При условии, что настроено всё правильно и нет проблем со свободным местом на сервере.
Миф о значительном влиянии модели восстановления на скорость записи, мягко говоря, преувеличен.

Хотя конечно зависит от того, что значит "дофига", а так же - как и чем (каким документом) производится запись. Может там параллельно блокируется куча таблиц, пока пишется твой регистр.

(5) темп находится на диске в оперативке, админ говорит смысла нет, сейчас 64 мб
https://dl.dropboxusercontent.com/s/p9dqe6yh6h0xf3i/2020-10-01_09h37_06.png?dl=0

(9) дофига - это порядка 500 000 записей в РС через менеджер записи . вот только сейчас все записало

ну да - лог вырос

(11) А теперь сделай бэкап лога (только не усекай) и попробуй еще разок свои 500 тыщ записать.
Должно быть так же, как в симпле.

и достиг максимального размера

(14) Это вполне может быть причиной. Если сиквел вместо штатной процедуры вынужден постоянно переизыскивать свободное место в логе и увеличивать его фрагментацию.

А с какой частотой бэкап лога настроен?

(15) в симпле то же самое

(17) В симпле место для переиспользования само по себе появляется с большой частотой (раз в несколько минут), а в полной - только после очередного бэкапа лога

Да и вообще лучше не устанавливать пределы на максимальные размеры файлов. Оставлять неограниченным. Просто настроить мониторинг на сигнализацию о проблемах с местом на диске.

(16) 10 мин

(16)
если мы об одном и том же говорим
https://dl.dropboxusercontent.com/s/w1kan27ydi5x1io/2020-10-01_09h50_34.png?dl=0

(20) Тогда странно. 40 гиг на 10 минут должно хватать :) Но из интереса попробуйте убрать ограничение на максимальный размер. Если начнет расти - значит для нормальной работы места все-таки не хватало либо что-то не так с бэкапами транзакций.

А дисковую нагрузку профилировали? Очереди к дискам, и т.п? Эффективнее всего, конечно, сравнить "до" и "после". По-идее, эти тесты и покажут кто виноват и что делать.

(0) Кажется. Простая отличается от полной только тем, что в простой модели, после фиксации транзакции и переноса данных из LDF в MDF, место этих данных в LDF доступно для использования. В полной - только после бэкапа.  как следствие - в простой вы не можете откатиться на любо момент времени при простой модели.

(7) Можно ссылку? Ваше утверждение противоречит моему пониманию процесса. Насколько я представляю, данные ВСЕГДА сначала пишутся в LDF. После завершения транзакции они переносятся в MDF.