Методы повышения производительности 1C на MS SQL. 1C sql оптимизация


Настройки для оптимизации производительности серверов СУБД(MS SQL) и Application (1C)

Тестирование SQL проблем

текст скрипта

Раскрытие тайны задержек SQL Server

ОПИСАНИЕ ТИПОВ ЗАДЕРЖЕК

---------------------------

Т.е. например разделили ДВА сервера по Gigabit Ethernet:1)видим картину нет загрузки сети больше 20% ))) - и системный администратор делает вывод что сети вполне хватает НО ОН ОШИБАЕТСЯ)) т.к. на самом мелкие пакеты и реальная скорость обмена 250 Мегабит/с то в принципе фиг загрузим сеть под 100% А если весь обмен идет по ОДНОМУ ПОРТУ то ВСЕ становится в очередь и будь у вас хоть одновременно СОТНЯ ПОЛЬЗОВАТЕЛЕЙ все они будут внутри этих 250 Мегабит и в очереди.

2)т.к. возникает ЗАДЕРЖКА из пункта 1) то возникают ситуации когда 1С сервер ожидает пока придут данные Основные, притом подкидывая новые запросы на SQL уточняя Основные данные(Объекты внутри Объектов и т.п)

3) т.к. возникают ожидания как следствия из пунктов 1) и 2) - то СИСТЕМНЫЙ АДМИНИСТРАТОР видит: - нет нагрузки на CPU - нет нагрузки на диски и делает вывод - система отлично сбалансирована и имеет значительный запас производительности но почему-то тормозит 1С - значит корень в самой 1с ибо она Абсолютно кривая и порочная (есть конечно часть правды...в этом...но лишь часть правды)) В ИТОГЕ ОН ОШИБАЕТСЯ т.к. 1С и SQL как получилось имеют медленный канал для обмена ОНИ ПРОСТО ОЖИДАЮТ ДРУГ ДРУГА и НЕ ГРУЗЯТ CPU и Диски

частично сэмулировать данную проблему можно следующим образом 1)берем Файловую 1С с объемом базы побольше 2)берем скоростной комп - но с Объемом оперативки небольшим (чтобы Кэшировалось поменьше) 3)берем какой-нибудь накопитель со скоростью Чтениние/Запись не больше 30 Мегабайт/с (250 Мегабит/с) ставим замеры скорости проведения документов))

потом 4)берем какой-нибудь накопитель со скоростью Чтениние/Запись 500 Мегабайт/с ставим замеры скорости проведения документов))

и все увидите))

Есть Иной способ решения Связки "1С" с "MS-SQL" это перенести ВСЮ ЛОГИКУ на сам MS SQL, т.е. практически не использовать программирование на языке 1С, а писать встроенные процедуры в SQL и Использовать от 1с только внешний вид на клиентах)).

Таки этот путь ОЧЧЧЕНЬ сложен в реализации и это уже будет не 1С)).И только такой путь может СНЯТЬ СИЛЬНУЮ зависимость от коммуникационной среды передачи данных. ИМХО вся бизнес логика будет крутится внутри самого SQL.

Но это не мой путь, затраты+время на разработку + поддержка = "не стоит игра свеч".

(Далее...)

---------------------------

О скорости работы 1с 8.х или как Выбрать сервер для 1С 8.х

---------------------------

Медленно работает 1С по сети с базой на SQL Server.

Одно из решений — правильно настроить сетевые протоколы для взаимодействия с SQL Server.http://www.1csql.ru/materials/faq/admin.html

Для такой настройки ODBC должен быть версии не ниже 3.5С помощью утилиты Client Network Utility (CLICONFG.EXE) (Program — Microsoft SQL Server — Client Network Utility) необходимо настроить протокол общения с SQL сервером. По умолчанию «Default network library» установлен в «Named Pipes», надо установить в «TCP/IP» и добавить строку в Server alias configuration. Где, соответственно, указать псевдоним, имя сервера, протокол TCP/IP, порт (можно оставить без изменений, если на сервере порт не был изменен). Вот пример настройки:

1 — пример настройки протоколов, 2 — ставить необходимо когда клиент и SQL Server находятся физически на одном компьютере, в єтом случае обмен идет не по сетвевым ресурсам, а через память.

(Далее...)

---------------------------

Настройка сервера 1С и MS SQL Server (gilev.ru)

---------------------------

Совмещение ролей сервера 1С + MS SQL Server (gilev.ru)

---------------------------

Проектирование сервера под 1С

odines.blogspot.com

Настройка MS SQL для работы с 1С Предприятие — Soft Setup

В целом настройка MS SQL Server для работы с 1С предприятия не сильно отличается от его обычной настройки, но все же есть некоторые нюансы выявленные опытным путем.

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

Установка MS SQL Server

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

Выбор и настройка компонентов

Для работы MS SQL Server c 1С Предприятие достаточно выбрать  следующий набор компонент:

Важно! Каталог общих компонентов лучше указывать на отдельном диске (отдельно от операционной системы). Это повысит скорость работы и отказоустойчивость.

Конфигурация сервера

Для запуска служб  Агент SQL Server и SQL Database Engine указываем учетную запись. Можно создать отдельнную учетную запись с правами администратора, либо указать учетную запись Администратор. Однако стоит помнить — если Вы решите когда-нибудь сменить пароль для учетной записи, которую здесь указали, то и служба перестанет запускаться. Поэтому используйте учетную запись в которой не планируете менять пароль.

Настройке компонента Databse Engine

Указываем смешанный режим и задаем пароль для sa — системной учетной записи SQL Server.

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

Далее все настройки можно оставить по-умолчанию.

Настраиваем брэндмауэр для работы mssql и 1С Серверa

Создаем правила разрешающее входящие подключения на  порт 1433 для MS SQL и 1541-1560 для 1С Сервера

Создаем правило для программы. Путь до программы будет выглядеть примерно такC:\Program Files\Microsoft SQL Server\MSSQL13.<InstanceName>\MSSQL\Binn\sqlservr.exe

Настройка свойств сервера Ms SQL для работы с 1С

Запускаем Microsoft SQL Server Management Studio и подключаемся к серверу.

Открываем окно свойств сервера и переходим к пункту Память. Выставляем максимально допустимое значение выделения памяти под нужды SQL сервера. Если этого не сделать он скушает всю свободную память, потому-что по-умолчанию стоит значение  2147483647 МБ. Допустимое значение памяти можно рассчитать по формуле (использовал опыт Алексея Новоселова с Infostat.ru):[Общее количество оперативной памяти сервера] – [4ГБ под систему(2ГБ если Win2003)] – [1,5 ГБ * количество процессов rphost (если SQL и 1С на одном сервере вращаются.)] Например если у нас на сервере всего 36 ГБ оперативной памяти, стоит Windows 2008 и запущено 8 процессов rphost то рассчет идет так: 36 — 4 — 1.5*8 = 20 ГБ ставим ограничение для SQL.

Переходим к пункту Процессор. Максимальное число рабочих потоков так же лучше установить вручную и задать значение 2048 так как при значении 0 число потоков может не превышать 255. Включаем параметр Поддерживать приоритет SQL.

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

Настройка рабочей базы 1С Предприятия

Открываем свойства настраиваемой базы данных.

Теперь самое главное определится с моделью восстановления базы данных. Они настраиваются в нукте параметры. Рассмотрим две основные модели восстановления.

1. Простая. Ее нужно использовать в том случае, когда вы планируете делать бэкап раз в день и для  вас не имеет значения возможность восстановления с точностью до определенного момента. Это может быть 1С Бухгалтерия или ЗУП где нет большого количества ежедневных транзакций. Делаете один бэкап каждую ночь и спите спокойно. Никаких сложностей.

2. Полная. Такую модель лучше всего использовать для бэкапа баз с большим количеством внутридневных транзакций, например продажи в 1С Розница. При такой модели у вас будут сохранятся все транзакции в журналах и будет возможность восстановления базы до любого момента времени. Но в этом случае придется повозится с настройками журналов транзакций.

 

Когда мы определились с моделью восстановления можно перейти к пункту [Файлы]

Для файла [Данные строк] размер авторасширения выставляем 200МБ. По-умолчанию выставлен 1МБ и это мало. Если у вас много транзакций по 1С, тогда SQL будет вынужден постоянно выполнять авторасширение и это будет тормозить его работу.

Настройку типа файла [Журнал] можно пропустить если используется простая модель восстановления.Если используется полная то необходимо скорректировать настройки.Авторасширение установим 50МБ. Стоит обратить внимание на ограничение авторасширения и его лучше изменить т.к. значение по-умолчанию больше 2Тб. При большом количестве транзакций, например розничные продажи в 1С Розница,  журнал транзакций будет расти очень быстро и вскоре у вас закончится свободное место на накопителе. Поэтому ограничение лучше установить на 10ГБ. Но это всего-лишь рекомендация, потому-что все индивидуально и зависит от количества транзакций.

При установке ограничения стоит помнить, что при достижении крайнего значения вас ждет ошибка: «журнал транзакций для базы данных заполнен» и 1С не будет запускаться. Чтобы журнал транзакций своевременно очищался необходимо настроить его бэкап в плане обслуживания базы данных. О том как создать план обслуживание базы жанных читайте здесь.

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

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

 

soft-setup.ru

Тормозит сервер 1С или компьютер с 1С

Очень часто ко мне обращаются с вопросами вида:

Что же делать и как это победить, и так по порядку:

Клиенты очень медленно работают с серверной версией 1С

Кроме медленной работы 1С, так же наблюдается медленная работа с сетевыми файлами. Проблема встречается при обычной работе и при RDP

для решения этого, после каждой установки Семерки или 2008-го сервера всегда запускаю

netsh int tcp set global autotuning=disabled

netsh int tcp set global autotuninglevel=disabled

netsh int tcp set global rss=disabled chimney=disabled

и сеть работает без проблем

иногда оптимальным является:

netsh interface tcp set global autotuning= HighlyRestricted

вот как выглядит установка

Далее посмотрите настройки брандмауэра Windows

Настроить брандмауэр Антивируса или Windows

Как настроить брандмауэр Антивируса или Windows для работы сервера 1С (связка из Сервера 1С: Предприятие и MS SQL 2008, например).

Добавьте правила:

Настройка производительности Сервера / Компьютера

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

1. Настройки BIOS

 

2. Настройки схемы в операционной системе - Высокая производительность

Сервера с архитектурой Intel Sandy Bridge умеют динамически менять частоты процессора.

Скачайте утилиту PowerSchemeEd.7z , распакуйте с помощь 7zip и запустите PowerSchemeEd.exe

Выберите раздел Управление питанием процессора и выставите параметры 01. Порог при питании от сети 30% и отключите 27. Переопределение ядра... как на картинке.

3. На серверах 1С и MS SQL Server использование антивирусов (даже сам факт инсталяции без включения) будет приводить к снижению производительности в виде периодических массовых замедлений и подвисаний интерфейса.

4. Совмещение ролей сервера 1С и сервера MS SQL Server дает большую производительность, особенно если использовать протокол обмена данных напрямую через память «Shared Memory».

Очень многие не недооценивают важность настройки сервера, когда роли сервера 1С и сервера СУБД совмещены на одном физическом компьютере.

Убедиться, что к примеру используется протокол Shared Memory можно следующим образом:

Код SQL select program_name,net_transport from sys.dm_exec_sessions as t1 left join sys.dm_exec_connections AS t2 ON t1.session_id=t2.session_id where not t1.program_name is null

Обратите внимание, что в версиях платформы некоторые релизы «переключались» на протокол «именнованых каналов».

Для работы 1С Предприятие  в режиме Shared Memory с SQL Server 2012 должен быть установлен NativeClient от SQL Server 2008 (backward compatibility connectivity components из дистрибутива SQL Server 2012 или отдельный пакет)

5. Отключение ненужных служб Виндовс

Одним из самых действенных способов ускорения компьютера является отключение неиспользуемых (ненужных) служб операционной системы. У ОС Windows по умолчанию включено огромное количество служб, на работу которых требуется большое количество ресурсов системы. Многие из них можно отключить без потери функциональности и снижения безопасности системы.

Какие службы можно отключить для оптимизации Windows:

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

Кэширование записей на дисках в Windows 

