Имя: Пароль:
1C
1С v8
Выгрузка в dt. 18 релиз. Долго.
0 Lama12
 
17.05.13
14:38
Каждую ночь происходит выгрузка базы в dt.
После выгрузки идет загрузка.
После перехода на 18 релиз платформы (сейчас 8.2.18.82) выгрузка стала занимать в 2-3 раза больше времени.
Кто ни будь подобное изменение заметил, или это только у меня?
Объем базы значительных изменений не претерпел.
Размер итогового dt остался примерно такой-же.

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

В общем вопрос - это нормально или ошибка. Собираемся писать в 1С, но хотелось бы больше информации.
1 НаборДанных
 
17.05.13
14:40
(0)Не замечено.
2 Maxus43
 
17.05.13
14:41
>>Каждую ночь происходит выгрузка базы в dt.
>>После выгрузки идет загрузка.
>>
>>База серверная
я помолчу лучше)
3 Фрэнки
 
17.05.13
14:42
(0) для начала надо исключить какие-то иные резкие телодвижения, помимо смены релиза.
4 Lama12
 
17.05.13
14:42
(2) Делается перенос с одной СУБД на другую.
аппаратная часть - на сервере приложений и сервере субд не загружена...
5 Фрэнки
 
17.05.13
14:42
а вообще, выгрузка в дт каждую ночь - нонсенс
6 Lama12
 
17.05.13
14:43
(3) Вот единственное что было. Увеличили на сервере субд ОЗУ с 16Гб до 100Гб.
7 Maxus43
 
17.05.13
14:43
(4) СУБД разные? тогда да. если Оба SQL например - то такой метод переноса крайне сомнителен
8 Фрэнки
 
17.05.13
14:44
а в какую СУБД загрузка - это не напрягает?
9 Maxus43
 
17.05.13
14:44
(6) тестировали память хоть? ну и 100Гб конечно респект)
10 shamannk
 
17.05.13
14:45
(0) Жесть
11 H A D G E H O G s
 
17.05.13
14:47
И естественно сделали реструктуризацию базы, как рекомендовала 1С.
12 Lama12
 
17.05.13
14:51
(5) Схема следующая.
Есть сервер базы данных. На нем два экземпляра SQL server.
На первом экземпляре крутится рабочая база. На втором технологическая.


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

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

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

Дополнительное изменение которое было кроме смены платформы.
Рабочая база и технологическая были на одном экземпляре MS SQL server. И всего ему было доступно 16Гб оперативки.
После на сервер баз данных установили 128 Гб оперативки. Сделали два экземпляра SQL server. На основном экземпляре рабочая база и этому экземпляру выделено 100 Гб оперативки. Второму экземпляру выделено 26 Гб оперативки.
фу...
13 Lama12
 
17.05.13
14:51
(11) Ага... сделали :)
Не надо было?
14 Фрэнки
 
17.05.13
14:53
А может быть куда логичней настроить вместо выгрузки в дт выгрузку по полному плану обмена?
15 Фрэнки
 
17.05.13
14:54
(12) что затем на серваке с Postgre в базе происходит?
16 Фрэнки
 
17.05.13
14:56
с ней же мало того, что выгружается долго, но и загрузка из дт идет ну очень долго. На порядки быстрей полные обмены выгрузки делать.
17 Lama12
 
