База УТ 11.4.12.77 закрытие месяца в файловом варианте 5-10 минут, в Серверном расчет себестоимости более 3 часов, память использует всю. Документов всех за месяц не более 500 с 1-5 позициями номенклатуры. Метод ФИФО. Предварительный расчет себестоимости включен.
Платформа 8.3.17.1549. Сервер новый, большой производительности Xeon 4.00 GHz, WS 2019 Standart , 1c на SSD, SQL 2016, память 64 Гбт,
Что надо сделать, какие настройки, чтобы закрытие проходило быстрее и без израсходования всей памяти сервера.
Инструкция по настройке рабочих серверов от 1с не помогает https://its.1c.ru/db/metod8dev/content/5908/hdoc. По форумам тоже решение не нашел. Распределение затрат и расчет себестоимости просто висит часами.
(1) Как организована система хранения данных для MS SQL?
на каком диске хранится tempdb/журнал транзакций для БД/файлы БД?
Память для MS SQL необходимо ограничить.
Как надо, для решения именно закрытия месяца, т.к. в остальном база работает быстро претензий нет.
Система стоит на SATA , база SQL на SSD и tempdb на SSD отдельно.
На реальном, терминал и SQL, больше ничего, сервер новый, база только перенесена, база в файле 1.7 Гб.
На старом вылетала с ошибкой по памяти, но там и сервер отстой был.
В файловой закрывается быстро.
Можно попробовать запустить тестирование и исправление.
Если не поможет - выгрузить в файловый вариант и попробовать утилиту chdbl.exe из каталога с платформой, потом загрузить обратно.
(11) Это было бы просто. Вылетала, реально памяти не хватало на сервере, и опять же на старом сервере в файле закрывалась. База уже другая свернутая с переносом документов в чистую базу, дело не в ней.
(20)База уже другая свернутая с переносом документов в чистую базу, а это остатки и документы текущие.
О каких ошибках речь? и потом напомню в файловом режиме все прекрасно, проблемма при закрытии в серверном варианте. И более, база типовая.
думаю смысл понятен :)
-----------------------
Как то в очередной раз разбираясь с расчетом себестоимости я заметил такую вещь, что в файловой базе полный расчет выполнялся за 30 секунд, а в серверной порядка 10 минут.
------------------------
(13)
Здесь следует сделать одно замечание: данный способ хорошо работает только в том случае, если в результирующей временной таблице по способам распределения большое число записей.
(13) Если бы база была большой, а тут легковес и в стандартной поставке такая засада. Ну не должно так быть, я понимаю тормоз SQL на маленькой базе по отношению к 64 файловой, но тут просто Камазовский тормоз.
(15)
я с MSSQL ничем не помогу
-------------------------------------
есть минимальные начальные настройки
надеюсь они сделаны
и общие рекомендации
также сделаны :) ?
------------------------------
для SQL
(15)запускаете расчет с/с на обоих базах(файловой и к-с) с замером производительности и сравниваете на что тратится значительное бОльше времени в случае к-с.
При изменениях в данных (процедура проведение документа в рассчитываемом периоде) требует полного повторного запуска расчетов, может длиться несколько часов. При запуске с параллельной работой пользователей (когда, к примеру, пользователи работают в текущем месяце, а вы запустили расчеты по предыдущему) он значительно «съедает» ресурсы, тормозит систему.
------------------------------
но вы говорили, что и при одном пользователе долго
всех отключили что-ли ?
------------------------
поставьте запрет на проведение задним числом
и попробуйте...больше вариантов пока нет
Да один на сервере, закрытие именно одного месяца, остальные закрыты. Я вот не пойму база меньше 2 Гб, откуда можно набрать более 40 Гб в памяти при расчете, это как зациклить надо? или архитиктуру так использовать бездарно. Причем эта проблемма идет с 2010 (что я нашел в форумах) и до сих пор методики настройки SQL и 1c по этой проблемме нет, непонятно.
(30) есть другой сервер (для эксперимента)?
Дальше - попробуйте включить технологический журнал и "раскурить" причины зависаний.
Еще вариант - если база небольшая и типовая (или почти типовая) - можно попробовать показать в 1с (отправить dt на ftp техподдержки, предоставляют место по запросу)
(30)Включайте замер производительности в файловой и к-с БД и сравнивайте, на что тратится значительно бОльшее количество времени в случае к-с.
Результат сравнения даст вам направление движения.
Сделал тест с КА 2.4.6 все пролетело за 15 мин., а база тяжелее в 7 раз. Так что сам SQL работает как надо.
Осталось понять, что не так с УТ 11.4.12.77, или дождаться метода решения от 1с. Тестирование и исправление делалось, дело в другом.