Кэшированием записей на устройстве хранения называется использование высокоскоростной энергозависимой памяти для накопления команд записи, отправляемых на устройства хранения данных, и их кэширования до тех пор, пока их не обработает более медленный носитель (либо физические диски, либо недорогая флэш-память). Для большинства устройств, использующих кэширование записей, требуется непрерывная подача электропитания.

Для управления кэшированием записей на диске откройте Панель управления - Диспетчер устройств.

В разделе Дисковые устройства дважды щелкните нужный диск.

Перейдите на вкладку Политики

В статье использован личный опыт и cайт Вячеслава Гилева

Буду рад конструктивным комментариям

helpf.pro

1C+MS SQL и файловый вариант: что быстрее?

В Сети пользователи частенько задают вопрос: в чем причина того, что файловая система обрабатывает запросы быстрее, чем 1C+MSSQL.

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

Попробуем внимательно рассмотреть проблему и ответить на интересующих многих вопрос: что же быстрее – 1C+MS SQL или файловый вариант?

В первую очередь рассмотрим сравнительную таблицу двух вариантов 1С – файлового и серверного.

Файловая 1С

Клиент-серверная 1С

Максимальный размер таблицы

4 gb

~сотни терабайт

Размер таблицы, при котором 1С начинает работать медленно

~16 Gb

~500-1500 Gb

Число пользователей, при котором 1С работает безупречно

3-10 (при большем количестве пользователей появляются табличные блокировки)

300-700 (если есть необходимость в большем количестве пользователей, требуется более мощное железо и оптимизация кода)

Функции, потребляющие ресурсы, которые обеспечивают высокую производительность

Нет

Транзакционная целостность данных, логирование операций для дальнейшего анализа, функции повышения параллельности работы пользователей

Преимущества

Простота использования за счет малого количества функций

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

Минимальная область блокировки

В таблице, т.к. требуется меньшее количество ресурсов)

В записях, т.к. требуется больше ресурсов)

Примерная стоимость владения

Невысокая

Значительно больше файловой

Наличие промежуточного этапа между пользователем 1С и СУБД

Нет

Сервер 1С

Сделаем предварительные выводы, исходя из полученных нами данных.

Итак, файловый вариант срабатывает оперативнее в том случае, если его функционирование не зависит от действий клиентов в базе.

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

Если же такой способ оказался не совсем убедительным, проверьте и в одном, и в другом вариантах любую операцию. Для примера возьмем «закрытие месяца». Вводим операцию в файловый вариант и тестируем. Стоит помнить, что подобный тест возможен только в том случае, если размер базы не превышает 4 гигабайт. Если же данный показатель превышен, то можно с уверенностью сказать, что файловый вариант не подходит для выполнения этой операции.

Теперь попробуем отобразить скорость обработки запроса в двух вариантах 1С в цифрах.

1.      Операции средней сложности файловый вариант обрабатывает примерно в два раза быстрее.

2.      С операциями средней сложности, при которых объем оперативной памяти меньше объема обрабатываемых данных, файловый вариант 1С справляется в 3 или 2 раза быстрее серверного варианта.

Давайте теперь определимся с таким понятием, как операция средней сложности. Если подробно разобраться, то получается, что некоторые операции, которые обработаются в серверном варианте, выполняются даже быстрее, чем в файловом. Но мы не берем их в расчет, так как их количество незначительно в общем объеме выполняемых операций. Основную массу составляют операции, которые обращаются к дисковой подсистеме для чтения или записи информации. Кстати, даже самые примитивные операции записывают данные, к примеру, в базу tempdb, если используется MS SQL Server.

Вернемся к файловому варианту. При введении запроса операция не обращается к серверу 1С, а это значит, что существенно экономится время обработки запроса. Тормозят работу серверного варианта и некоторые функции СУБД, ведь используются они зачастую не только для выполнения запросов, но и для обеспечения комфортной работы с другими запросами. Рассмотрим данную ситуацию на примере блокировки используемых данных: серверный вариант делает эту работу более тщательно, чем файловый, который зачатую блокирует нужные данные. Блокировка всей таблицы проходит гораздо быстрее, потому что появляется всего одна запись о блокировке, а блокировка тысячи строк таблицы – процесс более длительный и затратный в плане ресурсов: процессора, используемой памяти и даже места на диске. Таким образом, можно сделать вывод, что серверный вариант требует большее количество ресурсов, чем файловый, для выполнения одинакового объема работы.

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

