Добрый день!
Есть комп для "экспериментов" на win7, postgress i7 6700, 32Гб памяти и SSD и есть виртуалка с win srv, ms SQL на i7 10700k, 32Gb RAM, SSD nvme.
Естественно под виртуалку отданы не все ресурсы, в отличии компа c win 7.
Так вот, dt-бекап на виртуалке восстанавливается 30 минут, на на железе - 2-3 часа.
Но при этом сам старт 1С на виртуалке происходит до 10 мин, а на железе как обычно.
При этом загрузки проца/памяти/диска не наблюдается.
С чем такое может быть связано и что какие железные ресурсы критичны при восстановлении бекапов из dt?
При расчете всяких отчетов я так понял чем больше производительность на 1-е ядро, тем лучше, да? Встречал заметки что 1С в многопоточность очень не очень.

(0) Частоту процов укажи.

На железе postgress, а на виртуалке ms SQL?

При этом загрузки проца/памяти/диска не наблюдается - разверни загрузку по ядрам.

+ очередь к диску посмотри.

(1) 3,40 vs 3,80, турбобуст 4 vs 5
(2) да, именно так.

(4) А при практически нулевой загрузке диска может быть так что в очереди беда?

Слишком много переменных.
Поставь на железо ms SQL и сравни результаты между железкой и виртуалкой. Чтобы исключить некорректную настройку postgress.

(7) +1
существует много способов убить postgress под виндой из коробки

Или закажи развертку ПГ под НИКСами у меня

Поставить на железке MS SQL (можно Express или Developer edition) и посмотреть.
Может проблема в каких-то особенностях настроек PostgreSQL. У слоника есть любовь к открытию какого-то совершенно безумного количества файлов от чего файловая система Windows начинает жестко тупить.

Версия PG какая? Если 11+ то в конф файле найди параметр max_parallel_maintenance_workers, поставь значение равное половине количества ядер проца. ДТшник должен по шустрее начать грузиться.

>>Windows начинает жестко тупить
Поэтому и желателен Linux, + более эффективная работа с памятью.

(12) Так это постгре под виндой тупит, а не винда.
Что взять со студенческой под(д)елки?

(12) >> желателен Linux.

Он желателен, если соблюдается пара условий.
Ты умеешь в Linux или под рукой есть умеющий админ.
Речь о продуктивной системе, а не, как у автора, - комп для "экспериментов".

Ну и разумеется немаловажно - для чего именно используется система. Если речь о небольших типовых базах, работающих с обычной нагрузкой 8/24 и 5/7, то заморачиваться с системой, которую плохо знаешь, ради копеечной выгоды в производительности, которую никто не заметит, смысла мало.

(13) Именно винда. Она, видите ли, не умеет удалять и переименовывать открытые на чтение/запись файлы, ждет, пока они закроются. Пока наргузка на СУБД не слишком не слишком высока, это не так заметно. В Postgres Pro пытались что-то сделать, пишут, что помогло Начались проблемы с производительностью сервера 1С

(15) Нет. Это постгре не умеет работать толком под виндой.
У МССКЛ же нет таких проблем с файлами.

(15)>> Она, видите ли, не умеет удалять и переименовывать открытые на чтение/запись файлы, ждет, пока они закроются.

А разве это не задача разработчика ПО - учитывать особенности операционной системы (точнее даже - файловой системы ОС), для которой он пишет своё ПО?
Если я правильно помню, тут совпали две истории. С одной стороны "особенности" работы 1С с СУБД, выраженные в любви к созданию огромного количества временных таблиц. С другой стороны - "особенности" ограничений файловой системы Windows. А разработчики просто не предполагали подобного сценария работы с их СУБД. Никому в голову не пришло, что можно так безбожно насиловать базу данных и непрерывно генерировать такое множество маленьких временных таблиц. Когда это всплыло, начали ломать голову над способами обхода (заплатами).
Если я ничего не путаю, то в последних сборках PostgreSQL и патчах к нему для 1С проблема как-то решена. Потому и написал, что для чистоты эксперимента автору ветки следовало бы поставить на тестовый комп MS-SQL вместо PostgreSQL. Чтобы исключить фактор возможной некорректной работы слона с NTFS Windows. Это быстрее и проще, чем полностью переустанавливать ОС с Win на Lin и настраивать её. Можно было бы конечно развернуть готовый образ виртуалки, но это уже другая история.

у скуля же единый файл. ну и файл мастер и темпдб
или речь про другое?
под виндой когда проблемы с диском бывали помогало опиграться с парамтерами FILES и BUFFERS
но это было на древних ОС, на современных не должно быть такой проблемы, там адекватные значения по умолчанию уже.

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

Разработчики PostgreSQL тоже так думали. Пока не увидели, как 1С умудряется заставить один процесс держать открытыми более 1000 файлов. И удивились.
А работать с потоками и страницами, как делает MS-SQL, PostgreSQL не умеет.

(9)
В таком случае СУБД будет на Постгри, а сервер приложений 1С - на винде?
Это должны быть виртуалки, или разные железки?
Если разные железки, то не будет ли потерь производительности по сети между ними?
Есть опыт такой архитектуры?

(18) Вот эта проблема - "не удалось переименовать временный файл статистики из "pg_stat_tmp/global.tmp" в "pg_stat_tmp/global.stat": Permission denied". К 1С это непосредственного отношения не имеет.
Доклад, в котором все очень подробно объясняется https://www.youtube.com/watch?v=NmPa3m50JJU&t=1361s
Не думаю, что такое поведение проявляется именно из-за каких-то особенностей NTFS. Проверить можно на том же Linux и диске, отформатированном в NTFS, переименовать открытый файл.

(20)
Поправка:
(9)
В таком случае СУБД Постгри на линуксе, а сервер приложений 1С - на винде?
Это должны быть виртуалки, или разные железки?
Если разные железки, то не будет ли потерь производительности по сети между ними?
Есть опыт такой архитектуры?

(21)
Крутая информация, спасибо за видео!

(23) Это из ссылки в (15), наш коллега раскопал.

Залез в логи, пишет что "checkpoints are occurring too frequently (17 seconds apart)"
Это видимо оно. Попробую исправить по гайдам в инете.

PostgreSQL checkpoints are occurring too frequently