Бешеные тормоза после переноса на MS SQL #742361

После переноса переписанной файловой базы УТ 10.3 на MS SQL наблюдается лютые тормоза при работе с ней. Пользователей немного, штук 15 одновременной работы.При проведении ОРП с ТЧ в 226 строк система задумывается на 2(!) минуты, при чем 97% времени на строчку: УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров(Ссылка, Движения.СписанныеТовары.Выгрузить); Ну и формирование всяких отчетов стало занимать намного больше времени. На этом же сервере крутится еще 4 базы, с ними таких проблем нет. Настройки БД у всех одинаковые. Вроде и гуглил, и статейки всякие читал - причину найти не могу. Спасайте! Вводные: 8-ядерный Xeon CPU E5-2407 32Гб оперативной памяти SCSI винт (на котором базы) База УТ 10.3 размером в почти 9 Гб Платформа 1С:Предприятие 8.2 (8.2.19.90) Сервер 1с предприятия находится на другом компе Если нужна еще какая-нибудь информация - скажите. Насоветуйте чего-нибудь.

После переноса переписанной файловой базы УТ 10.3 на MS SQL наблюдается лютые тормоза при работе с ней. Пользователей немного, штук 15 одновременной работы.При проведении ОРП с ТЧ в 226 строк система задумывается на 2(!) минуты, при чем 97% времени на строчку: УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров(Ссылка, Движения.СписанныеТовары.Выгрузить); Ну и формирование всяких отчетов стало занимать намного больше времени. На этом же сервере крутится еще 4 базы, с ними таких проблем нет. Настройки БД у всех одинаковые. Вроде и гуглил, и статейки всякие читал - причину найти не могу. Спасайте! Вводные: 8-ядерный Xeon CPU E5-2407 32Гб оперативной памяти SCSI винт (на котором базы) База УТ 10.3 размером в почти 9 Гб Платформа 1С:Предприятие 8.2 (8.2.19.90) Сервер 1с предприятия находится на другом компе Если нужна еще какая-нибудь информация - скажите. Насоветуйте чего-нибудь.

+ Microsoft SQL Server 2008 R2

Я бы на индексы обратил внимание. Ну и регламентные процедуры обязательно настроить(проверить выполняются ли).

SCSIDiskIBM_____ServeRAID_M5110_3.24

Можно поподробней? желательно статью, где эти проблемы описываются

в хвосте это не скази, это название драйвера рэйда

Про индексы. Вот таким запросом можно смотреть статистику по отсутствующим индексам. В конце дня нужно выполнить и если есть в результате какие-то строки, то нужно разбираться и создавать индексы. SET NOCOUNT ON DECLARE @dbid int IF (object_id('tempdb..##IndexAdvantage') IS NOT NULL) DROP TABLE ##IndexAdvantage CREATE TABLE ##IndexAdvantage ([Преимущество индекса] float, [База данных] varchar, [Transact SQL код для создания индекса] varchar, [Число компиляций] int, [Количество операций поиска] int, [Количество операций просмотра] int, [Средняя стоимость ] int, [Средний процент выигрыша] int ); DECLARE DBases CURSOR FOR SELECT database_id FROM sys.master_files -- Получаем список ID баз данных WHERE state = 0 AND -- ONLINE has_dbaccess(db_name(database_id)) = 1 -- Only look at databases to which we have access GROUP BY database_id OPEN DBases FETCH NEXT FROM DBases WHILE @@FETCH_STATUS = 0 BEGIN -- Выполняем для каждой базы данных --------------------------------------------------       [Transact SQL код для создания индекса] = 'CREATE INDEX [IX_' + OBJECT_NAME(mid.object_id,@dbid) + '_' +       CAST(mid.index_handle AS nvarchar) + '] ON ' +       mid.statement + ' (' + ISNULL(mid.equality_columns,'') +       (CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ', ' ELSE '' END) +       (CASE WHEN mid.inequality_columns IS NOT NULL THEN + mid.inequality_columns ELSE '' END) +       ')' +       (CASE WHEN mid.included_columns IS NOT NULL THEN ' INCLUDE (' + mid.included_columns + ')' ELSE '' END) +       [Количество операций поиска] = migs.user_seeks,       [Количество операций просмотра] = migs.user_scans,       [Средняя стоимость ] = CAST(migs.avg_total_user_cost AS int),       [Средний процент выигрыша] = CAST(migs.avg_user_impact AS int) FROM  sys.dm_db_missing_index_groups mig JOIN  sys.dm_db_missing_index_group_stats migs ON    migs.group_handle = mig.index_group_handle JOIN  sys.dm_db_missing_index_details mid     FETCH NEXT FROM DBases GO SELECT * FROM ##IndexAdvantage ORDER BY 1 DESC -- Значение ''Преимущество индекса'' выше 5000 в промышленных системах означает, что следует рассмотреть возможность создания этих индексов. -- Если же значение превышает 10000, это обычно означает, что индекс может обеспечить значительное повышение производительности для операций чтения. -------------------------------------------------------------------------------------------- IF (object_id('tempdb..##IndexAdvantage2') IS NOT NULL) DROP TABLE ##IndexAdvantage2 SELECT * FROM ##IndexAdvantage WHERE [Преимущество индекса] >= 5000 ORDER BY 1 DESC Стырено с инфорстарта, кажется. Про регламентные процедуры статей куча, в гугле "регламентные процедуры sql 1с".