Для ответа на этот вопрос следует ответить на следующий: насколько эффективно работает файловый вариант в режиме, когда пользователи активно используют одни и те же ресурсы, к примеру, при продаже товара постоянно проверяют его наличие на складе?

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

Разберем данную ситуацию на конкретном примере. Возьмем предприятие, на котором с 1С работает 10 человек. Каждый из пользователей в день вводит, например, 10 документов, в которых 10 табличных строк. Путем нехитрых вычислений получаем 1000 строк, что вводят в систему каждый день.

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

Теперь предположим, что 10 пользователей одновременно нажмут кнопки при проведении первых в день документов. Время блокировки в файловом варианте примерно 20 секунд. То есть первый пользователь осуществит проведение документа сразу, а вот всем остальным придется ждать еще по 20 секунд друг за другом. Рассчитаем время простоя: 10 пользователей*1 документ*20 сек. Получаем 200 секунд ожидания!

Согласитесь, ждать каждый раз больше трех минут пользователи не станут, ведь они не знают, заблокирована система или можно проводить документ. Поэтому вывод, который они сделают, - система не работает, соответственно, работать с ней невозможно. Таким образом, может остановиться работа всего предприятия. Представляете масштабы убытков?

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

Если же добавятся еще несколько документов, то файловый вариант накопит примерно 5 (!) часов простоя!

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

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

Поставим последний вопрос: насколько важна для предприятия скорость работы двух вариантов 1С? Файловый вариант в однопользовательском режиме опережает серверный в несколько раз, зато в многопользовательском проигрывает в сотни раз. Преимущество явно не в пользу файлового. Далее поговорим о надежности защиты данных, обеспечении стабильной работы и исключении возможности сбоя. Естественно, мы понимаем, что и здесь в выигрыше остается клиент-серверный вариант. Рассмотрим это преимущество на конкретном примере. Если случайно произойдет отключение электричества, в файловом варианте данные могут остаться лишь частично, в то время как серверный вариант обеспечит целостность всех данных.

Сделаем вывод: файловый вариант проигрывает серверному не только в скорости (чем больше пользователей, тем больше время простоя и, соответственно, больше убытки), но в обеспечении сохранности данных.

Если понятно, что использование серверного варианта значительно выгоднее файлового, то почему с завидной периодичностью появляются вопросы на форумах о скорости этих вариантов? Любой вопрос начинается с проблемы, проблема невысокой скорости в серверном варианте беспокоит пользователя, и он начинает искать ее решение. Решение находится в файловом варианте, который, по мнению то же пользователя, работает быстрее. Но пользователь не принимает во внимание, что проблема вовсе не в серверном варианте, а в «посреднике», которого нет в файловом.

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

По материалам http://infostart.ru/public/174086/

4d.by

Настройка Microsoft SQL Server для 1С

Шаг 0. Перед установкой и настройкой MS SQL 2005 желательно иметь 3 физических диска. Один - для системы, второй - для файлов баз и третий - для журналов транзакций SQL. При этом, раздел для логов SQL и tempdb желательно чтобы был более производительным (например RAID 1+0).

Шаг 1. Установка сервера MS SQL

При установке SQL-сервера для работы с 1С достаточно следующих включенных компонентов (более подробно о компонентах Microsoft SQL тут, об установке серера тут): На данном изображении: - Integration services - не обязательный элемент - необходим для управления пакетами SSIS (планами обслуживания (экспорт/импорт)), потом его можно будет отключить - Database Servises - собственно сам сервер СУБД - Client Component - Managment Tools - утилита управления

Остальные настройки при установке по Вашему вкусу. Единственный нюанс - необходимо правильно установить способ сортировки collate. Для автоматической и правильной работы необходимо в "Языке и региональных стандартах" операционной системы  выбрать "Русский". В этом случае при установке SQL Server сам предложит правильную сортировкуCyrillic_General_CI_AS. Выбор режима проверки подлинности пользователей укажите смешанный (mixed). Остальные параметры всегда можно скорректировать после установки - 1С:Предприятие будет работать независимо от них.

Более подробно об установке (ахтунг - English).

