1c 8 sql тормозит отчет у пользователя
Любые пользователи 1С некоторое время спустя сталкиваются с тем, что программа начинает работать слишком медленно. Общие рекомендации по ускорению «1С» были даны в статье «Как ускорить работу 1С Бухгалтерия 8.3? Бесплатные лайфхаки по оптимизации», теперь поговорим об оптимизации файловой структуры и баз данных. Итак, что делать, чтобы ускорить базу «1С»?
Основные начала и принципа учета требуют практически немедленной реакции на любое событие хозяйственной жизни (см. Закон о бухучете), При между тем пользователи «1С: Бухгалтерия 8.3» отмечают существенное снижение скорости работы, что сказывается на продуктивности и эффективности работы. Попробуйте прежде всего оптимизировать базу в режиме конфигуратора.
Задать степень параллелизма
С помощью параметра «Максимальная степень параллелизма» (Max degree of parallelism) задается, во сколько потоков может выполняться один запрос. Так, если в поле стоит «0», то это означает, что сервер автоматически определяет это число. При использовании 1С оптимальным параметром будет «1».
Конечно, это далеко не все методы разогнать 1с, ускорить SQL, существует множество вариантов решения данной проблемы, правда, их реализацию лучше поручить техническим специалистам. Неумелое вмешательство в работу платформы может повлечь за собой потерю ценных данных и аварийную остановку ПО, а с ней – и работы в целом. Предлагаем квалифицированное и всестороннее обслуживание программ семейства «1С» – поручите техническую сторону дела нам, высвободив время для решения по-настоящему важных вопросов.
Ну собственно в том, что файловая база работала быстрее, чем СКЛ ничего особенного нет.
Но с СКЛ твориться какая то непонятная фигня.
Если утром провести на сервере СКЛ стандартные регламенты (очистка кэша, обновление статистики и реиндексацию), а затем рестартануть службу СКЛ сервера и Сервера 1С - то несколько часов база работает вполне прилично (не как файловая конечно, но терпимо).
Но затем по мере работы пользователей и отжирания оперативки СКЛ все начинает потихонечку замедлятся до полного безобразия - и документ который утром проводился за 1-1,5 секунды к обеду начинает проводиться секунд 5-10 - и это уже начинает становиться критичным.
Утром все повторяется.
Это вообще нормальное поведение для СКЛ и 1С - или надо чето делать?
Сервер: Вин2к3 стандарт 64х. 2хXeon E5540 2,53 GHz, 18 Gb RAM
SQL 2005 sp3 32 bit
1C 8.3.4.437 32 bit
Пользователи работают на отдельном сервере терминалов.
(0) нет, это не нормально и вопиет о криво настроенном как сиквеле, так и сервере приложений
ну и конечно работать под 32 bit безумие
(1) по поводу кривизны СКЛ и 1С - куда копать то?
По поводу 32 бит - не спорю - но маемо, шо маемо - "мопед не мой".
А с другой стороны и однозначности в этом вопросе тоже нет - тут мелькали темки в которых народ экспериментировал с разными комбинациями битности - и учитывая наличие в этой связке 1С - результаты как то не особо однозначны были.
Да и по-большому счету битность однозначно влияет на общую скорость, но связь битности с замедлением работы для меня не очевидна.
(3) Ну с утра после рестарта - с учетом всех процессов занято где то 5-6 Гб.
Сейчас конец дня - занято 16 гб.
Непосредственно СКЛ сожрал где то около 10 гб.
Кстати а где глянуть битность СКЛ?
А то я чето написал 32 а теперь усомнился - ибо в диспетчере задач - на 32 битных процессах есть в наименовании *32. А на СКЛ -нету.
А в "Опрограмме" студии версию пишет, а битность че то не вижу.
Итак, дано:
1. Сервер: Dell PowerEdge R815 (AMD Opteron 6276 2.3GHz, 4 процессора, 128 ГБ ОЗУ). SAS диски 10000 об/мин.
2. ОС: Windows Server 2008 R2 x64
3. СУБД: MS SQL Server 2012
4. Там же установлен сервер приложений 1С (8.3.10.2466). С SQL-сервером общаются в режиме Shared memory. Количество ИБ на процесс = 1.
5. Клиента 1С ERP пользователи (их на данный момент не более 10) запускают с сервера терминалов. Сеть между терминалкой и сервером БД - 1Гбит через коммутатор.
6. SQL-серверу выделено 90 ГБ ОЗУ (причём, что интересно, раньше он выедал классически всю выделенную ему память. Сейчас же, после последней перезагрузки, не более 500МБ). Параметр Maxdop = 1. Cost threshhold of parallelism=15. Maximum worker threads-2048. Модель восстановления БД Simple.
7. Мониторинг производительности показал что дисковых очередей значительных нет. Блокировок нет. Buffer Cache Hit Ratio стабильно в районе 100%.
8. Тест Гилёва в попугаях показал 18 пернатых (если кому интересно).
Собственно проблема заключается в том, что при открытии списков и проведении документов приходится ждать по 10-30 секунд. При этом единственное, что я заметил, резко возрастает в мониторинге значение параметра Batch requests/sec и вместе с ним SQL Re-Compilations/sec.
Развернул из выгруженного DT-шника БД у себя на рабочей машине (совсем офисная станция) в файловый вариант - всё летает. Мгновенно любые операции выполняются.
А насколько показательны вот эти вещи?
"Batch requests/sec и вместе с ним SQL Re-Compilations/sec"
Какие по ним можно сделать выводы?
Клиента 1С ERP пользователи (их на данный момент не более 10) запускают с сервера терминалов.
Тут еще проблема может быть.
Настрой 1с с локального компа.
(1) 2.2.4.31
насчет RLS, к сожалению, не знаю. Где посмотреть?
(2) Да. Переиндексация/ребилд по степени фрагментации, обновление статистики.
(3) Неоптимальные запросы, проблемы с планом выполнения. Если грешить на код.
(4) проблема повторяется даже если кэша вообще нет, с нуля. SSD нет в наличии, поэтому не вариант.
(5) Пробовал с локального - та же история.
УТ 11. SQL экспресс.
На сервере крутится 2 базы, УТ 11 и БП.
БП вроде работает нормально. А вот УТ просто жутко тормозит.
Работает 5 пользователей.
Жуткие тормоза при создании и проведении документов.
В файловом варианте база летает.
Перезапуск агента сервера не помогает.
Временное облегчение приносит ТиИ базы.
Но это на сутки, а то и меньше.
(8) делать ТИИ ежедневно не вариант
(0) не настроены регламенты SQL, угадал ?
Так, совсем не понял.
Посмотрел сейчас в Скуль менеджере.
Там база весит 36 гигабайт о_0!
При этом работает. Хотя у экспресса же ограничение на 10 гигов.
Как такое возможно?
(12) Почему. Может и экспресс.
Просто у экспресса нет sql agent и регламенты надо выполнять снаружи, например батником по расписанию.
(11) Может это лог разросся.
(13) реиндексация, обновление статистики, очистка процедурного кэша.
(9) Мне казалось что у какого-то нового SQL Express есть Agent, я не уверен. Но sqlcmd есть в любом случае.
(10) Ну значит разбираться почему ТиИ помогает и делать это же но например средствами SQL.
(11) Что в данном случае называется словом база?
Сейчас вот сижу проверяю. И не понятные дела происходят.
То все тормозит жутко, то ни с того, ни с сего все начинает просто летать. Работает быстро как и должно быть.
Тормоза начинаются когда процесс sql отжирает полностью одно ядро. Как понять чем вызвано?
(15) в SQL менеджере, в свойствах "Размер" )))
(16) пиши тогда уже на какой операционке оно установлена и действительно ли там 64 бит у 1С-ного сервера. И где там устанавливают ограничения на число rphost
(17) Эххх
Я так сказать там пытаюсь разобраться за спасибо. По старой памяти.
так хочется по быстрому отделаться)))
SQL Server 2012 Express Edition — является бесплатной версией SQL Server, идеально подходящей для разработки и развёртывания в настольных системах, в веб и малых серверах приложений. Новой возможностью Express версии SQL Server 2012 является SQL Server Express LocalDB. Это облегченная версия Express, которая имеет все программные функции, запускается в пользовательском режиме, быстро устанавливается, не требует настройки и имеет низкие системные требования.
Регламентные операции на уровне СУБД для MS SQL Server
Инструкция по выполнению регламентных операций на уровне СУБД.
Информация применима к клиент-серверному варианту "1С:Предприятия 8" при использовании СУБД MS SQL Server.
Общие сведения
Одной из часто встречающихся причин неоптимальной работы системы является неправильное или несвоевременное выполнение регламентных операций на уровне СУБД. Особенно важно выполнять эти регламентные процедуры в крупных информационных системах, которые работают под значительной нагрузкой и обслуживают одновременно большое количество пользователей. Специфика таких систем в том, что обычных действий, выполняемых СУБД автоматически (на основании настроек) оказывает недостаточно для эффективной работы.
Если в работающей системе наблюдаются какие-либо симптомы проблем с производительностью, следует проверить, что в системе правильно настроены и регулярно выполняются все рекомендуемые регламентные операции на уровне СУБД.
Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan. Существуют так же другие способы автоматизации выполнения этих процедур. В настоящей статье для каждой регламентной процедуры дан пример ее настройки при помощи Maintenance Plan для MS SQL Server 2005.
Для MS SQL Server рекомендуется выполнять следующие регламентные операции:
Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур.
Обновление статистик
MS SQL Server строит план запроса на основании статистической информации о распределении значений в индексах и таблицах. Статистическая информация собирается на основании части (образца) данных и автоматически обновляется при изменении этих данных. Иногда этого оказывается недостаточно для того, что MS SQL Server стабильно строил наиболее оптимальный план выполнения всех запросов.
В этом случае возможно проявление проблем с производительностью запросов. При этом в планах запросов наблюдаются характерные признаки неоптимальной работы (неоптимальные операции).
Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.
Для обновления статистик по всем таблицам базы данных необходимо выполнить следующий SQL запрос:
Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.
Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день .
Приведенный выше запрос обновляет статистики для всех таблиц базы данных. В реально работающей системе разные таблицы требуют различной частоты обновления статистик. Путем анализа планов запроса можно установить, какие таблицы больше других нуждаются в частом обновлении статистик, и настроить две (или более) различных регламентных процедуры: для часто обновляемых таблиц и для всех остальных таблиц. Такой подход позволит существенно снизить время обновления статистик и влияние процесса обновления статистики на работу системы в целом.
Настройка автоматического обновления статистик (MS SQL 2005)
Запустите MS SQL Server Management Studio и подключитесь к серверу СУБД. Откройте папку Management и создайте новый план обслуживания:
Создайте субплан (Add Subplan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач:
Настройте расписание обновления статистик. Рекомендуется обновлять статистики не реже одного раза в день. При необходимости частота обновления статистик может быть увеличена.
Настройте параметры задачи. Для этого следует два раза кликнуть на задачу в правом нижнем углу окна. В появившейся форме укажите имя базу данных (или несколько баз данных) для которых будет выполняться обновление статистик. Кроме этого вы можете указать для каких таблиц обновлять статистики (если точно неизвестно, какие таблицы требуется указать, то устанавливайте значение All).
Обновление статистик необходимо проводить с включенной опцией Full Scan.
Сохраните созданный план. При наступлении указанного в расписании срока обновление статистик будет запущено автоматически.
Очистка процедурного КЭШа
Оптимизатор MS SQL Server кэширует планы запросов для их повторного выполнения. Это делается для того, чтобы экономить время, затрачиваемое на компиляцию запроса в том случае, если такой же запрос уже выполнялся и его план известен.
Возможна ситуация, при которой MS SQL Server, ориентируясь на устаревшую статистическую информацию, построит неоптимальный план запроса. Этот план будет сохранен в процедурном КЭШе и использован при повторном вызове такого же запроса. Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план.
Таким образом, рекомендуется всегда после обновления статистик очищать содержимое процедурного КЭШа.
Для очистки процедурного КЭШа MS SQL Server необходимо выполнить следующий SQL запрос:
Этот запрос следует выполнять непосредственно после обновления статистики. Соответственно, частота его выполнения должна совпадать с частотой обновления статистики.
Настройка очистки процедурного КЭШа (MS SQL 2005)
Поскольку процедурный КЭШ необходимо очищать при каждом обновлении статистики, данную операцию рекомендуется добавить в уже созданный субплан «Обновление статистик». Для этого следует открыть субплан и добавить в его схему задачу Execute T-SQL Statement Task. Затем следует соединить задачу Update Statistics Task стрелочкой с новой задачей.
В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»:
Дефрагментация индексов
При интенсивной работе с таблицами базы данных возникает эффект фрагментации индексов, который может привести к снижению эффективности работы запросов.
Рекомендуется регулярное выполнение дефрагментации индексов. Для дефрагментации всех индексов всех таблиц базы данных необходимо использовать следующий SQL запрос (предварительно подставив имя базы):
sp_msforeachtable N'DBCC INDEXDEFRAG (, ''?'')'
Дефрагментация индексов не блокирует таблицы, и не будет мешать работе других пользователей, однако создает дополнительную нагрузку на SQL Server. Оптимальная частота выполнения данной регламентной процедуры должна подбираться в соответствии с нагрузкой на систему и эффектом, получаемым от дефрагментации. Рекомендуется выполнять дефрагментацию индексов не реже одного раза в неделю.
Возможно выполнение дефрагментации для одной или нескольких таблиц, а не для всех таблиц базы данных.
Настройка дефрагментации индексов (MS SQL 2005)
В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов».Добавьте в него задачу Reorganize Index Task:
Задайте расписание выполнения для задачи дефрагментации индексов. Рекомендуется выполнять задачу не реже одного раза в неделю, а при высокой изменчивости данных в базе еще чаще – до одного раза в день.
Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.
Реиндексация таблиц базы данных
Реиндексация таблиц включает полное перестроение индексов таблиц базы данных, что приводит к существенной оптимизации их работы. Рекомендуется выполнять регулярную переиндексацию таблиц базы данных. Для реиндексации всех таблиц базы данных необходимо выполнить следующий SQL запрос:
sp_msforeachtable N'DBCC DBREINDEX (''?'')'
Реиндексация таблиц блокирует их на все время своей работы, что может существенно сказаться на работе пользователей. В связи с этим реиндексацию рекомендуется выполнять во время минимальной загрузки системы.
После выполнения реиндексации нет необходимости делать дефрагментацию индексов.
Настройка реиндексации таблиц (MS SQL 2005)
В ранее созданном плане обслуживания создайте новый субплан с именем «Реиндексация». Добавьте в него задачу Rebuild Index Task:
Задайте расписание выполнения для задачи реиндексирования таблиц. Рекомендуется выполнять задачу во время минимальной нагрузки на систему, не реже одного раза в неделю.
Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.
Контроль выполнения регламентных процедур на уровне СУБД
Необходимо осуществлять регулярный контроль выполнения регламентных процедур на уровне СУБД. Ниже приведен пример контроля выполнения плана обслуживания для MS SQL Server 2005.
Откройте созданный вами план обслуживания и выберите из контекстного меню пункт «View History»:
Откроется окно с протоколом выполнения всех заданных регламентных процедур.
Успешно выполненные задачи и задачи, выполненные с ошибками, будут помечены соответствующими иконками. Для задач, выполненных с ошибками, доступна подробная информация об ошибке.
Настройка электропитания
Переходим из «Панели управления» в меню «Электропитание»:
В списке планов электропитания выбирайте «Высокая производительность»:
После этих нехитрых операций ваш ПК даже под «семеркой» сможет выделить достаточные аппаратные ресурсы с тем ускорить файловую «1С».
Включаем мгновенную инициализацию
Включение мгновенной инициализации файлов для пользователя, от имени которого запускается Microsoft SQL Server, что позволяет «разогнать» процессы:
- создания БД;
- добавления в имеющуюся БД файлов, журналов и проч.;
- увеличения размера существующих файлов;
- восстановления БД и (или) файловых групп.
Развертываем «Локальные политики», кликаем «Назначение прав пользователей», дважды кликаем на «Выполнение задач по обслуживанию томов», нажимаем «Добавить» - и включаем включения пользователя или группу. Не забываем нажать «Применить».
Тест работы проводится путем создания новой базы (файл в 5 Гб, журнал транзакций - 1 Мб). Если она сформировалась моментально, то все корректно (не забудьте удалить тестовую базу).
Отключить DFSS для дисков
Механизмы Dynamic Fair Share Scheduling (DFSS) осуществляют распределение аппаратных ресурсов, балансируют их между пользователями, что порой замедляет работу. Чтобы ускорить файловую базу 1С, порой достаточно отключить для дисков, для чего достаточно, вызвав реестр («Win» + «R», в окне «Выполнить» вписать «regedit», нажать «Enter»). В ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk задать «0» в параметре EnableFairShare.
Включить блокировку страниц в памяти
Включение разрешения на блокировку страниц в памяти для пользователя или группы производится аналогичным образом.
Тем самым мы определяем, какие именно пользователи вправе сохранять данные в оперпамяти. При этом система не будет отправлять страницы данных в виртуальную память на диске, что повышает производительность. Для проверки следует или перезагрузить сервер, или зайти под логином пользователя, под которым происходит запуск MS SQL Server.
Ускорение базы 1С в конфигураторе
Первым делом следует сформировать бэкап, что можно сделать и без запуска конфигуратора (при наличии прав администратора).
Тормозит 1С, ускорить SQL?
Первая рекомендация, хотя и несложная по реализации, нередко помогает решить рассматриваемую проблему.
Производим запуск SQL Server Management Studio и ввод данных для подключения, кликнув правой клавишей по серверу, открываем «Свойства»:
Выбираем закладку «Память», настраиваем ограничение потребления оперпамяти. Это делается в окошке «Максимальный размер памяти сервера (МБ)». Чтобы рассчитать этот показатель, необходимо от всего объема оперативной памяти отнять на нужды системы 4096 Мб, а затем вычесть произведение 1536 на число rphost-процессов. Так, при 32 Гб оперпамяти на сервере и двух процессах rphost максимальный размер будет равен 25 600 Мб (32 768 (32 х 1024) – 4096 – (1536 х 2)).
Перейдя на вкладку процессоров, выставляем в окне «Максимальное число рабочих потоков» значение 2048 (при значении «0» число потоков не может превышать 255), и включить чекбокс «Поддерживать приоритет SQL Server».
Вызвав «Базы данных» и рабочую базу (нажатием правой клавиши мыши), переходим на «Свойства» - «Файлы» - «Авторасширение» выставляем расширение файла БД до 250 мегабайт, лога - до 100 мегабайт с ограничением до 4096 Мб.
После нажатия «OK» закрываем программу. Замеры показывают существенное ускорение файловой 1С.
Тестирование и исправление
В режиме конфигуратора переходим по пути «Администрирование» - «Тестирование и исправление»:
В открывшемся окне отмечаем следующие пункты:
- «Реиндексация таблиц информационной базы»;
- «Пересчет итогов»;
- «Сжатие таблиц информационной базы».
Устанавливая галочки, мы получаем следующее:
- «Реиндексация таблиц информационной базы» - перестраивает табличные индексы, что позволяет ускорить 1с 8.3 файловый;
- «Пересчет итогов», т.ч. подсчитанных результатов, представленных в виде таблицы, что позволяет «разогнать» получение данных;
- «Сжатие таблиц информационной базы» уменьшает объемы БД на жестком диске.
Проверяем результаты нашей работы. Если ускорить 1С 8.3 файловый не удалось, следует попробовать иные методы
Оптимизация старых ОС
Если в силу каких-либо причин вам приходится работать на «возрастных» ОС – в частности, Windows 7 («семерка»), - то будет нелишним предпринять ряд элементарных шагов, которые помогут ускорить файловую базу 1С, поскольку ПК сможет выделять дополнительные ресурсы для обслуживания системы.
Отключить сжатие данных
Чтобы ускорить базу 1С, можно попробовать отключить сжатие данных для каталогов, где располагаются файлы БД. При включенной опции операционная система производит дополнительную обработку файлов, что замедляет процесс записи (хотя и экономит пространство на диске). Для отключения этой опции открываем свойства каталога (DATA Properties), на вкладке «Общие» (General) нажимаем «Другие» (Advanced Attributes), снимаем (если установлен) флажок «Сжимать содержимое для экономии места на диске» (Compress contents to save disk space).
Формирование бэкапа
На выходе вы получите зазипованный файл, находящийся там, где вы указали.
Оптимальное быстродействие
Вызовите свойства ПК (щелчок правой клавиши мыши по иконке «Мой компьютер» - «Свойства»:
Выбрать «Дополнительные параметры системы» (меню слева):
Переходим на вкладку «Дополнительно», открываем «Параметры быстродействия»:
На вкладке «Визуальные эффекты» отметить чекбокс «Обеспечить наилучшее быстродействие» для того чтобы снизить нагрузку на компьютер.
Читайте также: