Доброго дня. Анамнез - база Ут 10.3 с дописками и доками с 2010 года работает под sql 2019, mdf файл за годы распух до 600 Гб. Приняли решение (без меня) выгрузить базу в дт и загрузить назад чтобы таким путем ее чуть уменьшить. Сказано-сделано. Размер базы уменьшился почти вдвое. Далее был выполнен план обслуживания в sql - пересоздание индексов, статистика. После запуска сверили итоги по складским остаткам, взаиморасчетам и прочему все норм. Документ РТУ проводится 200 секунд. Это если в базе кто-то один, если несколько естественно валятся блокировки пока у кого висит документ. Замер производительности в 1с показывает основное торможение на СтрокаДвижения.НаборЗаписей.Записать(); .
Сервер в этот момент не загружен, кроме очереди диска которая поднимается до 35. Диск SSD Intel севрерный судя по его утилите чувствует себя прекрасно. Был проведен эксперимент тот файл дт что был выгружен был загружен на другом абсолютно новом сервере - там диск нвме 990 самсунг очередь до 20 и проведение 50 секунд.
Что я пробовал - тестирование через Конфигуратор, chdsk в sql ничего не нашел, бекап средствами sql.

Продолжай информировать нас

анамнез ни о чем

Информирую), хотелось бы конечно каких-то идей что еще сделать)

Какие нужны подробности? Это было кратко)

запускай техжурнал, потом думай

Проверим. Временно отключите партионный учёт на копии. Как теперь проводится реализация?

(6) Я так понимаю отключить в базе Списывать партии при проведении документов?

(7) Вам виднее, у меня УТ нет. Но опция по названию похожа на ту, что нам нужна.
Нам надо провести док без двиганья партий.

(6) Эксперименты провожу на другом сервере, более мощном. На нем при стоящей галочке документ из двух позиций проводится 20 сек. при отключенной 10.

(6) Чтобы не выглядело как в пределах нормы. Копия этой же базы от ноября 23 года развернута - в ней рту проводятся около 2 сек без влияния галочки. Только что проверил

(9) Нужна рабочая база или её копия. Там, где 3 минуты. В смысле проведения, а не то, что кто-то мог подумать...

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

(10) Хорошо. Значит дело не в железе, а в партиях.
Хайли лайкли есть минусовые остатки. По памяти там есть функционал квадратичных отклонений, который при нахождении отрицательного числа идёт вразнос и даже постепенно выходит на ошибку переполнения секстиллионных чисел, не говоря уж про тормоза.

"Операции" - "Управление итогами" по какую дату рассчитаны итоги?

К сожалению тот сервак где было 3 минуты разобрали для ТО. Это скриншот замера производительности при включенных партиях. Итоги на 1 января

https://ru.paste.pics/QAFT9

(12) т.е. или один регистр поплыл или все. могли еще со статистикой начудить

Глупый вопрос задам - после переноса на этот сервер план обслуживания в sql не запускал, стоит? будет ли влияние?

(17) Запусти - узнаешь

Запустил, как закончится, запущу еще раз из Конфигуратора все тестирования

(17) Разумеется, статистику стоит обновлять как можно чаще.

Просвятите - базы размером в 600 Гб сейчас нормально выгружаются в .DT и загружаются обратно ?

(21) бывает норм, бывает пишет что загружены не все данные, потом проверяешь вроде норм)

(21) Зависит от кучи всего
Например у меня на домашнем компе сначала загружались/выгружались подобного размера нормально
Затем непонятно почему начали глючить - пришлось переустановить винду и прочее - снова стало нормально

(23)+ У меня как понял были проблемы с

(17) Ну я бы не стал особо надеяться на план обслуживания. Тут скорее план запроса надо курить