Желательно обновить сервер MS SQL до актуального релиза (на текущий момент - SP4 для 2005 SQL). Кроме того, на многопроцессорных системах сервер Microsoft SQL 2005 может отказаться устанавливаться с ошибкой 1053 (The error is (1053) The service did not respond to the start or control request in a timely fashion). Решение этой проблемы описано тут.

Шаг 2. Настройка сервера Microsoft SQL 2005

2.1. Настройка протоколов подключения

Для настройки протоколов взаимодействия сервера и клиента Microsoft SQL необходимо запустить "SQL Server Configuration Manager":

...и  оставить для работы только протоколы TCP/IP и Shared Memory:

Если устанавливается версия MS SQL Express по-умолчанию выключен протокол TCP/IP, нужный для работы с 1С:Предприятие 8 - его необходимо включить. Протокол именнованных каналов (Named Pipe) выключите совсем (и для "клиента" тоже на сервере приложений).

2.2. Перенос tempdb на быстрый независимый массив/диски

Для переноса tempdb необходимо запустить  sql-скрипт примерно следующего содержания:

USE master GO ALTER DATABASE tempdb modify file (NAME=tempdev, FILENAME='E:\Temp\tempdb_data.mdf') GO ALTER DATABASE tempdb modify file (NAME=templog, FILENAME='E:\Temp\tempdb_log.ldf') GO

где, E:\Temp\ - каталог, в котором будут лежать tempdb, а tempdb_data.mdf и tempdb_log.ldf имя файла базы данных и лога соответственно.

2.3. Настройка параметров сервера SQL

Для настройки сервера запускаем "SQL Server Management Studio", подключаемся к установленному серверу Database Engine'ом и открываем свойства (Server Properties). Тут нам нужно настроить 3 пункта:

Память (Memory)

Параметр "Maximum server memory (in MB)" задает максимально отведенное серверу количество памяти из расчета: [Общее количество оперативной памяти сервера] – [3ГБ под систему(1,5ГБ если Win2k3)] – [сколько_нужно ГБ * количество процессов работающих на данном сервере (если SQL еще какой-то важный сервис крутится на этом же сервере)]. Например, если у нас на сервере всего 24 ГБ оперативной памяти, стоит Windows 2003 и запущен сервер 1С Предприятия с 2мя процессами rphost (которым нужна память хотябы по 1,5Гб) то рассчет будет следующим: 24 - 1,5 - 1,5*2 = 19,5 ГБ ставит параметр "Maximum server memory (in MB)". Это необходимо для того, чтобы sql-сервер рассчитывал на заданный объем и освобождал память заблаговременно, т.к. если поставить неограниченный объем, и сервер попробует получить память, которой нет, он начинает лезть в файл подкачки, что сильно замедлит работу.

Процессоры (Processors)

Максимальное количество потоков (Maximum worker threads) стОит регулировать только при большом количестве клиентов (более 255) и для 1С это не актуально, поэтому оставим по-умолчанию. (хотя некоторые утверждают обратное  ).  Также выставляем галку повышенного приоритета сервера (Boost SQL Server priority).

Database Settings

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

2.4. Дополнительные "приседания"

Шаг 3. Настройка рабочих баз данных Ms SQL

Если база еще не развернута из .dt файла, и вы знаете примерный ее размер, то первичному файлу размер инициализации лучше сразу указать больший или равный размеру базы, но это дело вкуса, он все равно вырастет при развертке до нужных размеров. А вот Автоувеличение (Autogrowth) размера надо обязательно указать примерно по 200 МБ на базу и по 50 МБ на лог (можно увеличить/уменьшить, в зависимости от размера конечной базы и наличия места на диске), т.к. значения по умолчанию – рост по 1МБ и по 10% очень сильно тормозят работу сервера, когда ему при каждой 3й транзакции надо файл увеличивать. В этом же параметре можно ограничить размер файла лога, чтоб сильно не разростался, хотя это очень спорный параметр...

Остальные параметры можно оставить по умолчанию, за исключением некоторых:

Например, параметр AutoShrink советуют отключить, ибо он приводит к постоянным скачкам размера лога. Лучше его держать в узде с помощью Планов обслуживания (они жеРегламентные задания, они же Maintenance Plans).

