1С 7.7 ТИС на SQL - взлетит? База большая, еще 6 перифериек,юзеров>40 терм режим
Продолжение

Тема была серьезной, заявки были большие
Есть небольшие достижения и большие вопросы :)

Начнем пожалуй:
1. Что касается 8-ки:
Перевел все бухгалтерии на 8-ку (включая две Бит-строительство 3.0)
- свернул базы бух 7.7., вылизал всякими обработками всякие надочеты, удалил все помеченное и
в бух 7.7 спокойно перенес остатки на 01.01.2020 в БП 3.0 (включая две базы Бит-строительство).
Что касается баз Бух 7.7 Проф то из ТИС 7.7 перегнал сформированные инвентаризации по всем складам по соответствующей фирме
в БП 3.0. В результате все более менее сошлось в ОСВ
- Для БП 3.0 на УСН все остатки перенес из УСН 7.7 вообще штатно

- Для выгрузки оборотов из ТИС 7.7 в БП 3.0 приобрел немного недоработанную обработку выгрузки-загрузки
В две базы БП загрузил текущие обороты с начала года (по одной базе мы вообще остаемся на БП 3.0 - и бух и оперативный учет),
В две самые "тяжелые" БП 3.0 пока что обороты загружал только пробно (одна из них будет на БИТ-строительство и "отрежется" от ТИС 7.7).

За 1-ый квартал конечно будем делать отчетность (особенно по НДС) и через выгрузку из ТИС в Бух 7.7
и через выгрузку в БП - то есть попробуем отчетность по НДС и там и там.

Поскольку вели год ЗУП по 4 фирмам, то оказалось достаточно несложно сделать синхронизацию ЗУП БП и
настроить первоначально выгрузку документов "Отражение бух. учета в ЗП", выгрузили из ЗУП все расчтные ведомости -
пока всем довольны в этом плане

Вот что касается бухгалтерии и зарплаты

2. Поскольку сервер мой терминальный в ЦБ достаточно мощный (2013 год куплен),
то решено SQL делать на нем (и под 7.7 и под в дальнейшем 8.3), усилим память, добавим ССД
Я кстати так и ожидал (хотя счета на новый скуль-сервер я давал руковдоству) :)

Воспользовались купленным серверочком специальгно для тестовых всяких дел.
Приобрели ССД, приобрел раньше "секретный релиз" 1С.
Установили на сервер win 2008 server, SQL 2008, все настроили согласно всяким умным сайтам,особенно
по tavalik.ru. Короче создали базу 1С под SQL
Загрузил свою рабочую базу в нее, побились немного с дублями ключей и запустили 1С 7.7 под SQL 2008

Пока застрял с тем что при групповом проведении документов идет сильное замедление и память все занимает аж 98%
Хотя памяти 16 ГБ установлено на серверочке.

Надеюсь на Вашу помощь в этом вопросе. Много почитал но пока не понял что же надо делать чтобы такого не было
и групповое проведение в ТИС 7.7 работало быстро ну и память на 98% не грузилась.
Пока это все пробно, лицензии мы в-основном покупаем, так что и скуль купим но просто пока что
пробы локальные делаю.

Что еще: все конечно замечательно с SQL потому что свертывать базу не надо, но на самом деле
есть еще периферийки и если я не настрою обмен так чтобы все лишнее в базы магазинов не сваливалось,
то толку мне от скуля немного или надо скуль делать на всех магазинов что мне кажется не нужно.
Но чем хорош скуль для обменов так тем что позволяет в немонопольном режиме отработать 1supdts преед обменов
и убрать из него сразу то лишнее что не касается обмениваемой в данный момент периферийки.

(0) у вас на сервере и 1С и СКЛ одновременно? И всего 16г рамы?