(25) план ничего и не дал(. Вопрос в том что конфа ноябрьская и текущая не отличаются, там код быстро отрабатывает а тут нет. Сейчас запустил тестирование из конфигуратора, вдруг поможет

ну у тебя история транзакций не висит? восстановил в скуле без хвостов?

Может, тебе сделать Перенос данных в новую базу после поломки старой. Инфы мало.

(27) история транзакций не висит - что имеется ввиду?

(28) и перенос сделать такой базы - задачка не слабая, они еще и работают 24на7

(29) Да я про своё подумал. На всякий случай спросил.

РТУ до сих пор висит? План запроса ничего не показал?

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

есть мутное подозрение на какой ПКО, что в нем поменять чтобы конфа заставила его реорганизоваться?

(0) Что-то не сходится. Как с таким тормозным проведением документов смогли нарастить базу до сотен гигов?
Какие таблицы самые большие в базе?

(35) Там вроде фишка, что после перезагрузки стало тормозить

Вообще-то после перезагрузки летать должно, а тут наоборот. Непонятно. Матан пока непонятен.

Хотя если раньше 2 сек было...
Смотреть отладчиком базу, где быстро и базу, где медленно. И сравнивать.

И на всякий случай проверить минимальные и максимальные периоды движений в регистрах накопления.

Ну по чесноку — проведение РТУ. Отлаживаешь запрос. Берёшь всё запросы в консоль какую. Выполняешь. Если собирать надо запрос, собирай. Консолей много. Замеры делай. Найди узкое место. Выясни.

Пока ничего не понятно

(38) проходил отладчиком насколько ума хватило, в "быстрой" базе СтрокаДвижения.НаборЗаписей.Записать() - 0.9 сек, в медленной - 6 сек.

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

что-то тис на ПКО подозрительно зависло

на проверке логической целостности ПКО зависла

дтшка сколько весит щас?

26

вернее, скуль. 300 гиг?

это без логов, триста гиг? суровая база

почти 500 мдф

полтерыча ещё ничего, а то бывают и терабайты. всё жмутся свёртку сделать

лан, что тебе ТИИ выдаст.

Запустил пересчет итогов и реструктуризацию таблиц, жду. Странно что на ПКО зависло, причем тут ваще пко

Реструктуризация на больших базах вообще можно ночевать на работе. Днями идёт.

Но у тебя хороший диск.

Так бы в сиквеле пробежался по размерам таблиц, а то мало ли.

(56) каким образом? их там тьма

(57) На всякий случай. Ждём ТИИ

ждем, реструктуризация идет, всякие там любимые объекты доступа документов)

самописных индексов в скуле не было?

Насчёт индексов бы я и сам подумал, но вряд ли. Так-то одно неиндексированное соединение может положить запрос

тии зависло на пересчете итогов с ошибкой конфликта блокировки sqk, при этом регламентные задание отключены, откуда конфликт непонятно, проведение рту все также висит(

еще странное - при нажатии провести через 2 секунды звездочка * (признак модифицированности) вверху рту исчезает все вроде как должно случиться, но тут начинают крутиться часики секунд 7-8 и опять появляется звездочка и через 2 секунды пропадает. документ проведен. Как будто два раза проводится

(14) вот самый важный вопрос !
очень вероятно, что дело в этом

(64) итоги на 1 января, а вот проведение по партиям висит еще на 11 году. Однако в копии также, то есть никто не занимался проведением по партиям так как стоит галочка списывать партии при проведении

(40) запросы тут не причем. У него тормозит запись в какой-то регистр

Замеры производительности я так понимаю еще не делали что бы определить что тормозит?

(67) если речь о замере из конфигуратора то делал, выше есть скриншот, могу дать подробности

(15) и где здесь 3 минуты?

Сервак, где было 3 минуты, уже разобрали.
Теперь 10 сек.
Не морочьте людям голову.

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

(71) Разбирайтесь, чо...

вот текущая ситуация в момент работы, замер производительности

https://ru.paste.pics/QAL6G

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

как вариант можно попробовать поменять платформу.
Я лично столкнулся, как после смены платформы с 15 на 17 у меня упала производительность в 100 раз при записи регистра сведений (тестировал на нескольких серверах). Установил 16 и все нормализовалось.

(73) Наверное, 9 раз записываете один и тот же набор

Процедура УдалитьДвиженияРегистратора(ДокументОбъект, Отказ) Экспорт
    
    МассивОбрабатываемыхСтрокТаблицыДвижений = Новый Массив();
    
    // получение списка регистров, по которым существуют движения
    ТаблицаДвижений = ПолныеПрава.ОпределитьНаличиеДвиженийПоРегистратору(ДокументОбъект.Ссылка);
    ТаблицаДвижений.Колонки.Добавить("НаборЗаписей");
    ТаблицаДвижений.Колонки.Добавить("БезусловноеУдаление", Новый ОписаниеТипов("Булево"));
        
    Для Каждого СтрокаДвижения ИЗ ТаблицаДвижений Цикл
        // имя регистра передается как значение, полученное с помощью
        // функции ПолноеИмя() метаданных регистра
        ПозицияТочки = Найти(СтрокаДвижения.Имя, ".");
        ТипРегистра = Лев(СтрокаДвижения.Имя, ПозицияТочки - 1);
        ИмяРегистра = СокрП(Сред(СтрокаДвижения.Имя, ПозицияТочки + 1));

        МассивОбрабатываемыхСтрокТаблицыДвижений.Добавить(СтрокаДвижения);
        
        ЕСли ТипРегистра = "РегистрНакопления" Тогда
            Набор = РегистрыНакопления[ИмяРегистра].СоздатьНаборЗаписей();
                
        ИначеЕсли ТипРегистра = "РегистрСведений" Тогда
            Набор = РегистрыСведений[ИмяРегистра].СоздатьНаборЗаписей();              
                
        КонецЕсли;

        Если НЕ ПравоДоступа("Изменение", Набор.Метаданные()) Тогда
            // отсутствуют права на всю таблицу регистра
            СообщитьОбОшибке("Нарушение прав доступа", Отказ, СтрокаДвижения.Имя);
            Возврат;
        КонецЕсли;

        Набор.Отбор.Регистратор.Установить(ДокументОбъект.Ссылка);            

        // набор не записывается сразу, чтобы не откатывать транзакцию, если впоследствии
        // выяснится, что на один из регистров не хватает прав.        
        СтрокаДвижения.НаборЗаписей = Набор;        
        
    КонецЦикла;    
    
    Для Каждого СтрокаДвижения ИЗ МассивОбрабатываемыхСтрокТаблицыДвижений Цикл        
        Если СтрокаДвижения.БезусловноеУдаление Тогда
            ПолныеПрава.ЗаписатьНаборЗаписейНаСервере(СтрокаДвижения.НаборЗаписей, ДокументОбъект.Ссылка);
        Иначе        
            Попытка
                СтрокаДвижения.НаборЗаписей.Записать();
            Исключение
                // возможно «сработал» RLS или механизм даты запрета изменения
                СообщитьОбОшибке(ОписаниеОшибки(), Отказ, СтрокаДвижения.Имя);
                ВызватьИсключение "Операция не выполнена";
            КонецПопытки;
        КонецЕсли;    
    КонецЦикла;
    
    ОчисткаКоллекцииДвиженийДокумента(ДокументОбъект);
    
    // Удаление записей регистрации из всех последовательностей
    УдалитьРегистрациюДокументаВПоследовательностях(ДокументОбъект, Истина);

КонецПроцедуры

(77) это типовой код удаления движений при отмене проведения. Лучше позовите программиста.

(78) согласен, в доступности нет его, ищу удаленно. Мне непонятно зачем при проведении вызывается процедура отмены проведения

(79) НО. Раз код 1С не менялся, и, можно ОБЪЕКТИВНЫМИ замерами до и после выгрузки в dt увидеть разницу в быстродействии в разы, то проблема в БД. Итоги, индексы или что-то еще. Может maxdop у вас не 1, но это не на запись влияет

(80) Расслабьтесь уже. Тут ошибки в программном коде. Многократная запись набора на каждую строку документа. Надо всё удалять и писать заново

(81) тогда только один вопрос - конфа с копией через сравнение идентична, в ней проведение 2-3 секунды.

(80) я и склоняюсь к тому что что-то с базой. Все мне доступные и понятные действия я сделал, а результата нет. Безусловно вынужденный переезд на другой сервер ускорил процесс, но изначально реально проведение длилось 3 минуты! Но проблема в базе никуда не делась. Не случайно зависает тис я думаю. Только как найти в чем косяк непонятно, вчера ночью оно зависло на ПКО именно.

(82) выкладывай dt шник и кидай ссылку на [email protected]. гляну