Каждую ночь происходит выгрузка базы в dt.
После выгрузки идет загрузка.
После перехода на 18 релиз платформы (сейчас 8.2.18.82) выгрузка стала занимать в 2-3 раза больше времени.
Кто ни будь подобное изменение заметил, или это только у меня?
Объем базы значительных изменений не претерпел.
Размер итогового dt остался примерно такой-же.

База серверная, но для чистоты эксперимента проверяли и на файловом варианте.

В общем вопрос - это нормально или ошибка. Собираемся писать в 1С, но хотелось бы больше информации.

(0)Не замечено.

>>Каждую ночь происходит выгрузка базы в dt.
>>После выгрузки идет загрузка.
>>
>>База серверная
я помолчу лучше)

(0) для начала надо исключить какие-то иные резкие телодвижения, помимо смены релиза.

(2) Делается перенос с одной СУБД на другую.
аппаратная часть - на сервере приложений и сервере субд не загружена...

а вообще, выгрузка в дт каждую ночь - нонсенс

(3) Вот единственное что было. Увеличили на сервере субд ОЗУ с 16Гб до 100Гб.

(4) СУБД разные? тогда да. если Оба SQL например - то такой метод переноса крайне сомнителен

а в какую СУБД загрузка - это не напрягает?

(6) тестировали память хоть? ну и 100Гб конечно респект)

(0) Жесть

И естественно сделали реструктуризацию базы, как рекомендовала 1С.

(5) Схема следующая.
Есть сервер базы данных. На нем два экземпляра SQL server.
На первом экземпляре крутится рабочая база. На втором технологическая.


Одна рабочая, вторая технологическая.
Средствами SQL server делается резервная копия рабочей базы данных. Эта резервная копия разворачивается в технологическую базу.
Из нее делается выгрузка в dt.

Далее этот dt файл загружается на другой сервер на котором стоит Postgre.

Вот на выгрузке тормозит.

Дополнительное изменение которое было кроме смены платформы.
Рабочая база и технологическая были на одном экземпляре MS SQL server. И всего ему было доступно 16Гб оперативки.
После на сервер баз данных установили 128 Гб оперативки. Сделали два экземпляра SQL server. На основном экземпляре рабочая база и этому экземпляру выделено 100 Гб оперативки. Второму экземпляру выделено 26 Гб оперативки.
фу...

(11) Ага... сделали :)
Не надо было?

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

(12) что затем на серваке с Postgre в базе происходит?

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

(9) Тестировали. С памятью все ОК.
Железо вообще проверили перед расширением ОЗУ.
Как то так случилось, что админы проспали и в новый год у нас одна планка памяти выпала. Долго искал почему базы стали тормозить.
(14) Не логичней. :(
Пробовали. База сильно растет. И не все в полный план обмена входит. Конфигурация УПО (УПП+проектный офис).
(15) Эта база становится тестовой на следующий день для пользователей. Также служит быстрым источником для переноса в базы для разработки.
Т.е. вся разработка ведется на Posrgre.
Тестовые для системных аналитиков на втором экземпляре SQL server.

(12) для свопа отдельный винт выделили?

(18) Да.

(19) А может включить все в полный план обмена, ну кроме сервисных объектов, которые сам обмена регулируют?

пока вспоминается, что в 18 доп. индексы ввели в журналах

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

(17) пухнет из-за неочищаемых таблиц с регистрацией - их же надо чистить загрузкой ответок о получателя. Или свою процедурку из одной команды нарисовать.

Так переписывайте состав объектов в полном плане обмена - само оно не запишется, но модуль полного обмена практический пустой. Там все что включено, то и передается.

(17) тестирование и разработка на СУБД, которая не является рабочей? всмысле в пром эксплуатации SQL? странно... у них свои особенности, и например с той же оптимизацией - на Постри может летать, а на SQL сдохнуть, или наоборот.

(22) угу... легких путей не ищИте

хотя это для ms

(26) так они и выгружают из МС

(22) Могу ошибаться, но сложновата у вас схема. У нас есть база в отдельном дата-центре на случаи катаклизмов, каждую ночь обмен по полному обмену - 2 года полет номрмальный. При обновлении проверяем состав обмена.

заменить Postgre на ms sql не предлагать?

(29) кстати да, как-то странновато - боевая на MS SQL, а разрабатываете под Постгре

(22) а что вам проку от стандартного объекта, если он все равно не выполняет свою задачу - если конфиг УПО (УПП+проектный офис) и полный план обмена этого не видит, то он не пригоден к использованию.

(29) у них наверняка он не только на постгри, но и база в линукс, сервак тоже в линукс. только боевое под виндой. На разрабах экономят

(24) Про производительность знаем. Нагрузочное тестирование если и делаем то только на копии MS SQL.
(29)Рад бы... да грехи, тьфу... финансисты денег не выделяют. :(
(32)Угадал.

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

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

(34) проверь, что там с допиндексами о которых речь в (21).

(33) это у Вас наверное сервер 1с на linux'e  еще и без глюча

(36) Нет. Сервер 1С на Windows. С ключем.
С лицензионной чистотой у нас строго. И лицензий клиентских куплено в полтора раза больше чем реально работает людей.

(37) тогда непонятно нафига постгри... ну это к вопросу не относится впринципе, зоопарк дак зоопарк)

вот нашел в описании 18 :
В таблицу журнала документов добавлен индекс по полю Ссылка. В результате повышается скорость работы динамического списка журнала документов, а также поиск по ссылке в журнале документов.

Копать видимо в PG надо, скорее всего дисковая подсистема, может хранилище PG в RAM закатать при 100 гб?

(38) 1С сервер с ключом один

(40) Ага. :(
Второй пока не получилось обосновать.