Добрый день.
1С 7.7.27 + SQL2008 Enterprise + 1С++. Самописная конфа.
При перепроведении документов за несколько месяцев через "Операции"-"Проведение документов..." (движок и каталог с md локально на SQL) тормоза нарастают с 4-5 часов/месяц до 8-10 часов/месяц. Помогает прерывание проведения и переиндексация таблиц итогов регистров (RG...) средствами SQL. Оперативной памяти достаточно (более 100 гиг под SQL при базе в 48 гиг). Модель восстановления простая, уровень совместимости SQL2000, автообновление статистики отключено. Похоже, что переполняется какой-то буфер в SQL. Подскажите, плиз, как отловить?

Может в сторону ТА?

Если я правильно понимаю, то при переиндексации чистится то, что переполнено. Потому и помогает. Что это может быть?

Переповедение этим способом подразумевает, что все проводится на ТА.

Может подскажете, какие счетчики поставить анализироваться в средствах наблюдения?

(0) Похоже статистика не обновляется.
уровень совместимости надо ставить 110
а то не факт что если движок 2008 а база 80
то вполне возможно что известная ошибка которая под sql2000,
в твоей базе точно также проявляется.

>>>уровень совместимости SQL2000,
вот это исправь, сперва

Статистика обновляется по расписанию. Уровень повышу, но сдается мне - не то. Почему переиндексация помогает?

как дружил с 2008 ?

Секретный релиз http://catalog.mista.ru/public/82018/

ну , тогда (6), для начала и в 2008 нет проблемы , как в 2000 , там не надо делать рекконект найтив

и, надеюсь, все dll -ки родные, от 2008 скуля ? Всякие одбс от старого не переписывал, поверх ?

Родные, конечно. В 2008 нет проблемы реконнекта в любом уровне совместимости базы.

ну ладно, авторасширение, какое установлено ?
тепмпдб, где валяется ?

с 4-5 часов/месяц.. это конечна жесть, у нас база за ночь за год перепроводилась, порядка полмульта доков

мот тупо есть кучка незакрытых регистров ? Туда посмотреть в начале ? Или доки с 1980 года, от которых итоги каждый раз из периода в период едут ?

Или.. проверить сперва пустые даты в _1sjourn/_1soper/_1scentry ..это те, которые 1573 годом

И это, нет ли строковых измерений, с типом строка хрензнает какая длина ? ...

темп на отдельном ссд, авторасширение 200 метров база и 100 метров лог. База с 2002 года. Основная нагрузка на последние годы, само собой. Примерно 6000-7000 доков в день. Проблема в том, что ОДИН И ТОТ ЖЕ ПЕРИОД в одном случае проводится 4 часа, в другом - 8. База только на регистрах. Пустых дат нет.

Так что плевать пока на структуру регистров и т.п. Дело чисто в SQL.

Замер отладчика показывает резкое торможение на запросах к регистрам (виртуальные таблицы 1С++)

Допустим, в одном случае 1000 запросов выполняется за 80 секунд, а в другом этот же период 1000 запросов за 1000 секунд.

При этом сервер и база использовались монопольно. Напомню, что помогала переиндексация RG...

А если обновить статистику, без пересчета итогов, помогает хоть ?

я бы ещё попробовал периодически сбрасывать кэш планов
DBCC FREEPROCCACHE

в монопольном режиме гемор конечно...

(23) Нет, статистика не помогает.
(24) Пробовал, не то, хотя примерно нечто такое я и ищу. Какими бы счетчиками производительности обвешаться?

(16) 1753

установить
max degree of parallelism = 1

(26) Все равно нету )))
(27) Ну не то это. Переполняется какая-то дрянь.

ну самое стандартное:
SELECT TOP 10
[Wait type] = wait_type,
[Wait time (s)] = wait_time_ms / 1000,
[% waiting] = CONVERT(DECIMAL(12,2), wait_time_ms * 100.0
               / SUM(wait_time_ms) OVER())
FROM sys.dm_os_wait_stats
WHERE
    wait_type NOT LIKE '%SLEEP%'
    and wait_type not like '%backup%'

    and wait_type Not IN ('REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
        'XE_DISPATCHER_WAIT',
        'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE',
        'BROKER_TO_FLUSH'
    )
    
ORDER BY wait_time_ms DESC

может с ходу чего-нить показать... а может и нет :)


ещё вот такая полезная штука есть: http://simplesqlserver.com/2013/08/13/sys-dm_os_perfomance_counters-demystified/

