Все привет.
В 1С 8.3.10 выполняется длительная операция > суток. При этом ресурсы сервера (в данном случае CPU) используются на 25%. Есть ли возможность понять какое узкое место на сервере и увеличить скорость работы 1С?
https://d.radikal.ru/d34/1809/95/a5d4723ae245.jpg
https://d.radikal.ru/d04/1809/95/d43ae538606d.jpg

А что ты ожидал увидеть? 1С одноядерное приложение и больше 1-го ядра за раз не может использовать

Одноядерный процессор поставь и наслаждайся загрузкой

+ (0) скажи, а точно радикальный противник использования кнопки PrtScr?
Тебе религия не позволяет? Или внутренние убеждения? Или, может СБ тебе туда 380 вольт подключила?

(1) 2-й скрин да, один процесс грузит полностью одно ядро. 1-й скрин сумма загрузки процессами ядер тоже около 25%. Неужели нет вариантов?

(4) Я понять не могу что за 1С у тебя

Судя по второму это файловая, тогда причем тут 1 скрин?

(3) может у меня сервер вне внешней сети и интернета?!

(6) И ты снимаешь через окошко на улице? Какая религия запрещает сделать скриншот на той машине что сидишь?

(5) да, 1-й скрин это серверная, 2-й это файловая.

(8) Так сколько 1С у тебя запущено и что ты ускорить собираешься?

(0) 1 ядро на проце - вот твое узкое место.
варианты лечения: взять процессор помощнее (чтобы отдельное ядро было значительно сильнее).
распараллелить нагрузку. если позволяет задача - запустить (число потоков минус 1) инстанца, чтобы каждое ядро повисло на 100% загрузке.

ну и все от задачи зависит. в 99.59% случаев такие проблемы решаются исправлением запроса, оптимизацией обработки данных.

(9) на 1-м скрине одна 1С запущена серверная, на 2-м запущено две 1С, действия выполняет только файловая.
Хочу, чтобы использовала ресурсы сервера. Из 4-х ядер используется одно, как серверной так и файловой версией. Давали 36 ядер, загрузка проца 3-4%.

(10) Уже лет 10 мечтаю, что появятся процессоры, в которых вырастет многократно мощность одного ядра. Либо ПО начнет использовать нормально ядра. Речь в теме есть ли варианты ускорить работу без оптимизации алгоритмов и распараллеливания запросов и т.п. в самой 1С?

(12) При таком описании максимум что ты можешь услышать это (11)

Какое оборудование, какая задача.

Одно дело когда пишутся в справочник линейно данные и тут сложно программно ускорить.
Другое дело когда идет выборка и тут можно смотреть план запроса, попадает ли выборка в индексы

(13) Да увеличить частоту процессора. Заменой или разгоном

(14) В 1С в этот момент (2-й скрин) выполняется ПланыОбмена.ПрочитатьИзменения(). Читается xml файл размером 23 Гб. Т.е. оптимизация кода в данном случае в 1С невозможна.

(16) Если у тебя накопилось изменений на 23ГБ - это не проблемы 1с. Это проблемы настройщиков обмена

Итить колотить... 23 Гб...
Признайся - сколько по времени такой обмен формируется?

(17) а если мне нужно развернуть узел из центра, в котором за 2 года работы куча объектов накопилось, которые необходимы в новом узле?
(18) xml-файл формируется около 12 часов. Читается в несколько раз дольше. Вот это и хотелось бы ускорить. А так хоть 100 ядер выделяй и пол терабайта ОЗУ толку нет.

(19)
Существует куча способов создать узел, не прибегая к штатной выгрузке

(20) Как мне создать новый узел, выгрузив в него пол миллиона элементов номенклатуры, тысячи контрагентов, данные из десятков прочих справочников, тысячи документов не прибегая к штатной выгрузке, чтобы при этом ускорился общий процесс сколь либо значительно?

(21) типа Книга знаний: Альтернативное создание начального образа в УРБД;

(22) спасибо за ссылку, но из центральной базы 500 ГБ сделать копию и очистить гигов 450 будет наверное дольше, чем создать периферийный 50 гиговый узел штатными средствами.

(23) даже если тобой будет проведено исследование разных приложений, то ты удивишься - почти абсолютное большинство приложений не умеет использовать более одного ядра при создании всего одного процесса. Можешь из интереса посмотреть при запущенном браузере с множеством вкладок на количество созданных процессов браузера. Можешь посмотреть сколько процессов создает скайп и т.д.
В этом смысле приложения 1С ничем не лучше. Представь, что открытый только один сеанс пользовательский = одной вкладке браузера...
Другими словами, распараллеливание длительных операций, если это реализовано типовыми способами, до делается запуском фоновых ПРОЦЕССОВ. И вот тогда можно увидеть, что эти процессы садятся на разные ядра. Но! При работе в клиент-серверном режиме нужна правильная настройка 1С кластера серверов.

з.ы. В твоем частном случае этого распараллеливания нагрузки не сделаешь.

25% в среднем - использование 1 ядра на 4-ех ядерном процессоре (ядра могут быть и виртуальными тоже)
3-4% на 36 ядерном - это тоже загрузка только одного из 36-ти ядер

(24) спасибо, хорошо описал! Итого единственный вариант - это распараллеливание выгрузки и загрузки объектов с помощью отдельных сеансов работы 1С либо фоновых заданий. В серверном варианте, возможно, придется увеличивать количество rphost'ов ограничивая число соединений.

(26) в общем случае бред и практически не реализуемая задача

Грубо говоря таблица изменений и таблица планов обмена одна на объект и на ней нельзя наложить "гибкие" блокировки.
А значит выгружая номенклатуру в одном сеансе платформа будет блокировать всю таблицу изменений номенклатура (так как она будет туда писать номер выгружаемого пакета) и другой сеанс нарвется на "блокировку" и выпадет в ошибку транзакции.
Даже если предположить что мы будет в каждом сеансе выгружать "свой" объект то во первых таблица планов обмена одна и значит при выгрузки пакета он будет писать туда номер выгруженного пакета, а значит если два параллельных пакетах попытаются записать туда очередной номер, то несложно догадаться что будет в этом случае.
И это мы еще упускаем из виду тот факт что типовыми средствами такой сценарий нельзя будет реализовать.
Типовой сценарий подразумевает что выгружаются в пакете все изменения и если потом прилетает подтверждение, то значит все считается что все пакеты до этого номера успешно загружены.
Например выгрузили номенклатуру, пакету присвоится номер 42. Выгрузили контрагентов - номер 43. При загрузки подтверждения с номером 43 1с будет считать что пакет 42 тоже успешно загружено. Т.е. нельзя выборочно подтвердить пакет.

Вот именно поэтому народ отказывается от типового механизма и реализовывает свой, например на РС, где можно наложить и блокировку и выборочное подтверждение

(28) Чет дичь какая-то.

Щас проверим.

А не, все верно. Я перепутал с записью 2 элементов справочника.

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

У меня например так и работает.

(32)+ при этом обе задачи как выгрузки, так и загрузки, хорошо и не сложно параллелятся разными сеансами, при условии формирования нескольких файлов.