17.05.13
14:56
(9) Тестировали. С памятью все ОК.
Железо вообще проверили перед расширением ОЗУ.
Как то так случилось, что админы проспали и в новый год у нас одна планка памяти выпала. Долго искал почему базы стали тормозить.
(14) Не логичней. :(
Пробовали. База сильно растет. И не все в полный план обмена входит. Конфигурация УПО (УПП+проектный офис).
(15) Эта база становится тестовой на следующий день для пользователей. Также служит быстрым источником для переноса в базы для разработки.
Т.е. вся разработка ведется на Posrgre.
Тестовые для системных аналитиков на втором экземпляре SQL server.
18 1Сергей
 
17.05.13
14:58
(12) для свопа отдельный винт выделили?
19 Lama12
 
17.05.13
14:59
(18) Да.
20 Восточный Парень
 
17.05.13
15:00
(19) А может включить все в полный план обмена, ну кроме сервисных объектов, которые сам обмена регулируют?
21 stix2010
 
17.05.13
15:01
пока вспоминается, что в 18 доп. индексы ввели в журналах
22 Lama12
 
17.05.13
15:02
(20) Не хочется.
Стараемся только в критических случаях (т.е. если совсем по другому нельзя), менять стандартные объекты конфигурации.
Можно конечно свой план обмена вкорячить и в него все включить, но как-то пока этот вариант не рассматриваем.
23 Фрэнки
 
17.05.13
15:02
(17) пухнет из-за неочищаемых таблиц с регистрацией - их же надо чистить загрузкой ответок о получателя. Или свою процедурку из одной команды нарисовать.

Так переписывайте состав объектов в полном плане обмена - само оно не запишется, но модуль полного обмена практический пустой. Там все что включено, то и передается.
24 Maxus43
 
17.05.13
15:03
(17) тестирование и разработка на СУБД, которая не является рабочей? всмысле в пром эксплуатации SQL? странно... у них свои особенности, и например с той же оптимизацией - на Постри может летать, а на SQL сдохнуть, или наоборот.
25 Фрэнки
 
17.05.13
15:03
(22) угу... легких путей не ищИте
26 stix2010
 
17.05.13
15:03
хотя это для ms
27 Фрэнки
 
17.05.13
15:04
(26) так они и выгружают из МС
28 Восточный Парень
 
17.05.13
15:04
(22) Могу ошибаться, но сложновата у вас схема. У нас есть база в отдельном дата-центре на случаи катаклизмов, каждую ночь обмен по полному обмену - 2 года полет номрмальный. При обновлении проверяем состав обмена.
29 krbIso
 
17.05.13
15:04
заменить Postgre на ms sql не предлагать?
30 Восточный Парень
 
17.05.13
15:06
(29) кстати да, как-то странновато - боевая на MS SQL, а разрабатываете под Постгре
31 Фрэнки
 
17.05.13
15:06
(22) а что вам проку от стандартного объекта, если он все равно не выполняет свою задачу - если конфиг УПО (УПП+проектный офис) и полный план обмена этого не видит, то он не пригоден к использованию.
32 Фрэнки
 
17.05.13
15:08
(29) у них наверняка он не только на постгри, но и база в линукс, сервак тоже в линукс. только боевое под виндой. На разрабах экономят
33 Lama12
 
17.05.13
15:11
(24) Про производительность знаем. Нагрузочное тестирование если и делаем то только на копии MS SQL.
(29)Рад бы... да грехи, тьфу... финансисты денег не выделяют. :(
(32)Угадал.
34 Lama12
 
17.05.13
15:14
(31) Периферийные базы с функционалом проектного оффиса не работают. Да, у них имеются в некоторых объектах битые ссылки, но только в периферийных базах. Что б эти ссылки не удалялись, идет административная работа, да и правами запрещено :).

Вопрос создания полного плана обмена поднимал. Сказали пока не столь важная задача. Вот и приходится выкручиваться.
35 Фрэнки
 
17.05.13
15:16
(34) проверь, что там с допиндексами о которых речь в (21).
36 stix2010
 
17.05.13
15:18
(33) это у Вас наверное сервер 1с на linux'e  еще и без глюча
37 Lama12
 
17.05.13
15:20
(36) Нет. Сервер 1С на Windows. С ключем.
С лицензионной чистотой у нас строго. И лицензий клиентских куплено в полтора раза больше чем реально работает людей.
38 Maxus43
 
17.05.13
15:23
(37) тогда непонятно нафига постгри... ну это к вопросу не относится впринципе, зоопарк дак зоопарк)
39 stix2010
 
17.05.13
15:23
вот нашел в описании 18 :
В таблицу журнала документов добавлен индекс по полю Ссылка. В результате повышается скорость работы динамического списка журнала документов, а также поиск по ссылке в журнале документов.

Копать видимо в PG надо, скорее всего дисковая подсистема, может хранилище PG в RAM закатать при 100 гб?
40 Фрэнки
 
17.05.13
15:32
(38) 1С сервер с ключом один
41 Lama12
 
17.05.13
15:41
(40) Ага. :(
Второй пока не получилось обосновать.