Хм. А vk_Hook1C.dll не дружит с уровнем базы 110. Ладно, обойдусь без нее.

и ещё, статейка:  https://blogs.msdn.microsoft.com/blogdoezequiel/2014/04/09/sql-swiss-army-knife-14-troubleshooting-with-waits-and-latches/

там в самом начале ссылочка на скрипт view_Waits.sql

ASYNC_IO_COMPLETION    71419    30.80
LCK_M_S    36595    15.78
LCK_M_U    32060    13.83
ASYNC_NETWORK_IO    31477    13.58
WRITELOG    26175    11.29
PAGEIOLATCH_SH    9094    3.92
LCK_M_X    7416    3.20
PAGEIOLATCH_EX    3269    1.41
LCK_M_IX    2888    1.25
PAGELATCH_EX    2708    1.17

(30) это вообще надо в первую очередь выкинуть.. зачем вы вообще её используете ? не понимаю.

(33) )) Уже выкинул

"Замер отладчика показывает резкое торможение на запросах к регистрам (виртуальные таблицы 1С++)"
Есть возможность получить план запроса для резко заторможенных запросов?
Думаю, все же, не стоит отметать вероятность неудачного выбора плана запроса и зацикливаться на поиске кешей/буферов

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

(36) Помнится, 1С 7.7 всегда славилась тормозами при проведении очень большого пакета документов зв один "чих" :)

(37) ну, если все впихнуть в одну транзакцию...

(37) это замедление было только на sql2000 и при определенных условиях

(39) ну не знаю... длительное восстановление ГП всегда было проще прервать и запустить заново с продолжением. Получалось быстрее. Видимо восстановление ГП всегда попадало под "определенные условия"

Historical_Latches    BUFFER    16886.92    113833183    99.98    99.98    0.0001    [Buffer Pool - PAGELATCH or PAGEIOLATCH]
Historical_Latches    ALLOC_IAM_PAGE_RANGE_CACHE    1.05    6    0.01    0.01    0.1742    Other
Historical_Latches    FGCB_ADD_REMOVE    0.84    29    0.00    0.01    0.0291    [IO Operations]
Historical_Latches    LOG_MANAGER    0.73    8    0.00    0.02    0.0916    [IO - Log]
Historical_Latches    ACCESS_METHODS_HOBT_COUNT    0.32    4792    0.00    0.01    0.0001    [HoBT - Metadata]
Historical_Latches    BUFFER_POOL_GROW    0.08    178    0.00    0.00    0.0004    Other
Historical_Latches    ACCESS_METHODS_HOBT_VIRTUAL_ROOT    0.03    147    0.00    0.00    0.0002    [HoBT - Metadata]
Historical_Latches    QUERY_OPTIMIZER_ID_MANAGER    0.03    1448    0.00    0.00    0.0000    Other

Information    latch_class    wait_time_s    waiting_requests_count    pct    overall_running_pct    avg_wait_s    latch_category

Что-то первая строчка меня беспокоит. Это запрос отсюда:
https://blogs.msdn.microsoft.com/blogdoezequiel/2014/04/09/sql-swiss-army-knife-14-troubleshooting-with-waits-and-latches/

(40) восстановление ГП с применением типовых методов проведения - да, попадало

(44) + но это в данной ветке, пока - оффтопик

Попадало, потому что регистры приходится очищать и пересчитывать, которые еще впереди. Я реистры чищу перед перепроведением. Получается в разы быстрее.

(46) Замедление проведения на 2000 связано с применением множественных фильтров, например при расчете остатков.
Если избавиться от множественных фильтров, то замедления не будет и реконектнейтив не понадобится

не знаю для 2008 актуально это или нет, на 2000 скл была системная проблема с замедлением из-за частого создания временных таблиц.

у меня в оптимизации для ТиС была для этого предусмотрена глобальная временная таблица

Если кому интересно, я перепровожу большие базы на копии, а потом внедряю регистры в оригинал. Разумеется с запретом редактирования документов. Накидал свое и не свое:

https://dropmefiles.com/1wS2y

1. Запрет редактирования документов ранее, скажем, 01.03.16
2. Бэкап.
3. Восставить из бэкапа в копию. (и MD и т.п. тоже)
4. Убить регистры в копии скриптом.
5. Перепровести копию до 01.03.16.
6. Бэкап.
7. Внедрить в оригинал регистры перепроведенной копии скриптом.
8. Перепровести остаток оригинала.
9. Открыть доступ к докам.

Таким образом даже очень тяжелые базы уйдут в монопольный доступ только на время внедрения регистров и проведения хвостика.
СКРИПТЫ ПИСАЛИСЬ ТОЛЬКО ПОД РЕГИСТРЫ. ПРОВОДКИ НЕ ПЕРЕНОСЯТСЯ!!!

Кстати, после всяких бэкапов/ресторов, и прочих регламентов типа перестроения индексов и статистик, надо счетчики сбрасывать, а то фигня будет, а не статистика.

DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR)
DBCC SQLPERF(''sys.dm_os_latch_stats'', CLEAR)

(51) Попробую, спс.

Похоже, что дело было в статистике индексов, которая, в силу проведения кучи документов из одного периода, настраивалась на текущий месяц. И когда начинали проводиться документы следующего месяца, система тормозила. Вылечил созданием служебного документа, который поместил в начало каждого месяца. В модуле документа перестраиваю индексы таблиц итогов регистров с целью сброса статистики и реорганизации (дефрагментации) индексов и сбрасываю кэш:

Процедура ОбработкаПроведения()

    Запрос = СоздатьОбъект("ODBCRecordSet");

    ТекстЗапроса = "
    |SET NOCOUNT ON
    |
    |DECLARE @SQL NVARCHAR(900)
    |DECLARE @TableName char(32)
    |DECLARE SysCur CURSOR FOR SELECT name FROM sysobjects WHERE type='U' and name like 'RG%' order by name
    |OPEN SysCur
    |FETCH NEXT FROM SysCur INTO @TableName
    |WHILE @@FETCH_STATUS=0 BEGIN
    |    SET @SQL = N'ALTER INDEX ALL ON dbo.' + @TableName + N' REBUILD WITH (SORT_IN_TEMPDB = ON, ONLINE = ON)'
    |   EXECUTE sp_executesql @SQL
    |   FETCH NEXT FROM SysCur INTO @TableName
    |END
    |CLOSE SysCur
    |DEALLOCATE SysCur
    |
    |DBCC FREEPROCCACHE
    |";
    
    Попытка
        Запрос.ВыполнитьСкалярный(ТекстЗапроса);
    Исключение
    КонецПопытки;
    
КонецПроцедуры

Такое перестроение возможно, только если SQL Enterprise. Имеется ввиду хинт "ONLINE = ON".
На рабочей базе с кучкой активных пользователей документ провелся за 12 минут. Проведение копии за последние 9 месяцев не тормозило. Стабильные 3-4 часа/месяц.

Выполнение только (51) не помогло.

(53) как то не кошерный код, а если баз много ? И они еще и разные ?

Я под себя писал. Идею донес, а там допиливайте под себя ))
А что не кошерного? Что смущает?

(56) вот это
SELECT name FROM sysobjects WHERE type='U' and name like 'RG%'

Это модуль проведения документа, который находится в началах периодов. Нужен для перепроводки конкретной базы. Так что "баз много" - надо в каждую вставить. На счет разных баз, можно дописать под бухгалтерию, добавив обработку таблицы _1scttlc, кажется.

(57) а как лучше?

(59) как минимум, добавить в запрос условие на конкретную базу.
Если несколько баз на серваке, (и не только от 7.7) он же тебе все их будет колбасить

Не будет. Он же в контексте конкретной базы выполняется.

И у меня, кстати, несколько баз. Копия для программирования, как минимум. ))

(61) ?

(61) а причем тут контекст? ты ж явно лезешь к сисобджектс...

Выполни
select COUNT(*) from sysobjects
в Management Studio для разных баз.

Если это представление содержит сведения обо ВСЕХ базах, то результат будет одинаковый. А если только о текущей базе - то разный. У меня разный результат получился.

(66)ну, может быть, лень смотреть даже :)

:)
В обозревателе объектов:
"Базы данных"-"Моя база"-"Представления"-"Системные представления"-...
Там все эти служебные вьюшки лежат. Для каждой базы свои.

Кстати, Мишаня! Поздравляю с присоединением к лиге трехкратных отцов! ))) Сам уже 3,5 года как такой )))

это ты кому?

Тебе! ))) Тут Мишани только ты да я )))

(71) ну, по крайней мере мне об этом ничего не известно.
Я понимаю, что "ни один мужчина не может быть уверен в количестве своих детей"©, но вряд ли за последние несколько лет что-то существенно измениллось...

тогда извиняй ))) Мне на днях ветка попадалась, видимо обознался )

Точно! Это Кулешов Мишка был!

:-)