(1) Пока что один пользователь, а так да и 1С и скуль
Но это тестовый серверочек, рабочий - это настоящий сервер хотя образца 2013 года,
но с куда более мощными кондициями.
Просто столкнулся с тормозами при групповом перепроведении (хочу сразу
основные "тяжелые" обработки и отчеты ну и регламент отсмотреть

Что помню из перехода на 2008 скуль:
Для начала проверь отсутствие пустых дат в конструкциях типа ВыбратьДокументы().
Даты там должны быть проставлены обязательно, везде где можно.

(3) прцентов на 99 увеоен что даты стоят. Куда дальше копать?

(0) Я тут надыбал ветку по теме но не все понятно
ТиС 7.7 Server 2008 R2 и SQL 2008R2

у меня 500гб крутится

(4) и даты актуальности по РН тоже установлены? И да, 16Г рамы на сервере где и 1С и Сиквел - мало!!!! Вот 48 было-бы ну уже туды-сюда (тогда можно было-бы сказать сиквелу вот тебе 32 и хватит!)

Проверял отладчиком Процедуру "обработка проведения" Отчет ККМ.
время в DBF - глсписаниепартий 1.7
время в sql - глсписаниепартий 13.0

Разве такая разница может быть? Что-то не так настроено в sql а что?

(8) Копай глубже, до строчки кода. Тогда видно будет что не так.

Был в Комплексной 7.7 прикол - если в расходной накладной одни услуги, то при проведении оно нереально тормозило. Не было фильтра по товарам и временный расчет итогов велся по всему регистру.

(9,10) Спасибо!
Нет там услуг. И разница в 10 раз а то и больше - мне кажется это
сначала надо оптимизировать работу SQL а потом втыкаться в оптимизацию и фильтрацию запросов и выгрузок итогов в 1С

(11) SQL по определению не будет быстрее файловой (в терминале). Тем более "Отчет ККМ" не маленький документ скорее всего.
Что бы оптимизировать SQL, надо понять на чем идет затык в коде.

(8) В отладчике запускай замер и смотри.

(11) "Сначала надо оптимизировать работу SQL а потом втыкаться в оптимизацию и фильтрацию запросов и выгрузок итогов в 1С"

На ИТС есть статья
https://its.1c.ru/db/metod8dev/content/5904/hdoc

надо настроить память и процы
1. если это только скульный сервер то отдаем ему памяти по максимуму и оставляем чутка под систему (например 12 скулю 4 системе)
2. maxdop надо настроить, начать с 2 потом если по процу есть запас можно увеличить до 4

(8) Чистый SQL будет медленнее, чем DBF. Хочешь быстрее - переписывай запросы на "прямые".

(8) в отладчике есть галка "для вызовов пароцедур и ф-ций ...."
сними ее и увидишь кто реально тормозит

Все пробуем. еще сценарий пробуем переиндексации сжатия и пр

- выставили память в 10 ГБ
- выставили простой режим восстановления
- выставили 15 ГБ начальный размер базы+100 МБ (не в процентах)
Буду еще раз пробовать перепроведение за три месяца

(19)+ Отчет ККМ ГлСписаниеПартйиТМЦ медленно, буду копать что там тормозит

тормозит там обычно 1. расчет временных итогов 2. усугубляемый незакрытыми регистрами (большой объем выборки, вместо пары записей - несколько сотен-тысяч) имхо

если не используеь в ТИС книгу покупок/продаж - заблокируй формирование записей по ним. это не особо поможет, но всё же...

(21) Так там нет расчета временных иотгов - я точку актуальности сдвинул назад до начала проведения.
При этом
- итоги пересчитываются намного быстрее чем на DBF что интересно
- незакрытых регистров в смысле партий тмц у меня как-то и нет

ну тогда отладку включи с замером и смотри...

(24)для всех документов глсписаниепартий и выгрузитьитоги под sql тормозит пока что.
замер включал но даже и без замера это видно. Где товаровдижения нет - там мухой все перепроводится: РКО ПКО и т.д.

(25)+ Перемещение реализация отчетккм - вот они могут тормозить когда там много строк
Но временные иотги там ведь не расчитываются

(26)+ Вторая по медлительности выгрузитьитоги регистра. примерно в 2008 году я оптимизировал свои запросы под SQL работая тогда в другой организации и запросы эти касались путевых листов и остатков по видам топлива и т.д.
Удалось ускорить во много раз большой запрос за счет того что типа выбирал сначада всех например контрагентов а затем выгрузив результаты в ТЗ очищал ее по условия от лишних строк.

Вариант с фильтром ТекстЗАпроса=ТекстЗапроса+"Условие(....);"; работал под SQL медленно

(27)+ Может попробовать Запрос.ВключитьSQL(1)

ТаблНоменклатуры.ВыбратьСтроки();
    Пока ТаблНоменклатуры.ПолучитьСтроку()=1 Цикл
        СуммаМОЛБезНДС=0;              
        Номенклатура=ТаблНоменклатуры.Номенклатура;
        Если (Номенклатура.ВидНоменклатуры = Перечисление.ВидыНоменклатуры.Услуга)
         или (Номенклатура.ВидНоменклатуры = Перечисление.ВидыНоменклатуры.Работа) Тогда
            Продолжить;
        КонецЕсли;
        
            
        ВремПартии.ВыгрузитьИтоги(ТаблИтогов,1,1);  
                
        Думаю что такой цикл с выгрузкой по каждому товару неоптимален а для SQL вообще сильно тормозной

(29)+ Один раз выгружаю все по списку номенклатуры из документа, а потмо просто обрабатывая таблицу номенклатуры беру один раз посчитанное.
Вот только почему в DBF режиме все проходит вполне шустро

ну открой в отладчике визуально таблИтогов, посмотри - объем соответствует ожидаемому?
.
у меня на серваке документы под 300-500 строк проводились до 3 сек... партионка - по среднему.

(31) Да смотрел я в отладчике производительность.
Партионка по ФИФО у нас что создает тормоза дополнительные

(32) еще раз - "ну открой в отладчике визуально таблИтогов, посмотри - объем соответствует ожидаемому?"

может у тебя там копейки где-то без количества подвисли и тянется тоннами...

(34) Ну сам подумай - 300 строк, по каждой строке делается выгрузитьитоги. Насколько я помню 1С под скуль этого не любит.
Ей надо один раз выгрузить - проверяю сейчас. Еще заодно ЦенаПродиз регистра убираю и из всех модулей - она никак не импользовался ни разу

(35) вот ты упертый... еще раз - "ну открой в отладчике визуально таблИтогов, посмотри - объем соответствует ожидаемому?"

(36) Что значит объем? Объем чего смотреть?

в отладчике тормозни после строки
ВремПартии.ВыгрузитьИтоги(ТаблИтогов,1,1);  
.
в табло
ТаблИтогов.ВыбратьСтроку(,) энтер
перключиться в базу - осмотреть содержимое ТЗ внимательно

сделать такое для одного=двух десятков строк...

(38) Ну да, понял. Только там база ТЗ будет мизерная потому что он это деллает по каждой строке номенклатуры

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

ты не трынди. а сделай так как я написал. а не так как ты в (41) хочешь сделать.

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

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

(41) "Пишет причем в какой-нибудь доп. справочник" - нафейхоа это? это всеголишь совет как попытаться выловить что-то лишнее, чего не должно быть. увидеть это быстро при поиске/постановке диагноза можно только глазаками.

(45) Да согласен я полностью. Попробую сейчас поглядеть

(45) Забыл чтоб отладчик не терял курсор - что надо делать? А то сейчас  вообще стало неудобно им пользоваться

процесс dwm в диспетчере задач убить.
только надо уибивать ДВА РАЗА

(48) Спасибо. Точно я ж так уже делал. Подзабыл