Шаг 4. Настройка Планов обслуживания (Maintenance Plans, Регламентных заданий)

Для работы регламентных заданий необходимо создать план обслуживания:

Итак, приведу свой пример настроенного Maintenance Plans с комментариями. Мой план состоит из 5 подпланов:

Первый подплан (ежедневное еженочное обслуживание сервера и резервных копий):

 

Данный подплан состоит из нескольких шагов. Связи зеленого цвета задают переход к следующему заданию при удачном завершении (т.е. без ошибок), связи синего цвета задают переход к следующему заданию при любом результате выполнения текущего. Параметры шагов видны на размещенных в редакторе заданиях. Параметры некоторых заданий нужно описать отдельно. Первым шагом выполняется "Проверка целостности базы данных" (Check Database Integrity Task), которая выполняется для всех баз системы и следующие задания выполняются только при отсутствии ошибок при проверке баз. Следующим шагом выполняется "Перестроение индексов баз данных" (Rebuild Index Task) для всех баз данных сервера. Данная процедура довольно ресурсоемкая, но в последствии ускоряет работу базы, т.к. если фрагментированость индексов > 25%, это резко снижает производительность сервера. Если размер баз не позволяет выполнять данную задачу, т.к. она занимает много времени, то рекомендуется делать данное действие хотябы раз в неделю, при этом, на ночные задания заменить задачу Перестроение индексов баз данных (Rebuild Index Task) на Дефрагментацию индекса (Reorganize Index Task), которая менее  ресурсоемка. Далее происходит "Обновление статистики базы данных" (Update Statistics Task) для всех баз данных, опять же для оптимизации. После этого задания рекомендуется выполнить "Очистку процедурного кэша":

При этом, запускается процедура DBCC FREEPROCCACHE

После оптимизации работы желательно сделать резервную копию журналов транзакций. Этот шаг делать не обязательно, но желательно.  Во время выполнения предыдущих шагов (Перестроение индексов баз данных (Rebuild Index Task) и Обновление статистики базы данных (Update Statistics Task)) файлы журналов вырастают примерно до размера базы данных, а то и более. В результате, в следующих подпланах при выполнении первого резервного копирования журнала транзакций, размер копии имеет довольно большой объем. Это может сильно увеличить вермя восстановления базы. Таким образом, делая копию логов до полной копии, мы избавляемся от данной проблемы. (спасибо за идею комментатору Kyoshiro)

Далее можно выполнить полный бэкап заданием Создание резервной копии базы данных (Back Up Database Task):

При выполнении данного задания копии складываются в сетевую папку на файловом сервере с расширением bak, при этом, для каждой базы создается своя папка: SAMBA ~ # ls -1 /backup/full/ database1 database2 ... SAMBA ~ # ls -1 /backup/full/satabase1/ database1_backup_201111210250.bak database1_backup_201111220251.bak ...

После заверешения создания резервной копии параллельно запускается 3 задания: очистка резервных копий журналов транзакция (о создании таких копий - ниже) старее 5 дней,очистка полных бэкапов старее 1 недели и очистка истории старше 1 месяца (сюда входит в основном - очистка служебной информации MS SQL, такой как журналы):

Данный подплан у меня запускается каждую ночь в нерабочее время по будням:

Второй, третий, четвертый подплан (обновление статистики 3 раза в день):

Следующие 3 подплана одинаковы по содержимому и различаются лишь временем выполнения. Выполняются 3 раза в день - в 6, 13 и 19 часов:

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

Пятый подплан (резервное копирование журнала транзакций):

Данный план выполняет инкрементальное копирование транзакционного лога Microsoft SQL Server:

Копирование выполняется каждые пол часа в рабочее время и сохраняется в сеть с расширением trn:

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

notanet.blogspot.com

Обслуживание SQL базы данных 1С

Общие сведения

Одной из часто встречающихся причин не оптимальной работы системы является неправильное или несвоевременное выполнение регламентных операций на уровне СУБД. Особенно важно выполнять эти регламентные процедуры в крупных информационных системах, которые работают под значительной нагрузкой и обслуживают одновременно большое количество пользователей. Специфика таких систем в том, что обычных действий, выполняемых СУБД автоматически (на основании настроек) оказывает недостаточно для эффективной работы.