ну я хз, это мне админ так говорил, а это из ИД оборудования, единственное, на что у меня есть права посмотреть

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

отладка на сервере включена? разбей строку из на две - одна для получения ТЗ из движений, другая для выполнения процедуры общего модуля

Отладка на сервере отключена. Строки разбил, получение ТЗ из движения не занимает времени, что тормозит в общем модуле - посмотреть не могу.

в бэкапе симпл

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

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

регламенты есть только по индексам, обновление статистики добавил и сразу провел на проблемной базе - результат 0.

Эффект будет только через несколько дней? ))))

Это в реестр лезть надо?

Как вариант - поднять базу на PostgreSQL, которая в отличие от MSSQL не жрет всю память и при правильных запросах в 1с  почти не блокирует данные на чтение. И посмотреть - если оперативки не станет хватать, значит дело в некорректных запросах. Я в свое время на Linux с помощью Htop выявил некорректный запрос.

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

1. Регламенты. 2. Переписать партионное списание на годный код. 3. Реализовать управляемые блокировки. Но так как nobody_cares, то все останется как есть.

+146%, соник дело говорит

"поднять базу на PostgreSQL, которая в отличие от MSSQL не жрет всю память и при правильных запросах в 1с  почти не блокирует данные на чтение"

Подробнее можно по п.2? Можно на почту.

+ да и по п.3 интересно. Так как пишут многие, а реализаций не видел.

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

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

проверь в настройках скуля Max degree of parallelism (DOP). Скинь в 0 и проверь.

для MS SQL Server лучше наоборот 1 ставить.

точнее для баз 1С

Я точно не помню. Просто была непонятная фигня со сложным запросом: вплоть до вешанья сервака. Оказалось, что в DOP было дикое число, скуль паралеллил и сам потом развлекался с этими потоками, ни на что больше не реагируя :)

ну тогда  точно в 0 ставил :) это параметр отвечает за распараллеливание операций для многоядерных процессоров: 0 - это неограниченно

т.е. в 1 ))

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

А, шаг увеличения тмп файла у скл увеличен ? (по умолчанию он 1мб)

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

Скинул на почту

Max degree of parallelism (DOP) значение 1 У меня такая проблема, при добавлении строчки -debug у меня перестает запускаться агент на сервере. Вот такая ошибка, это мне админ прислал: Компьютер:     1CSERVER.kom-kastor.local Описание: Параметры разрешений для конкретного приложения не дают разрешения Локальный Активация для приложения COM-сервера с CLSID {BA126AD1-2166-11D1-B1D0-00805FC1270E} пользователю 1CSERVERUSR1CV82 с SID (S-1-5-21-4102014034-2086728852-1080897402-1002) и адресом LocalHost (с использованием LRPC). Это разрешение безопасности можно изменить с помощью служебной программы управления службами компонентов. Xml события: <Event xmlns="; Я так понимаю, там что-то с настройками безопасности. Админ комментариев не дает. Подскажите, что не так?

для вроде вот решение, вечером только проверим

увеличил до 200 - по фигу... для журнала тоже

для 8 лучше ставить 0, это для 7.7 надо ставить 1

вернул обратно на ноль

sql server 2008 r2 best practices analyzer ничего страшного не выяснил

Я бы посмотре что внутри этой процедуры тормозит.

для этого надо отладку на сервере включить, а это не получается пока

без этого дальнейший разговор бессмысленный. Может там блокировки идут

Ну ок. Можно в профайлере посмотреть что происходит на скуле в момент выполнения этой процедуры. Поставь точку останова на процедуру, перед выполнение запусти профайле и смотри самые тяжелые запросы.

сделай ...

Я несколько хз, где это запускать :))) И не понял, что конкретно этот скрипт делает. Буду рад пояснениям )))

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

Этот скрипт будет 5 часов мониторить при первом значении в 300?

да

Поставил на 5 минут и начал проведение проблемного документа, жду...

+ прогони тест Гилева

Проверь размер приращения БД, вот полезная статья на эту тему: не поленись прочитать

Таааак, а результат в мс?

какая конфигурация дисковой системы?

там в % куда нагляднее... нормально когда запись и чтение диска занимает 5-15%

Ок, спасибо. Щас после оценки результата из займусь

может админы все на один диск запихали

LAZYWRITER_SLEEP процент  = 25

вот еще статья по оптимизации + делали пересчет итогов

Рейд массив там вроде как. А так да, все на одном диске

запускать на менее часа смысла нет...

Надо ведь и нагрузку тогда обеспечить на проблемную базу для хорошего результата, не?

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

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

Попробуй бэкап свернуть/развернуть

а не проблемные базы типовые?

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

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

да, и все обновленные до последнего релиза. А проблемная это "Управление торговлей", редакция 10.3 (10.3.18.3) Ну он заявит что проблема в самой базе. При этом его заявление будет выглядеть логичным, ведь остальные базы не тормозят. Запустил на час без нагрузки, кроме обычной

Ну тогда проблемы с диском можно отмести.

Размер прироста выставлен в 200 мб при базе в 9гб. Судя по статье - норм показатель.

один работаешь или нет? Может регламент какой блокировки накладывает?

Если только с этой базой так на этом сервере, то очень вероятно что именно они

это если база располагается также как остальные

Нет, не один. На протяжении рабочего дня регламентов нет.

Попробуй в MSSQL включить регулятор запросов, и поставь 2000-10000, документы будет проводится быстрее, а вот кто больше всего начнет кричать, у того и смотри. Обычно отчеты сами начинают ругаться на этот параметр.

Начни с 2000.

Это не скажется на работе других баз?

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

Кстати - какой у тебя размер tempdb?

Модель восстановления какая устновлена, full или simple? Если full, то поменяй на simple.

Simple

Где посмотреть? ))))

В системных базах данных

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

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

Может проблема в том, что в файловой версии было прописано, что процедура выполняется локально, а нужно на сервере? Посмотри - при проведении - сколько у тебя грузится сеть.

Ошибки валятся про мутабельные значения

Тест ничего особо не показал, кроме LAZYWRITER_SLEEP, у нее 21 %, все остальные не превышают 12 Может все-таки нагрузить ее?

Но ведь тогда замер бы на нее сработал, нет?

Tempdb = 8мб, прирост 10%

+ ghjcnj ,fpf ctqxfc vj;tn ,snm yt jcj,j yfuhe;tyf gjkmpjdfntkzvb

+ просто база сейчас может быть вообще не нагружена пользователями

Получается, сервер недавно перезагружал? Для tempdb это очень маленький размер, поставь изначальный размер хотябы Мб 500, иначе постоянно будут блокировки на расширении файла данных. И я пропустил, индексы уже перестраивал? Если нет, запусти на ночь, днем перестроение индексов помешает работе пользователей

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