Есть такая система
win7х64
i 7700K (4 ядра, 8 вирт. потоков)
32 гига ОЗУ
SAMSUNG M.2 970 PRO 1,0 Tb
И база УПП на 20 гигов (в архиве ~2 гига), в которой нужно перепровести документы с 2013го года.
Закинул базу на этот супер-пупер диск и оказалось, что он все равно не тянет такую нагрузку и оказывается самым слабым звеном.
Может еще чего подкрутить на нем надо или "это норма"?

пока единственное оптимальное решение - сделать вирт. диск из ОЗУ и на нем обрабатывать. Тогда проц показывает постоянную полную загрузку одного потока. Но мне надо несколько вариантов проведения попробовать.

Узкое место - файловая база на 20Гб, в которой нужно перепровести документы с 2013 года. ¯\_(ツ)_/¯

(0) скорее всего там в проц упирается, а не диск

как понял что диск виноват? а не проц например?

(2) Готовься к большой любви.ГБ спросил хоть?

(4) (3) тогда почему если проводить "на оперативке", то проблем нет?
А так смотрел на его загрузку, было ~50% и на проце загрузка потока 1с постоянно прыгала.

(0) >он все равно не тянет такую нагрузку и оказывается самым слабым звеном
Пруфы есть?

Прежде всего нужно понять, где именно узкое место. Потом уже "крутить". Если не хочешь тратить время на анализ, не жди толковых советов.

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

(8) Алгоритмы одинаковые. И можно распараллелить, там где это имеет смысл. Тогда у "супер-пупер диска" появится шанс себя показать.

монопольный режим включи при старте

(0) Размер базы какой?

добавить оперативки и сделать ram drive

можно через https://www.osforensics.com/tools/mount-disk-images.html

ЗЫ
Подскажите ramdrive аппаратный сча можно купить?

Еще вариант sql
Заметил что 1С последнее время дико щемит файловую и на даже худшем цуко железе многие монопольные по сути операции быстрей не сиквеле чем файловой

Например ТиИ на одинаковой средней такой базе БП3 быстрее на postgres на дерьмовом железе чем на отличном на nvme файловой
я охренел

(13)+ *сы, сэр

(13) может они просто оптимизировали на скл? и теперь там запросами, а не перебором записей

(15) запросы это тоже переборы записей, просто сервер sql это умеет делать в несколько потоков

(16) скл умеет в индексы + кэш

(17) проверка всех реквизитов на пустые ссылки и индексы и кэш идут лесом
остается только дико затормозить файловую дергая ключ на каждые N операций

Мое мнение что 1С щемит файловую в угоду серверной
И щемит аппаратные ключи в угоду программным
Короче бабло побеждает как обычно

Аппаратный ключ железка сама денег стоит и его можно передать
Программный это просто набор байт - бесплатно считай и хрен передашь

(12)
Имею аналогичное наблюдение.
Базы на скуле работают быстрее и стабильнее файловых даже в монопольном доступе.
Доказательств, конечно же, никаких я не имею, чисто субъективно.

(20) хочешь сказать и проведение будет быстрее?
ТиИ в несколько раз на sql пройдет, но проведение в несколько раз медленнее.

(21)
УПП... не знаю...
Один из примеров: база УТ11 на скуле стала проводиться в разы быстрее файловой (монопольно).

(0) всё-таки наверно на супердиск надо забрасывать не базу, а временные рабочие папки, кеши и т.п. То что сама база на суперпупер диске, а всё остальное на дряхлом стареньком диске С, ничего не даст.

(0) Итоги у тебя по какую дута рассчитаны?

(23)
С этим тоже нельзя не согласиться

(24) по май этого года
https://b.radikal.ru/b05/2105/70/72d3bf23d258.png

(23) система тоже на ССД крутится, но просто SATA

(26) Ну вот и посчитай сколько итогов нужно платформе посчитать после проведения одного документа?
Хотя бы по годам раздей. Установить расчет на декабрь 2013 и проведи за 2013. Потом так же следующий года. Должно быть быстрее.

(0) Стесняюсь спросить чем вызвана задача перепровести аж за 8 лет почти?
Может если что-то одно подправить быть может проводить только нужный регистр в документе?
Правда надо чуток временно переделать код. Или обойтись обработкой.

Я вот менял по одному регистру  в УТ 2 каз (считай УТ10) движения за 3 года просто обработкой.
И то на это потратил почти 12-15 дней.

(29) поменять способы распределения затрат, плюс попробовать объединить все подразделения в одно
Если что, это партионка

(0) у фирмы нет 80к на сервер 1с и Бесплатный Postgree?

(0) сходи к тем у кого есть SQL сервер, там перерповеди, потом забери себе взад

(32) да есть там сервак, только проводиться будет не три дня, а три недели

(33) Если сроки проведения критичны то надо думать как проводить ускоренно.
Есть возможность при проведении доков не трогать некоторые регистры
а проводить именно по нужным по регистрам.
Но для этого как я выше сказал надо временно сделать изменения в модулях проведения документов.
Так можно существенно сократить время проведения доков.
Если нет проблем краснотой временно отключить проверку отрицательных остатков.

убрал файл подкачки и все запорхало

(19) См. https://ru.wikipedia.org/wiki/Бритва_Хэнлона
Если лень переходить - Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью.

Хотя это конечно заманчиво - считать что в 1С работают сверхчеловеки и все баги делаются сознательно, потому что они злые)