Если в работающей системе наблюдаются какие-либо симптомы проблем с производительностью, следует проверить, что в системе правильно настроены и регулярно выполняются все рекомендуемые регламентные операции на уровне СУБД.

Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства 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 запрос:

exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN' Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.

Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день.

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

Настройка автоматического обновления статистик (MS SQL 2005)

Запустите MS SQL Server Management Studio и подключитесь к серверу СУБД. Откройте папку Management и создайте новый план обслуживания:

Создайте субплан (Add Sublan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач: Настройте расписание обновления статистик. Рекомендуется обновлять статистики не реже одного раза в день. При необходимости частота обновления статистик может быть увеличена.

Настройте параметры задачи. Для этого следует два раза кликнуть на задачу в правом нижнем углу окна. В появившейся форме укажите имя базу данных (или несколько баз данных) для которых будет выполняться обновление статистик. Кроме этого вы можете указать для каких таблиц обновлять статистики (если точно неизвестно, какие таблицы требуется указать, то устанавливайте значение All).

Обновление статистик необходимо проводить с включенной опцией Full Scan.

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

Очистка процедурного КЭШа

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

Возможна ситуация, при которой MS SQL Server, ориентируясь на устаревшую статистическую информацию, построит неоптимальный план запроса. Этот план будет сохранен в процедурном КЭШе и использован при повторном вызове такого же запроса. Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план.

Таким образом, рекомендуется всегда после обновления статистик очищать содержимое процедурного КЭШа.

Для очистки процедурного КЭШа MS SQL Server необходимо выполнить следующий SQL запрос: DBCC FREEPROCCACHE

Этот запрос следует выполнять непосредственно после обновления статистики. Соответственно, частота его выполнения должна совпадать с частотой обновления статистики.

Настройка очистки процедурного КЭШа (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»:

Откроется окно с протоколом выполнения всех заданных регламентных процедур.

dkrichun.blogspot.com

Методы повышения производительности 1C на MS SQL

Ниже я рассмотрю основные методы повышения производительности ИС на платформе 1С 8.3, работающего в клиент-серверном режиме работы.

Методы оптимизации производительности 1C 8.3 в связке с MS SQL

  1. настройка регламентных операций СУБД
  2. анализ загруженности оборудования
  3. мониторинг производительности системы

Настройка регламентных операций СУБД  — MS SQL

Это очень важный пункт, не требующий привлечения ресурсов. Причем дает эффект, зачастую, очень большой. Ранее я рассказывал подробнее о регламентных операциях СУБД  — MS SQL.

Анализ загруженности оборудования

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

Получите 267 видеоуроков по 1С бесплатно:

Если по результатам замеров оборудование большинство времени находится в состоянии перегруженности — необходимо всерьез задуматься о аппаратном апгрейде.

Мониторинг производительности системы

Этот способ является более прогрессивным и интересным. Он позволяет найти узкие места конфигурации и СУБД MS SQL и получить инструкции по исправлению ситуации. Правильнее всего, для этой задачи использовать программный продукт — Центр Управление Производительностью (ЦУП).

С помощью этой утилиты рекомендуется произвести замер следующих параметров:

Полученные данные смогут вам о многом рассказать. Можно 100% говорить о неполадках в системе по части производительности, если выделяются следующие симптомы:

  1. показатели — «количество взаимоблокировок» и «количество таймаутов»  не равно нулю
  2. с течением времени значительно увеличивается показатель «максимальное T выполнения запроса»
  3. если «среднее T ожидания на блокировке СУБД» составляет от 50% процентов и более от показателя «среднее T выполнения запроса»
  4. периодические резкие изменения показателей «среднее T выполнения запроса», «среднее T ожидания на блокировке СУБД», «среднее T ожидания на блокировке 1С».

Если вы выявили в системе хоть один из вышеупомянутых симптомах, вам необходимо произвести анализ проблем производительности конфигурации и СУБД MS SQL.

Анализ проблем производительности и оптимизация системы

Для данной задачи так же нужно продолжить пользоваться программой 1С Центр Управление Производительностью (ЦУП).

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

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

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

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

programmist1s.ru


Prostoy-Site | Все права защищены © 2018 | Карта сайта