FREEPROCCACHE

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

http://technet.microsoft.com/ru-ru/library/ms174283.aspx

Удаляет все элементы из кэша планов, удаляет заданный план из кэша планов с помощью указания дескриптора плана или дескриптора SQL либо удаляет все записи кэша, связанные с указанным пулом ресурсов.

Инструкция DBCC FREEPROCCACHE используется для аккуратной очистки кэша планов. Освобождение кэша планов приводит, например, к тому, что хранимая процедура повторно компилируется, а не используется из кэша. Это может стать причиной внезапного временного снижения производительности обработки запросов. В SQL Server для каждого очищенного хранилища кэша в кэше планов журнал ошибок содержит следующее информационное сообщение: «SQL Server обнаружил %d экземпляров, записанных на диск хранилищ кэша для хранилища кэша %s (части кэша планов) в результате операций DBCC FREEPROCCACHE или DBCC FREESYSTEMCACHE». Это сообщение добавляется в журнал каждые пять минут при сбросе кэша в течение этого интервала времени.

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

Иногда возникает необходимость очистить кэш для определенной БД. Когда полностью очиненный кэш сделанный по необходимости для одной БД, может повлиять на производительность остальных работающий в одном экземпляре SQL. Есть недокументированная команда по очистки КЭШа БД. Насколько она безопасна, решать каждому ее использовавшему:

1. select name, database_id from sys.databases
// получаем идентификатор нужной БД.

2. DBCC FLUSHPROCINDB(<database_id>)
// очищаем кэш по id БД.

 

 

BIOS: Processor C-states / All C-states

Cisco рекомендует для профиля электропитания High-Performance Computing для параметра All C-states установить значение enabled (и в этом профиле так и установлено), но для максимальной производительности параметр нужно не включать, а выключать disabled, а для этого настраивать свой план электропитания Custom.

BIOS: Collaborative Power Control

для биоса HPE параметр Collaborative Power Control отвечает за тем кто будет управлять понижением частот, биос или операционная система. Если этот параметр доступен для выбора, значит у вас стоит не лучшее значение другого параметра HP Power Regulator и необходимо исправить его , а здесь выключить.

 

BIOS: Minimum Processor Idle Power Package State

У BIOS HPE параметру Minimum Processor Idle Power Package State установите значение No Package State. Смысл настройки похож на http://www.gilev.ru/bios-minimum-processor-idle-power-core-state/ лишь с тем отличием что здесь идет настройка не для отдельных ядер процессора а целиком для процессора.

BIOS: Minimum Processor Idle Power Core State

У BIOS HPE параметру Minimum Processor Idle Power Core State установите значение No C-states . Это выключает энергосберегающие состояния, понижающие частоту процессора.

 

BIOS: Intel QPI Link Power Management

Для биос HPE у параметра Intel QPI Link Power Management ставьте значение Disabled для максимальной производительности 1С-систем.
QPI , он же Intel QuickPath Interconnect  —  последовательная кэш-когерентная шина типа точка-точка разработанная фирмой Intel для соединения процессоров в многопроцессорных системах и для передачи данных между процессором и чипсетом. Например внутри процессора LGA 1156 связь между ядрами и встроенным контроллером PCIe осуществляется через данную встроенную шину. Параметр биоса управляет управляет понижением электроснабжения шины. Если верить документации https://techlibrary.hpe.com/docs/iss/proliant_uefi/UEFI_Gen9_121417/s_Intel_QPI_LP.html то данный параметр хоть влияет на скорость, но не сильно.

BIOS: Override OS Energy Performance

Override OS Energy Performance — отмена влияние настроек ОС на энергосбережние

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

BIOS: Software Controlled T-States

Параметру “Software Controlled T-States” присвоить значение “Disable” чтобы выключить управляемый программно тротлинг (пропуск тактов) для производительности 1С-систем

 

BIOS: Energy Efficient Turbo

Energy Efficient Turbo во включенном состоянии означает, что электричество будет экономиться.

Для производительности 1С-систем выключайте этот параметр (Disable)

BIOS: ENERGY_PERF_BIAS_CFG

Параметру “ENERGY_PERF_BIAS_CFG” присвоить значение “Maximum Performance” для максимальной производительности 1С-систем

в более ранних версиях также может встречаться параметр Energy Performance

укажите значение Perfomance для производительности 1С-систем

BIOS: Intel SpeedStep (IST)

Старый режим энергосбережения процессора, предшествовавший Enhanced Intel SpeedStep Technology.

Intel SpeedStep

Для максимальной производительности 1С-систем выключайте этот режим, выберите значение Disable, а если его нет, то  Maximum.

В отключенном режиме частота меняться не будет.

BIOS: Turbo Boost

Turbo Boost — это технология компании Intel для автоматического увеличения тактовой частоты процессора свыше номинальной, если при этом не превышаются ограничения мощности, температуры и тока в составе расчётной мощности (TDP). Это приводит к увеличению производительности однопоточных и многопоточных приложений. Фактически, это технология «саморазгона» процессора. Есть турбобуст 2 и 3й версии.

Параметр может называть также Turbo Mode (одно и тоже).

или Turbo Boost Tehnology.

Для производительной работы 1С-систем его надо включать обязательно (Enabled).

В биосе для HPE для параметра Intel(R) Turbo Boost Technology выбирайте значение Optimized for Performance

BIOS: Package C State

Может также встречаться Package C State Limit или Package C State Support

Возможные варианты значений:
Auto — Значение выбрано автоматически.
Enabled — Параметр включен.
C0/C1 — Поддержка C0/C1 состояний пакета.
C2 — Поддержка C2 состояния пакета.
C3 — Поддержка C3 состояния пакета.
C6 — Поддержка C6 состояния пакета.

Для производительной работы 1С-систем выбирайте режим C0/C1 .

Таким образом для всех ядер процессора вы задаете общий режим работы (парковки ядер). В выбранном режим падения частоты процессора не происходит.

BIOS: CPU C6 Report

CPU CReport — позволяет запретить (параметр [Disabled]) / разрешить (параметр [Enabled]) переход процессора в энергосберегающее состояние C6 (когда в состоянии C3 значения регистров записываются в постоянную память). В таком режиме CPU функционирует при очень незначительном напряжении питания, достаточном лишь для выхода его из этого состояния. При этом минимальная нагрузка на линию +12В может опускаться до 0,5 А, поэтому блок питания должен поддерживать такую возможность (определено в спецификации ATX12V 2.3).

Важно отметить, что некоторые производители не отделяют этот режим от С3.

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

BIOS: CPU C3 Report

Состояние процессора С3 сбрасывает кэш и понижает частоту (и питание) процессора.

Тут надо пояснить, что ядра процессора могут иметь различные состояния.

позволяет запретить (параметр [Disabled]) / разрешить (параметр [Enabled]) переход процессора в энергосберегающее состояние C3 (когда частота опускается до 0 МГц, отключается кэш-память L1 и L2, но при этом сохраняются значения всех регистров). В таком режиме CPU функционирует при очень незначительном напряжении питания, которое требуется лишь для хранения данных из регистров.

Для повышения производительности 1С-систем рекомендуем выключать данный параметр (Disable).

BIOS: Enhanced Halt State (C1E) «Улучшенное состояние простоя»

C1E — одна из функций энергосбережения процессоров (называемого также Enhanced Halt State). Состояние C1E позволяет снизить напряжение при переводе процессора в состояние HALT, применяемое при низком уровне загрузки системы. При этом снижается уровень энергопотребления системы при низкой загрузке процессора. При этом снижается частота процессора (и вольтаж). Это в свою очередь негативно сказывается на скорости работы 1С-систем.

Рекомендуется выключать данный режим (в англоязычных настройках Disable).

Другие варианты обозначения данного параметра:

C1E

вспомогательные файлы 1С

  • def.usr — хранится в каталоге <Данные приложений пользователя>/1C/1Cv8/<Идентификатор информационной базы> (например, C:/Documents and Settings/User/Application Data/1C/1cv82/4129dbdb-b495-41cb-99ea-ef315060a03e/def.usr) и содержит имя пользователя который последним открывал данную информационную базу.
  • ibases.v8i — хранится в каталоге <Данные приложений пользователя>/1C/1CEStart (например, C:\Documents and Settings\user\Application Data\1C\1CEStart\ibases.v8i) и содержит список информационных баз, зарегистрированных на данном клиентском компьютере. Этот список отображается в диалоге «Запуск 1С:Предприятия».
  • GenTempl_ru.st, GenTempl_en.st  — стандартный файл шаблонов текста расположен в каталоге загрузочных модулей 1С:Предприятия (например C:/Program Files/1cv82/bin) на русском и английском языке соответсвенно.
  • appsrvrs.lst — хранится в каталоге <Данные приложений пользователя>/1C/1cv82 (например, C:/Documents and Settings/User/Local Settings/Application Data/1C/1cv82/appsrvrs.lst) и содержит список серверов 1С:Предприятия, зарегистрированных в утилите администрирования информационных баз в варианте клиент-сервер.
  • srvribrg.lst —  хранится на центральном сервере кластера в каталоге <рабочий каталог центрального сервера> (например, C:/Program Files/1cv82/server/srvribrg.lst) и содержит список кластеров, зарегистрированных на данном компьютере сервера 1С:Предприятия. Содержащиеся в нем данные необходимы для нормальной работы приложений, использующих данный сервер 1С:Предприятия.
  • 1CV8Reg.lst — файл настройки кластера( например C:\Program Files\1cv82\srvinfo\reg_1541\1CV8Reg.lst)
  • В каталогах DBNameCacheConfigSaveConfigSICache хранится множество файлов, кеширующих различные компоненты конфигурации. Эта информация является производной от конфигурации информационной базы, хранимой в базе данных, и служит для ускорения запуска клиентских приложений и повышения их производительности. Кеш конфигурации располагается в каталоге данных приложений текущего пользователя, например, C:/Documents and Settings/User/Local Settings/Application Data/1C/1cv82/7b0a6294-d6a3-41c5-a23e-dc9e5301ad22/DBNameCache.
  • В каталоге 1Cv8FTxt хранятся данные, используемые службой полнотекстового поиска. Они располагаются на компьютере центрального сервера 1С:Предприятия в каталоге <рабочий каталог кластера>/<идентификатор информационной базы>. Например: C:/Program Files/1cv82/server/reg_1541/7eac7609-c0cb-4701-83cf-9ff5f8961de8/1Cv8FTxt.
  • Группа файлов CACHE/ddb<n>.snp хранится в каталоге хранилища конфигурации и служит для кэширования запрошенных версий конфигурации из этого хранилища. Наличие этих файлов не является обязательным и позволяет ускорить получение версий конфигурации.
  • *.1ccr — конфигурационный файл Web-сервиса для работы с удаленным хранилищем может иметь произвольное имя (расширение 1ccr обязательно), формат XML и содержит единственный узел с произвольным именем и атрибутом connectString — в этом атрибуте указывается адрес сервера хранилища в схеме tcp.
  • *.mft — файл с расширение mft является файлом-манифестом — специальным файлом, описывающим шаблон конфигурации. Файл может иметь произвольное имя. Файл располагается в каталоге установленного шаблона конфигурации.
  • *.v8i — в данном файле приводится описание формата файла описаний зарегистрированных информационных баз. Данный список используют все клиенты. Файл располагается на локальном компьютере в каталоге %APPDATA%\1C\1CEStart\ и по умолчанию имеет имя ibases.v8i.
  • 1CESCmn.cfg — файл 1CESCmn.cfg содержит общие настройки программ запуска (1CEStart.exe и 1Cv8s.exe).
  • 1CEStart.cfg — файл 1CEStart.cfg содержит настройки, которые используют программы запуска (1CEStart.exe и 1Cv8s.exe) и клиентские приложения (1Cv8.exe и 1Cv8c.exe). Файл расположен в каталоге %APPDATA%\1C\1CEStart.
  • adminstall.cfg — файл adminstall.cfg указывает на то, что установка системы программ «1С:Предприятие» выполнялась с использованием средств администрирования операционной системы. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие» и представляет собой текстовый документ в кодировке UTF-8.
  • comcntrcfg.xml — файл comcntrcfg.xml служит для указания внешнему соединению необходимости запуска в отладочном режиме.
  • Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • conf.cfg — файл conf.cfg определяет расположение каталога общих конфигурационных файлов. Файл расположен в каталоге bin\conf каталога конкретной версии «1С:Предприятия» и представляет собой текстовый документ в кодировке UTF-8.
  • debugcfg.xml — файл debugcfg.xml предназначен для настройки дополнительного диапазона портов, используемого при отладке конфигураций. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • def.usr — файл хранится в каталоге %APPDATA%\1C\1Cv82\<Уникальный идентификатор информационной базы> и содержит имя пользователя который последним открывал данную информационную базу.
  • default.vrd — данный файл служит для настройки веб-клиента и использования Web-сервисов, и находится в каталоге виртуального приложения.
  • inetcfg.xml — файл inetcfg.xml позволяет задавать настройки прокси по умолчанию и имеет больший приоритет над настройками прокси по умолчанию в Windows. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • logcfg.xml — файл logcfg.xml служит для настройки технологического журнала. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • logui.txt — располагается в каталоге %APPDATA%\1C\1Cv82\<Уникальный идентификатор информационной базы> и содержит список интерактивных действий пользователя, которые выполнялись за время журналирования.
  • nethasp.ini — для настройки параметров взаимодействия системы «1С:Предприятие» с HASP License Manager используется конфигурационный файл nethasp.ini. Файл располагается в каталоге конфигурационных файлов системы «1С:Предприятие», и его наличие не является обязательным.
  • nhsrv.ini — некоторые настройки HASP License Manager могут задаваться при помощи файла конфигурации nhsrv.ini. При запуске HASP License Manager осуществляет поиск конфигурационного файла nhsrv.ini в различных каталогах в следующей последовательности:
    • каталог, в котором размещается исполняемый файл HASP License Manager;
    • текущий каталог Windows;
    • системный каталог Microsoft Windows (%SystemRoot%\system32 — для 32-разрядной версии и %SystemRoot%\system — для 64-разрядной версии);
    • каталог Microsoft Windows;
    • каталоги, перечисленные в переменной окружения PATH (только в случае установки HASP License Manager как приложения Microsoft Windows).

Рекомендуется размещать файл nhsrv.ini, если это необходимо, в каталоге, в котором размещается исполняемый файл HASP License Manager. Проверка того, что HASP License Manager нашел и прочитал файл конфигурации, можно с помощью журнала Activity Log/Server Activity Log.

  • srv1cv82 — конфигурационный файл /etc/sysconfig/srv1cv82 используется для задания параметров запуска агента сервера «1С:Предприятие» с помощью скрипта /etc/init.d/srv1cv82. Данный конфигурационный файл используется в случае запуска сервера «1С:Предприятия» в операционной системе Linux.
  • swpuser.ini — для того чтобы рабочий процесс запускался не от имени того же пользователя, что и агент сервера, в каталоге данных приложений, относящемся к пользователю агента сервера, может быть размещен файл swpuser.ini
  • *.lic — лицензии базовых конфигураций (C:\Documents and Settings\All Users\Application Data\1C\licenses)

Подключение сервером 1С к PostgreSQL на нестандартном порту

Для подключения по нестандартному порту PostgreSQL в консоли администрирования серверов 1С:Предприятия в параметрах информационной базы в поле «Сервер баз данных» нужно написать строку в следующем формате:

hostname port=5433

Зачем аппаратному RAID-контроллеру нужна батарейка?

Зачем аппаратному RAID-контроллеру нужна батарейка?

Многим достаточно информации, что батарейка RAID контроллера ( от англ. Battery Back-Up Unit или BBU) нужна для того, чтобы при аварийном отключении электроэнергии данные из кэша контроллера не были утеряны, а были записаны на RAID-массив.

Обращаем ваше внимание, что наличие батарейки позволяет RAID-массиву работать в режиме Write Back (отложенная запись). Этот режим является оптимальным при записи информации на диск в случае наличия BBU на RAID контроллере.

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

Контроллер принудительно выключит режим WriteBack и включит режим Write Through (сквозная запись) при любом из следующих событий:
— отсутствие BBU;
— низкий уровень заряда BBU («батарейка села»);
— для некоторых контроллеров, у которых режим WriteBack платный и истек срок trial лицензии.

В том случае, когда выбран режим Write Through, подтверждение о записи информации поступит только после того, как данные будут записаны. Таким образом, режим Write Through замедляет работу системы, но гарантирует запись данных. Если же в сервере установлен контроллер с Battery Back-Up модулем и кэш-памятью, то оптимально использовать режима Write Back.

Пример разницы производительности RAID-массива (RAID5 из шести дисков Intel S3610, контроллер LSI MegaRAID SAS 9361-8i) при использовании режима WriteBack.
Примечание. Важно понимать, попадают ли используемые данные в кэш, или нет, от этого сильно зависит результат теста.

Результат теста RAID массива с выключенным режимом WriteBack (работает Write Through):

Результат теста того же RAID массива с включенным режимом WriteBack:

Подробно о тесте — http://www.gilev.ru/crystaldiskmark/ .

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

P.S. Мы не рекомендуем размещать базы данных 1С на дисках Intel S3610.

 

 

 

Обновление статистики базы данных

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

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

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

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

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

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

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

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

Например, в период минимальной нагрузки на систему — в ночные часы.

Можно сделать, например, так: В MS SQL:

1) Создайте новый план обслуживания

2) Создайте субплан (Add Subplan) и назовите его «Обновление статистик».

3) Добавьте в него задачу Update Statistics Task из панели задач:

4) Настройте расписание обновления статистик (рекомендация не реже 1 раза в день).

5) Настройте саму задачу:

5.1) Базу данных для который выполняется обновление статистики

5.2) Список таблиц установите «All» — это означает что будет обновлена статистика по всем таблицам БД

5.3) Укажите опцию Full scan

(Примечание. Такой режим будет эквивалентен скрипту

exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
DBCC UPDATEUSAGE (dbname)

где dname имя вашей базы)

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

Поэтому в субплан:

6) Добавьте задачу Execute T-SQL Statement Task.

7) Соедините задачу Update Statistics Task стрелочкой с новой задачей

8) В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»

9) если у вас значительная нагрузка на базу в пиковые моменты (сотни пользователей, роботы-фоновики и т.п.) то наряду с параметром «Автоматическое создание статистики (AUTO_CREATE_STATISTICS)» будет полезно также для базы данных включить параметр «Автоматическое асинхронное обновление статистики (AUTO_UPDATE_STATISTICS_ASYNC)»

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

Если используется версия до SQL Server 2014 (12.x), SQL Server применяет пороговое значение в зависимости от процента измененных строк. Это значение не зависит от числа строк в таблице. Пороговое значение:
Если на момент оценки статистических данных кратность в таблице не превышала 500, обновление выполняется для каждых 500 модификаций.
Если на момент оценки статистических данных кратность в таблице превышала 500, обновление выполняется для каждых 500 + 20 % модификаций

Начиная с версии SQL Server 2016 (13.x) и при уровне совместимости базы данных 130 SQL Server используется пороговое значение для динамического обновления статистических данных по убыванию. Значение изменяется в зависимости от числа строк в таблице. Оно вычисляется как квадратный корень из произведения текущего значения кратности в таблице и 1000. Например, если таблица содержит 2 миллиона строк, значение вычисляется как квадратный корень из (1000 * 2000000) = 44721,359. Благодаря этому изменению статистика для больших таблиц будет обновляться чаще. Но если уровень совместимости для базы данных ниже 130, применяется пороговое значение SQL Server 2014 (12.x).

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

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

Особенности 8.3.13

Реализована поддержка СУБД PostgreSQL версии 10. (смотрите также https://postgrespro.ru/blog/news/3876555?fbclid=IwAR0ivfJaOBWJ7p7IDK4-nAdS3cBmHmtgV6aEcdsA9fB_T8_CkDkWPhdwK1w)

Оптимизация работы с PostgreSQL
Оптимизирована работа виртуальных таблиц оборотов регистров накопления и бухгалтерии в случае использования группировок по дню, месяцу или году, а также при использовании функции языка запросов НачалоПериода(). Оптимизация используется для любых версий поддерживаемых СУБД, кроме Microsoft SQL Server, где оптимизация действует, начиная с версии 2012.

 

Добавлен механизм контроля потребления ресурсов. Смотрите https://wonderland.v8.1c.ru/blog/mekhanizm-upravleniya-potrebleniem-resursov/

факты превышения счетчика фиксируются в технологическом журнале (событие <ATTN>)

Реализована возможность оценивать использование процессора за время работы сеанса:

  • за текущий серверный вызов;
  • за последние 5 минут;
  • за все время работы сеанса.

Для события <CALL> реализовано свойство CpuTime, которое содержит длительность завершившегося серверного вызова, в микросекундах.

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

Новые конструкции запросов. Реализована возможность создания поля с уникальными (в рамках одной таблицы), последовательно возрастающими значениями. Реализована функция языка запросов АВТОНОМЕРЗАПИСИ(), которая может быть использована только при создании временной таблицы.Не поддерживается использование функции АВТОНОМЕРЗАПИСИ():
  • в запросах, содержащих ОБЪЕДИНИТЬ на верхнем уровне;
  • в запросах, не формирующих временную таблицу;
  • вне списка выборки;
  • в выражениях.

Реализован объект КонстантаКлючЗначения.Для менеджера константы реализованы методы СоздатьКлючЗначения()Новый формат временных файлов будет использоваться после отключения режима совместимости. В режиме совместимости с версией 8.3.12 поведение не изменилось.

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

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

Фоновики.
Реализована возможность ожидать завершение работы одного или нескольких фоновых заданий в течение заданного промежутка времени. Реализован метод 
ОжидатьЗавершенияВыполнения() для объектов ФоновоеЗадание и МенеджерФоновыхЗаданийМетод ОжидатьЗавершения() считается устаревшим и не рекомендуется к использованию. Рекомендуется выполнить анализ прикладного решения и изменить алгоритмы работы с фоновыми заданиями.
Оптимизирован запуск и ожидание завершения фоновых заданий

 

Старт клиента.
Реализована возможность отключать отображение заставки при старте клиентского приложения. Реализован параметр командной строки запуска клиентского приложения DisableSplash. Параметр доступен для тонкого клиента, толстого клиента и веб-клиента.

Оптимизирована и ускорена отрисовка заголовков страниц (закладок) при работе в веб-клиенте.

Обновление используемых библиотек

  • Библиотека LibEtPan обновлена до версии 1.8.
  • Библиотека WebSocket обновлена до версии 0.7.0.
  • Драйвер Micosoft JDBC Driver for SQL Server обновлен до версии 6.2.
Маки.
Реализовано событие технологического журнала <MACCERT>.


Особенности работы платформы с сеансовыми данными

За работу с сеансовыми данными отвечает менеджер кластера – rmngr.exe Если в кластере несколько рабочих серверов, то сеансовые данные будут расположены в соответствии с требованиями назначения функциональности.

Если требования не заданы, то сеансовые данные распределятся равномерно по всем рабочим серверам.

Сеансовые данные растут блоками по 64 Мб. Когда заканчивается блок, то менеджер кластера выделяет следующий блок в 64Мб.Блоки большего объема возможны в результате помещения объемных данных во временные хранилища.

Для обеспечения скорости работы, платформа всегда пишет новые данные в конец, аналогично transaction log в СУБД. Таким образом, размер сеансовых данных постоянно растет. Во всем объеме сеансовых данных, существуют как актуальные, так и устаревшие данные. Актуальность данных определяется способом их помещения:

  • Если сеансовые данные помещены из формы и в качестве идентификатора передается идентификатор формы (ЭтаФорма.УникальныйИдентификатор), то данные считаются актуальными, пока открыта форма.
  • Если в качестве идентификатора передан УникальныйИдентификатор, не являющийся уникальным идентификатором формы (Новый УникальныйИдентификатор), то значение перестанет быть актуальным после завершения сеанса пользователя.
  • Если ничего не передано, то значение перестанет быть актуальным при любом следующем серверном вызове.

Перед выделением следующего блока на диске, проверяется, прошло ли 5 секунд с момента выделения предыдущего блока. Если 5 секунд прошло, то запускается «сборщик мусора» (key value garbage collector). Сборщик оценивает процент актуальных сеансовых данных в общем объеме. Если актуальные данные занимают менее 25% от общего объема, то все актуальные данные копируются в новые файлы, а затем все старые.

Так как каждый сеанс (клиенты, фоновые задания, web-сервисы) в своей работе постоянно пишет информацию в сеансовые данные, то при большом количестве пользователей, скорость дисковой подсистемы, на которой расположены файлы сеансовых данных, играет очень важную роль. При большом количестве пользователей, рекомендуется располагать файлы сеансовых данных на максимально быстрых дисках. Желательно RAM-drive. Отказоустойчивость дисков не важна, т.к. при потере сеансовых данных, никакой важной информации утеряно не будет.

Следует отметить порядок размещения сеансовых данных. Если поместить во временное хранилище двоичные данные или файл, то эти данные пройдут в качестве потока байт через rphost, затем в rmngr, который сбросит этот поток на диск. Если же, в качестве помещаемого значения,  будет выступать коллекция (таблица значений, результат запроса, массив…), то сначала вся эта коллекция разместиться в памяти rphost, а только затем преобразуется в поток байт и будет передана в rmngr.

сеансовые данные 1С

Сеансовый кэш (по правильному — «сеансовые данные») как правило находится в расположении C:\Program Files\1cv8\srvinfo\reg_1541\snccntx + уникальный идентификатор. В этой папке (название папки может быть наподобие такого: snccntx23a3c417-bab8-43a5-9df9-8ba437f4523c) лежат файлы вида: snccntx.000057F1.dat . Это и есть сеансовые данные.

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

При вызове методов: ПоместитьВоВременноеХранилище, ПоместитьФайл, НачатьПомещениеФайла, значения указанные в параметрах, записываются в сеансовые данные.

При фоновом исполнении отчетов СКД, результат отчета помещается в сеансовые данные, а затем передается в клиентскую часть.

Сам файл *.dat является местом хранения  noSQL база данных (key-value storage).

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

Примечание. Путь кластера сервера 1С (C:\Program Files\1cv8\srvinfo\) может быть переопредлён ключом -D при запуске службы.

Подкаталог reg_1541 соответствует конкретному кластеру, совпадая в наименовании по номеру порта кластера. Если у вас несколько кластеров, или они расположены по нестандартным портам, то учитывайте это, просматривая соответствующие reg_… каталоги.

Рестарт службы сервера 1С с очисткой временных файлов

Пример скрипта рестарта службы сервера 1С с очисткой временных файлов.

set LOG_FILE="scripts.log"
set SERVICE_1C_NAME="1C:Enterprise 8.3 Server Agent (x86-64)"
set SERVICE_RAS_NAME="1C:Enterprise 8.3 Remote Server"
set CNTX_PATH="C:\srvinfo\reg_1541"
set PFL_PATH="C:\ProgramData\1C\1cv8"
set TEMP_PATH="%TEMP%"
echo %DATE% %TIME% stop service %SERVICE_1C_NAME% >> "%~dp0"%LOG_FILE%
sc stop %SERVICE_1C_NAME%
sc stop %SERVICE_RAS_NAME%
timeout 5
taskkill /f /im "rphost.exe"
taskkill /f /im "rmngr.exe"
taskkill /f /im "ragent.exe"
taskkill /f /im "ras.exe"
timeout 5
echo %DATE% %TIME% done stop service %SERVICE_1C_NAME% >> "%~dp0"%LOG_FILE%
echo %DATE% %TIME% start clean temp >> "%~dp0"%LOG_FILE%
DEL /Q /F /S %CNTX_PATH%\snccntx*
DEL /Q /F %PFL_PATH%\*.pfl
DEL /Q /F /S %TEMP_PATH%\*.*
echo %DATE% %TIME% done clean temp >> "%~dp0"%LOG_FILE%
echo %DATE% %TIME% start service %SERVICE_1C_NAME% >> "%~dp0"%LOG_FILE%
sc start %SERVICE_1C_NAME%
sc start %SERVICE_ RAS _NAME%
echo %DATE% %TIME% service %SERVICE_1C_NAME% restarted >> "%~dp0"%LOG_FILE%

Чтобы правильно определилась переменная %TEMP%, скрипт необходимо запускать от имени пользователя, под которым работает служба сервера 1С.

Перенос данных на рам-диск (или более быстрый диск)

1. Перенос кеша пользователя.

Для переноса кеша требуется выполнить 3 команды:

1. Удаление папки с кешем (по умолчанию: %USERPROFILE%\AppData\Roaming\1C\1Cv82) — для 8.2
%USERPROFILE%\AppData\Local\1C\1cv8 — для 8.3

rd /s /q «<Путь к папке на жестком диске>»

2. Создание папки на RAM диске:

mkdir «<Путь к папке на RAM диске>»

3. Создание символьной ссылки на папку RAM диска:

mklink /j «<Путь к папке на жестком диске>» «<Путь к папке на RAM диске>»

Данную процедуру нужно проделать для каждого пользователя. Проще всего написать батник вида:


mkdir B:\Users\1c\user1

rd /s /q «C:\Users\user1\AppData\Roaming\1C\1Cv82»
rd /s /q «C:\Users\user1\AppData\Local\1C\1cv8»

mklink /j «C:\Users\user1\AppData\Roaming\1C\1Cv82» «B:\Users\1c\user1»
mklink /j «C:\Users\user1\AppData\Roaming\1C\1cv8» «B:\Users\1c\user1»


Следует понимать что содержимое RAM диска находится в оперативной памяти и исчезает при выключении\перезагрузке сервера. Не обнаружив папку на диске B 1с выдаст ошибку: «Ошибка при выполнении файловой операции ‘<Путь к папке с кешем>'» и работать не будет. Поэтому при загрузке сервера каждый аз нужно выполнять создание папок на RAM диске:

mkdir «<Путь к папке на RAM диске>»

Пример батника:


mkdir B:\Users\1c\user1
mkdir B:\Users\1c\user2
mkdir B:\Users\1c\user3


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

gpedit.msc -> Конфигурация компьютера -> Конфигурация Windows -> Автозагрузка.

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

Некоторые приложения RAM-дисков http://www.gilev.ru/ram-disk/ позволяют создавать каталоги автоматом.

Можно принудительно установить имя пользователя путем дописывание строчки:

/N»<имя пользователя 1С>»

в дополнительные параметры запуска. Или строчки:

AdditionalParameters=/N»<имя пользователя 1С>» в файл

C:\Users\<Имя пользователя>\AppData\Roaming\1C\1CEStart\ibases.v8i

Размещать каталог C:\Users\<Имя пользователя>AppData\Roaming\1C\1cv8 на рам-диске надо продуманно, так как там хранятся различные настройки.

2. Перенос временных файлов пользователя.

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

Аналогично переносу кеша, только папка будет другой (по умолчанию: %USERPROFILE%\AppData\Local\Temp).

Каталоги
С:\Temp
C:\Windows\Temp
общесистемных временных файлов также могут быть использованы 1С и их можно переносить на РАМ-диск, но делать надо это острожно, с учетом других приложений на сервере.

3. Перенос журнала регистрации

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

Путь размещения лучше всего посмотреть через ключ D запуска сервера 1С.
Пример размещения C:\Program Files\1cv8\srvinfo\reg_1541\ad4b6360-d5be-4ddf-b55c-4af1496443f2\1Cv8Log

4. Перенос сеансовых данных.

При большом количестве пользователей есть смысл кэшировать сеансовые данные. Подробней здесь http://www.gilev.ru/introsd/ .
Путь размещения лучше всего посмотреть через ключ D запуска сервера 1С.
Пример размещения C:\Program Files\1cv8\srvinfo\reg_1541\snccntx10790324-1e9b-4e2e-bbdc-6d02b2fffd9e

Про виртуализацию и 1С

Поговорим о виртуализации.
Последние несколько лет стала очень широко использоваться виртуализация, администраторы очень быстро увидели плюсы для себя: очень удобно работать с такой машиной, легко переносить её между несколькими физическими серверами, можно настроить отказоустойчивую схему, когда одну виртуальную машину могут обслуживать более одного физического сервера. Кроме того, виртуалка перезагружается на порядок быстрее. Кто не знает, приличный физический сервер может спокойно перезагружаться по 10-15 минут: пока всё потушит, пока сразу после старта неспешно всё у себя проверит, затем даст возможность контроллерам дисковых накопителей потестировать себя и диски всласть, и только после этого начинает грузить операционную систему. Виртуальный же сервер все проверки проскакивает за секунды, с точки зрения железа это всего лишь обычная программа. А для руководства компании мощнейший плюс виртуализации состоит ещё и в том, что можно взять например десять устаревших серверов, и запихнуть их функции на один физический, получается серьёзная экономия что на модернизации оборудования как такового, что на площади серверной комнаты, что на электричестве, нужном для работы и охлаждения сервера. Или можно арендовать в дата-центре вместо десяти слабеньких серверов один сильненький за меньшие суммарно деньги. К тому же, если например раньше вам потребовалось бы увеличить в два раза мощность двух из этих десяти серверов, это могло повлечь за собой необходимость апгрейда этих серверов. А в виртуальной системе достаточно изменить настройки выделения ресурсов. Ну и если вдруг мощности конкретного хост-сервера перестало хватать, можно вынести отдельные виртуалки на другой сервер, причём в некоторых случаях можно их даже не выключать.
Ну то есть замечательная технология. А есть ли у неё минусы? К сожалению, есть.
Главный и основополагающий для нас минус — это снижение производительности (по нашим данным, вендоры сообщают о замедлении относительно физических серверов от 9 до 24%). Причём снижение это идёт сразу по нескольким уровням. Во-первых, что бы там ни рассказывали производители процессоров и виртуальных сред, технология виртуализации сама по себе предполагает выполнение команд не в оригинальной среде, а в её имитации, которая называется эмуляцией. Эмуляция по ресурсам совсем не бесплатна, она отнимает в лучшем случае несколько процентов производительности по сравнению с исполнением того же кода на этом же оборудовании, но без виртуальной среды.
Во-вторых, свои штрафы накладывает эмуляция сетевых интерфейсов и эмуляция сетевых дисков, которые тоже отнимают каждая свои процентики.
Что делает уважающий себя администратор, дорвавшийся до виртуалок? Он берёт старый сервер, где крутились одновременно сервер 1С и сервер СУБД, и раскладывает роль сервера 1С в одну виртуалку, а роль сервера СУБД в другую. С точки зрения отказоустойчивости и балансировки нагрузки — он большой молодец. Такую схему разносить по нескольким физическим серверам проще, распределить нагрузку по незагруженным серверам например.
Однако схема такая сразу начинает работать медленней. Причём, например результат нашего теста может упасть сразу в два раза.
Почему? Например, потому что раньше сервер 1С и сервер СУБД внутри одной операционной системы общались между собой по протоколу Shared Memory, и это было очень быстро. А теперь используют сетевой интерфейс, а даже внутри одного сервера виртуализация сети- задача по ресурсам совсем не бесплатная.
А кроме того, есть ещё и неудобные для 1С сочетания факторов, вот как на снимке: использование сетевого интерфейса WMXNET3 практически гарантирует узкое место на передаче данных 1С по сети.
Есть ещё ряд факторов, которые могут ухудшить производительность виртуальной среды относительно выполнения той же программы на физическом железе без виртуализации.
Мы же выделим один наиболее значимый. Теперь кроме всех прочих факторов, добавляется ещё один, совершенно непредсказуемый для виртуальной машины: на этом же железе может исполняться неизвестное количество других виртуальных машин, нагрузка которых может колебаться от условного 0 до 100%. Благодаря этому можно наблюдать например такую картину: сидит один пользователь в базе, на сервере 1С кроме него никого нет, и запускает один и тот же несложный отчёт, например взаиморасчёты по отдельным контрагентам с расшифровкой по документам. Объём данных примерно одинаковый, и время формирования должно быть примерно одинаковым, но нет! То отчёт формируется за секунду, а то приходится ждать целую минуту. Почему? А потому что на этом же физическом сервере в это время например другой бухгалтер в другой базе на другом сервере запустил закрытие месяца, и сервер страшно занят. Изнутри виртуальной машины вот это внешнее влияние отследить совершенно никак невозможно, только с тоской наблюдать, как скачут замеры времени ключевых операций.
Что делать в данном случае? Обеспечить гарантированно высокую производительность системы можно только в том случае, когда ей никто не может помешать. То есть ответ простой: если высокая производительность какой-то конкретной базы 1С является ключевым показателем работы сервера, то всех остальных пассажиров приходится подвинуть. Либо на конкретном примере с объективными замерами показываем админам, что разница в производительности слишком велика, чтобы её игнорировать, и дальше конкретно эта база 1С обслуживается физическим сервером без виртуализации, либо разгружаем виртуальный сервер от всех сторонних виртуальных машин, и эта база 1С обслуживается виртуальным сервером, но её производительность в любом случае становится стабильной.
В книжке 1С эксперта на 22й странице методика считает, что наиболее значимый вклад составляют плохая работа запроса и плохая работа кода. При этом способность среды выполнять действия с необходимой скоростью не рассматривается. Считается, что во-первых скорость среды неизменна, хотя в виртуальной среде это может быть совсем не так. Кроме того, схожая по внешним признакам среда на практике может кардинально отличаться способностью выполнять такой же объём работ за единицу времени. На сервер может быть возложена куча других задач («резиновый сервер»: купили дорогой, надо использовать ) Обычно, когда проводят нагрузочное тестирование – его всегда проводят с имитацией деятельности в базе, но в реальной жизни надо учитывать и имитировать любую другую стороннюю нагрузку (веб-сервер, терминальный сервер, другая ERP), которые могут отнимать непредсказуемую часть ресурсов сервера. В учебнике приводится упрощённый вариант, которого в жизни обычно не бывает. Написанное в учебнике правильно, но этого явно недостаточно для того, чтобы решать задачу по-настоящему. Умение разложить состав нагрузки по составляющим источникам позволяет существенно сократить объём денег и усилий, необходимых для решения проблем.
Кроме того, многие компании, обеспечивающие работу в ЦОД, зачастую не могут сказать – где находится физически виртуальная машина. Таким образом, эксплуатируемое приложение в виртуальной среде, не привязанное к физическому оборудованию, при частой миграции виртуальной среды между узлами, может кардинально менять скорость исполнения в виртуальной среде. Также вы можете встретиться с ситуацией, когда несколько айти-специалистов берут из одного источника один и тот же образ виртуальной машины, запускают на своих компьютерах с максимально похожими характеристиками, и получают совершенно разные результаты тестов производительности. Более того, даже запуская на одном компьютере несколько копий одного образа, неожиданно выясняется необходимость понимания механизма привязки виртуальных ядер к физическим ядрам процессора. Например, когда на четырёхсокетной машине виртуальная система выбирает ядра разных процессоров, скорость отличается от той же самой виртуалки, ядра которой привязаны к одному физическому процессору.
В качестве ещё одного примера: у нас в своё время был неприятный опыт отладки запроса на базе 1С, размещённой в облаке Амазон. Сервер 1С был развёрнут на одной амазоновской виртуалке, сервер СУБД на другой. Сидим на тестовом сервере в одном сеансе, никого больше нет. Запускаем один и тот же довольно несложный запрос и замечаю, что время его выполнения может отличаться на порядок. То есть к примеру он может выполниться за 3 секунды, в следующий раз за 25, потом за 10. Внутри тестовых серверов не происходит ничего, что могло бы объяснить такую разницу. Всё зависит от того, сколько и каких виртуалок ещё развёрнуто на тех же физических серверах, какую они генерируют загрузку процессоров, памяти, дисков и сети.
В жизни бывают ещё более сложные задачи, когда из-за несущественных на первый взгляд факторов может измениться скорость среды.

Postgres параметр full_page_writes

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

Postgres параметр SYNCHRONOUS_COMMIT

Включает/выключает синхронную запись в лог-файлы после каждой транзакции. Включение синхронной записи защищает от возможной потери данных. Но, накладывает ограничение на пропускную способность сервера. Вы можете отключить синхронную запись, если вам необходимо обеспечить более высокую производительность по количеству транзакций. А потенциально низкая возможность потери небольшого количества изменений при крахе системы не критична. Для отключения синхронной записи установите значение off в этом параметре.

Еще одним способом увеличения производительности работы PostgreSQL является перенос журнала транзакций (pg_xlog) на другой диск. Выделение для журнала транзакций отдельного дискового ресурса позволяет получить получить при этом существенный выигрыш в производительности 10%-12% для нагруженных OLTP систем.

В Linux это делается с помощью создания символьной ссылки на новое положение каталога с журналом транзакций.

В Windows можно использовать для этих целей утилиту Junction. Для этого надо:

  1. Остановить PostgreSQL.
  2. Сделать бэкап C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog.
  3. Скопировать C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog в D:\pg_xlog и удалить C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog.
  4. Распаковать программу Junction в C:\Program Files\PostgreSQL\X.X.X\data.
  5. Открыть окно CMD, перейти в C:\Program Files\PostgreSQL\X.X.X\data и выполнить junction -s pg_xlog D:\pg_xlog.
  6. Установить права на папку D:\pg_xlog пользователю postgres.
  7. Запустить PostgreSQL.
    Где X.X.X — версия используемой PostgreSQL.

Postgres: параметр fsync

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

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

Возможные значения:

  • open_datasync – запись данных методом open() с параметром O_DSYNC,
  • fdatasync – вызов метода fdatasync() после каждого commit,
  • fsync_writethrough – вызывать fsync() после каждого commit игнорирую параллельные процессы,
  • fsync – вызов fsync() после каждого commit,
  • open_sync – запись данных методом open() с параметром O_SYNC.

ПРИМЕЧАНИЕ! Не все методы доступны на определенных платформах. Выбор метода зависит от операционной системы под управлением, которой работает PostgreSQL.

В состав PostgreSQL входит утилита pg_test_fsync, с помощью которой можно определить оптимальное значение параметра wal_sync_method.

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

Для вероятно Windows оптимальным решением будет использование open_datasync.

Для Linux вероятно  оптимальным решением будет использование fdatasync и open_datasync.

РЕШЕНИЕ ПРОБЛЕМЫ С ЗАВИСАНИЕМ POSTGRESQL.

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

Варианты решения проблемы:

  1. Увеличить количество записей, просматриваемых при сборе статистики по таблицам. Большие значения могут повысить время выполнения команды ANALYZE, но улучшат построение плана запроса:
    1. Файл postgresql.conf — default_statistics_target = 1000 -10000.
  2. Отключение оптимизатору возможности использования NESTED LOOP при выборе плана выполнения запроса в конфигурации PostgreSQL:
    1. Файл postgresql.conf — enable_nestloop = off.
    2. Отрицательным эффектом этого способа является возможное замедление некоторых запросов, поскольку при их выполении будут использоваться другие, более затратные, методы соединения (HASH JOIN).
  3. Отключение оптимизатору возможности изменения порядка соединений таблиц в запросе:
    1. Файл postgresql.conf — join_collapse_limit=1.
    2. Следует использовать этот метод, если вы уверены в правильности порядка соединений таблиц в проблемном запросе.
  4. Изменение параметров настройки оптимизатора:
    1. Файл postgresql.conf:
      1. seq_page_cost = 0.1
      2. random_page_cost = 0.4
      3. cpu_operator_cost = 0.00025
  5. Использование версии PostgreSQL 9.1.2-1.1.C и выше, в которой реализован независимый от AUTOVACUUM сбор статистики, на основе информации об изменении данных в таблице. По умолчанию включен сбор статистики только для временных таблиц и во многих ситуациях этого достаточно. При возникновении проблем с производительностью выполнения регламентных операций, можно включить сбор статистики для всех или отдельных проблемных таблиц изменив значение параметра конфигурации PostgreSQL (файл postgresql.confonline_analyze.table_type = "temporary" на online_analyze.table_type = "all".

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

Скрипт сжатие таблиц mssqlserver

DECLARE @Table_catalog NVARCHAR(128)
DECLARE @Table_schema NVARCHAR(128)
DECLARE @Table_name NVARCHAR(128)
DECLARE @Index_Name NVARCHAR(128)

DECLARE @cmd VARCHAR(4000)

— включение сжатия для таблиц
DECLARE TableNameCursor CURSOR
FOR
SELECT Table_catalog, Table_schema, Table_name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = ‘BASE TABLE’
ORDER BY Table_catalog, Table_schema, Table_name

OPEN TableNameCursor

FETCH NEXT FROM TableNameCursor INTO @Table_catalog, @Table_schema, @Table_name
WHILE @@fetch_status = 0
BEGIN

PRINT @Table_catalog + ‘.’ + @Table_schema + ‘.’ + @Table_name
SET @cmd = ‘ALTER TABLE [‘ + @Table_catalog + ‘].[‘ + @Table_schema + ‘].[‘ + @Table_name + ‘] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)’
EXEC (@cmd)

FETCH NEXT FROM TableNameCursor INTO @Table_catalog, @Table_schema, @Table_name
END
CLOSE TableNameCursor
DEALLOCATE TableNameCursor

— включение сжатия для индексов
DECLARE IndexCursor CURSOR
FOR
SELECT DB_NAME(), schemas.name, tables.name, indexes.name
FROM sys.schemas as schemas inner join sys.tables as tables inner join sys.indexes as indexes on tables.object_id = indexes.object_id on schemas.schema_id = tables.schema_id
ORDER BY schemas.name, tables.name, indexes.name;

OPEN IndexCursor

FETCH NEXT FROM IndexCursor INTO @Table_catalog, @Table_schema, @Table_name, @Index_Name
WHILE @@fetch_status = 0
BEGIN

PRINT @Table_catalog + ‘.’ + @Table_schema + ‘.’ + @Table_name + ‘: ‘ + @Index_Name

SET @cmd = ‘ALTER INDEX [‘ + @Index_Name + ‘] ON [‘ + @Table_catalog + ‘].[‘ + @Table_schema + ‘].[‘ + @Table_name + ‘] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)’
EXEC (@cmd)

FETCH NEXT FROM IndexCursor INTO @Table_catalog, @Table_schema, @Table_name, @Index_Name
END
CLOSE IndexCursor
DEALLOCATE IndexCursor

— делаем шринк базы — возвращаем свободное место на диск
SELECT @cmd=(
SELECT ‘DBCC SHRINKDATABASE(»’+ DB_NAME() + »’)’
)
EXEC (@cmd)

Использование буферного кеша Postgres

SELECT
'total', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int))
FROM pg_buffercache
UNION SELECT
'dirty', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int))
FROM pg_buffercache
WHERE isdirty
UNION SELECT
'clear', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int))
FROM pg_buffercache
WHERE NOT isdirty
UNION SELECT
'used', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int))
FROM pg_buffercache
WHERE reldatabase IS NOT NULL
UNION SELECT
'free',pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int))
FROM pg_buffercache
WHERE reldatabase IS NULL;
SELECT
d.datname,
pg_size_pretty(pg_database_size(d.datname)) AS database_size,
pg_size_pretty(count(b.bufferid) * (SELECT current_setting('block_size')::int)) AS size_in_shared_buffers,
round((100 * count(b.bufferid) / (SELECT setting FROM pg_settings WHERE name
= 'shared_buffers')::decimal),2) AS pct_of_shared_buffers
FROM pg_buffercache b
JOIN pg_database d ON b.reldatabase = d.oid
WHERE b.reldatabase IS NOT NULL
GROUP BY 1 ORDER BY 4 DESC LIMIT 10;

Использование индексов Postgres

SELECT
t.tablename,
indexname,
c.reltuples AS num_rows,
pg_size_pretty(pg_relation_size(quote_ident(t.tablename)::text)) AS table_size,
pg_size_pretty(pg_relation_size(quote_ident(indexrelname)::text)) AS index_size,
CASE WHEN indisunique THEN 'Y' ELSE 'N' END AS UNIQUE,
idx_scan AS number_of_scans, idx_tup_read AS tuples_read, idx_tup_fetch AS tuples_fetched
FROM pg_tables t
LEFT OUTER JOIN pg_class c ON t.tablename=c.relname
LEFT OUTER JOIN
( SELECT c.relname AS ctablename, ipg.relname AS indexname, x.indnatts AS number_of_columns,
idx_scan, idx_tup_read, idx_tup_fetch, indexrelname, indisunique FROM pg_index x
JOIN pg_class c ON c.oid = x.indrelid JOIN pg_class ipg ON ipg.oid = x.indexrelid
JOIN pg_stat_all_indexes psai ON x.indexrelid = psai.indexrelid )
AS foo
ON t.tablename = foo.ctablename
WHERE t.schemaname='public'
ORDER BY 1,2;
--------------------------------------------------------------
SELECT
idstat.relname AS table_name,
indexrelname AS index_name,
idstat.idx_scan AS times_used,
pg_size_pretty(pg_relation_size(tabstat.relid)) AS table_size,
pg_size_pretty(pg_relation_size(indexrelid)) AS index_size,
n_tup_upd + n_tup_ins + n_tup_del as num_writes,
indexdef AS definition
FROM
pg_stat_user_indexes AS idstat
JOIN pg_indexes ON indexrelname = indexname
JOIN pg_stat_user_tables AS tabstat ON idstat.relname = tabstat.relname
WHERE
idstat.idx_scan < 200 AND indexdef !~* 'unique' ORDER BY idstat.relname, indexrelname; -------------------------------------------------------------- WITH table_scans as ( SELECT relid, tables.idx_scan + tables.seq_scan as all_scans, ( tables.n_tup_ins + tables.n_tup_upd + tables.n_tup_del ) as writes, pg_relation_size(relid) as table_size FROM pg_stat_user_tables as tables ), all_writes as ( SELECT sum(writes) as total_writes FROM table_scans ), indexes as ( SELECT idx_stat.relid, idx_stat.indexrelid, idx_stat.schemaname, idx_stat.relname as tablename, idx_stat.indexrelname as indexname, idx_stat.idx_scan, pg_relation_size(idx_stat.indexrelid) as index_bytes, indexdef ~* 'USING btree' AS idx_is_btree FROM pg_stat_user_indexes as idx_stat JOIN pg_index USING (indexrelid) JOIN pg_indexes as indexes ON idx_stat.schemaname = indexes.schemaname AND idx_stat.relname = indexes.tablename AND idx_stat.indexrelname = indexes.indexname WHERE pg_index.indisunique = FALSE ), index_ratios AS ( SELECT schemaname, tablename, indexname, idx_scan, all_scans, round(( CASE WHEN all_scans = 0 THEN 0.0::NUMERIC ELSE idx_scan::NUMERIC/all_scans * 100 END),2) as index_scan_pct, writes, round((CASE WHEN writes = 0 THEN idx_scan::NUMERIC ELSE idx_scan::NUMERIC/writes END),2) as scans_per_write, pg_size_pretty(index_bytes) as index_size, pg_size_pretty(table_size) as table_size, idx_is_btree, index_bytes FROM indexes JOIN table_scans USING (relid) ), index_groups AS ( SELECT 'Never Used Indexes' as reason, *, 1 as grp FROM index_ratios WHERE idx_scan = 0 and idx_is_btree UNION ALL SELECT 'Low Scans, High Writes' as reason, *, 2 as grp FROM index_ratios WHERE scans_per_write <= 1 and index_scan_pct < 10 and idx_scan > 0
and writes > 100
and idx_is_btree
UNION ALL
SELECT 'Seldom Used Large Indexes' as reason, *, 3 as grp
FROM index_ratios
WHERE
index_scan_pct < 5 and scans_per_write > 1
and idx_scan > 0
and idx_is_btree
and index_bytes > 100000000
UNION ALL
SELECT 'High-Write Large Non-Btree' as reason, index_ratios.*, 4 as grp
FROM index_ratios, all_writes
WHERE
( writes::NUMERIC / total_writes ) > 0.02
AND NOT idx_is_btree
AND index_bytes > 100000000
ORDER BY grp, index_bytes DESC )
SELECT reason, schemaname, tablename, indexname,
index_scan_pct, scans_per_write, index_size, table_size
FROM index_groups;

Отсутствие индексов Postgres

SELECT
relname,
seq_scan - coalesce(idx_scan, 0) AS too_much_seq,
case when seq_scan - coalesce(idx_scan, 0) > 0 THEN 'Нет индекса?' ELSE 'OK' END AS Message,
pg_relation_size(relname::regclass) AS rel_size,
seq_scan,
coalesce(idx_scan, 0) AS idx_scan
FROM
pg_stat_all_tables
WHERE
schemaname='public'
AND pg_relation_size(relname::regclass)>10000 -- ограничение на размер анализируемых таблиц
ORDER BY
too_much_seq DESC;

Базы данных с максимальным IO Postgres

SELECT
pg_stat_database.datname AS DatabaseName,
MAX(pg_stat_database.tup_returned) AS TotalReads,
MAX(pg_stat_database.tup_inserted + pg_stat_database.tup_updated + pg_stat_database.tup_deleted) AS TotalWrites,
MAX(pg_stat_database.tup_returned + pg_stat_database.tup_inserted + pg_stat_database.tup_updated
+ pg_stat_database.tup_deleted) AS IO,
SUM(pg_stat_statements.calls) AS ExecutionCount

FROM
pg_catalog.pg_stat_database AS pg_stat_database
LEFT OUTER JOIN pg_stat_statements AS pg_stat_statements
ON pg_stat_statements.dbid = pg_stat_database.datid
GROUP BY
pg_stat_database.datname
ORDER BY
IO Desc

Разброс времени на разных компьютерах может приводить к обрыву соединений

Причиной перезапуска процессов может являться изменение системного времени. Из-за этого процесс rmngr фиксирует исчерпание таймаута ожидания принга от рабочего процесса и считает рабочий процесс пропавшим. Это происходит например если у вас включена синхронизация с NTP сервером, и периодически происходит значительная корректировка времени. Это можно обнаружить в журнале событий Windows по событию от Kernel-General об изменении времени  Event Viewer — группа Windows Log — журнал System — отбор (Filter Current Log) по Event Sources = Kernel General и Event ID = 1 типа такого:
The system time has changed to ‎2017‎-‎01‎-‎30T13:31:54.401000000Z from ‎2017‎-‎01‎-‎30T13:31:49.686072200Z.
Change Reason: An application or system component changed the time.

 

Запускается новый рабочий процесс сервера 1С, а старый завершается. Тайм-аут по умолчанию равен 5 секундам.
Пользователями это воспринимается как массовое подвисание.

Для его изменения можно запустить ragent с параметрами, например, -pingperiod 3000 -pingtimeout 15000.

Особенности 8.3.9

С версии 8.3.9.1818, 1С:Предприятие поддерживает прозрачную переустановку разорванных соединений с SQL-сервером, за исключением случаев разрыва соединения при активной транзакции.

Реализована поддержка СУБД Microsoft SQL Server 2016.

Ускорена работа в многопользовательском режиме при использовании СУБД Microsoft SQL Server при активном использовании tempdb, а также устранены задержки при закрытии соединений.

Для Microsoft SQL Server 2014 сервер «1С:Предприятия» выполняет принудительную установку TRACE FLAG 4199. В связи с этим в настройках соединения сервера «1С:Предприятие» с СУБД необходимо указывать пользователя, обладающего административными правами sysadmin.

Источник: http://downloads.v8.1c.ru/content//Platform/8_3_9_2170/1cv8upd.htm#7c1b8dd6-9531-11e6-a3f7-0050569f678a

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

Если при эскалации блокировки возникает конфликт с уже наложенными блокировками, то эскалация не выполняется, а производится попытка установить запрошенную блокировку. В этом случае возможна ситуация, когда в системе будет существовать более 100 000 блокировок на одно пространство.

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

 

Диагностика серверных вызовов

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

 

Веб-сервисы

За счёт переиспользования сеансов значительно увеличена производительность веб-сервисов. http://v8.1c.ru/o7/201604service/index.htm подробнее

Реализованы две различные стратегии:

  • Автоматическое переиспользование сеансов из пула;
  • Управление сеансами с помощью HTTP-заголовков.

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

Бета-версия 64-разрядных приложений для Windows

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

Преимущество 64-разрядных приложений заключается в том, что они не имеют ограничений по использованию оперативной памяти. Это позволяет более комфортно работать в конфигураторе с крупными конфигурациями, такими как ERP.

Форматированный документ

Ускорена работа форматированного документа с большими объёмами данных.

 

Инструменты для работы с двоичными данными

Реализован ряд низкоуровневых инструментов для работы с двоичными данными. С их помощью возможна последовательная работа с большими объёмами данных. Также они предоставляют произвольный доступ к относительно небольшим двоичным данным целиком в оперативной памяти. Новые инструменты позволяют решать такие задачи, как:

  • Взаимодействие со специализированными устройствами по двоичному протоколу;
  • Разбор файлов и манипуляция файлами различных форматов;
  • Конвертация текстовых данных напрямую в двоичные данные, например, для отправки отчетов;
  • Работа с двоичными данными в памяти.

Удерживать таблицу в оперативной памяти PostgreSQL

pg_prewarm http://www.postgresql.org/docs/9.4/static/pgprewarm.html

Разогрев кэша

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

Для начала, установим расширение и создадим тестовую таблицу:

<code>CREATE EXTENSION pg_prewarm;

CREATE TABLE big AS
SELECT array_to_string ( array_agg ( t.x ), '' )
	|| '#' || generate_series ( 1, 10000 ) AS value
FROM ( SELECT 'a' || generate_series ( 1, 1000 ) AS x ) t;

-- немного увеличим размер буфера
ALTER SYSTEM SET shared_buffers = '256MB';
</code>

Теперь, остановим сервер PostgreSQL, сбросим кэши ОС на диск и запустим сервер снова (в вашей ОС команды могут быть иные):

<code>/etc/init.d/postgresql-9.4 stop
sync
/etc/init.d/postgresql-9.4 start
</code>

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

<code>-- первая попытка
EXPLAIN ( ANALYZE, BUFFERS )
SELECT * FROM big;
--
Seq Scan on big  (cost=0.00..76047.00 rows=5000000 width=8) (actual time=0.013..448.978 rows=5000000 loops=1)
  Buffers: shared read=26047
Planning time: 0.081 ms
Execution time: 689.083 ms

-- вторая попытка
EXPLAIN ( ANALYZE, BUFFERS )
SELECT * FROM big;
--
Seq Scan on big  (cost=0.00..76047.00 rows=5000000 width=8) (actual time=0.044..449.973 rows=5000000 loops=1)
  Buffers: shared hit=32 read=26015
Planning time: 0.027 ms
Execution time: 692.045 ms

-- третья попытка
EXPLAIN ( ANALYZE, BUFFERS )
SELECT * FROM big;
--
Seq Scan on big  (cost=0.00..76047.00 rows=5000000 width=8) (actual time=0.044..449.973 rows=5000000 loops=1)
  Buffers: shared hit=32 read=26015
Planning time: 0.027 ms
Execution time: 692.045 ms
</code>

Наглядно видно, что так как в кэше еще ничего нет, данные читаются с диска (shared read), но с каждым последующим запросом кэш наполняется (shared hit).

Снова остановим сервер PostgreSQL, сбросим кэш ОС и запустим сервер. И опять посмотрим на результат EXPLAIN, но перед этим заполнив кэш данными тестовой таблицы:

<code>-- загружено 26047 блоков
SELECT pg_prewarm ( 'big' );

EXPLAIN ( ANALYZE, BUFFERS )
SELECT * FROM big;
--
Seq Scan on big  (cost=0.00..76047.00 rows=5000000 width=8) (actual time=0.007..407.269 rows=5000000 loops=1)
  Buffers: shared hit=26047
Planning time: 0.129 ms
Execution time: 642.834 ms
</code>

Все данные уже находятся в кэше.

 

Статистика которую можно получить из базы данных PostgreSQL

Таблица Описание
pg_stat_activity Каждая строка показывает: процесс сервера, OID базы данных, имя базы данных, ID процесса, OID пользователя, имя пользователя, имя приложения, адрес клиента и порт,время, текущею транзакцию, текущий запрос, статус процесса, текст запроса. Колонки показывающие данные текущего запроса доступны если параметр track_activities включен. Эти колонки доступны только для суперпользователя или пользователя владельца процесса.
pg_stat_bgwriter One row only, showing cluster-wide statistics from the background writer: number of scheduled checkpoints, requested checkpoints, buffers written by checkpoints and cleaning scans, and the number of times the background writer stopped a cleaning scan because it had written too many buffers. Also includes statistics about the shared buffer pool, including buffers written by backends (that is, not by the background writer) and total buffers allocated.
pg_stat_database Одна строка: OID базы данных, имя базы данных, количество процессов подключенных к базе, кол-во транзакций примененных и отмененных, количество прочитанных блоков, количество попаданий в буфер, количество выбранных, переданных, добавленных, обновленных и удаленных строк.
pg_stat_all_tables Для каждой таблицы в текущей базе данных (включая TOAST таблицы): OID таблицы, схема и имя таблицы, количество последовательны просмотров, количество строк выбранных запросами, количество просмотров индексов (все индексы данной таблицы), количество строк выбранных через сканирование индексов, количество: пересечений строк, обновленных, удаленных строк, количество обновленных HOT строк, количество живых и мертвых строк, время последнего ручного vacuum, время последнего автоматического vacuum, время последнего ручного analyze, время последнего автоматического analyze.
pg_stat_sys_tables То же что и pg_stat_all_tables, только системные таблицы
pg_stat_user_tables То же что и pg_stat_all_tables, только пользовательские таблицы
pg_stat_all_indexes Для каждого индекса текущей базы: OID таблицы и OID, схема, имя таблица и индекса, количество просмотров индекса, количество записей возвращенных при сканировании индекса, количество живых строк таблицы полученных простым сканированием индексов используя этот индекс.
pg_stat_sys_indexes То же что и pg_stat_all_indexes, только системные таблицы
pg_stat_user_indexes То же что и pg_stat_all_indexes, только пользовательские таблицы
pg_statio_all_tables Для каждой таблицы текущей базы данных (включая TOAST таблицы), OID таблицы, схема и имя таблицы, количество блоков прочитанных с диска, количество попаданий в буфер, количество блоков прочитанных с диска и попавших в буфер для всех индексов таблицы, количество блоков прочитанных с диска и попавших в буфер that table’s auxiliary TOAST table (if any), количество блоков прочитанных с диска и попавших в буфер для индекса TOAST таблиц.
pg_statio_sys_tables То же что и pg_statio_all_tables, только системные таблицы
pg_statio_user_tables То же что и pg_statio_all_tables, только пользовательские таблицы
pg_statio_all_indexes Для каждого индекса текущей базы данных: OID таблицы и индекса, имя таблицы и индекса, количество блоков прочитанных с диска и попаданий в буфер.
pg_statio_sys_indexes То же что и pg_statio_all_indexes, только системные таблицы
pg_statio_user_indexes То же что и pg_statio_all_indexes, только пользовательские таблицы
pg_statio_all_sequences Для каждой последовательности в текущей базе данных: OID последовательности, схема и имя последовательности, количество прочитанных блоков с диска и попаданий в буфер.
pg_statio_sys_sequences То же что и pg_statio_all_sequences, только системные таблицы
pg_statio_user_sequences То же что и pg_statio_all_sequences, только пользовательские таблицы
pg_stat_user_functions For all tracked functions, function OID, schema, name, number of calls, total time, and self time. Self time is the amount of time spent in the function itself, total time includes the time spent in functions it called. Time values are in milliseconds.
pg_locks Информация о блокировках в базе

Hyper-threading процессоров для производительности — за и против

hyper-threading_kak_working

•После включения технологии гипертрейдинга один физический процессор (одно физическое ядро) определяется операционной системой как два отдельных процессора (два логических ядра). При определённых рабочих нагрузках использование HTT позволяет увеличить производительность процессора. В некоторых тестах около 25% улучшения.
•…а может и ухудшить (любая технология обладает не только плюсами, но и минусами, из-за непопадания в кэш процессора, из-за неправильного предсказания алгоритмом ветвления по потокам задач, взаимное ожидание ресурсов в разных потоках, более «быстрые потоки» ждут «более медленные потоки», ошибки в выборе по загруженности ресурсов)
•НЕ все можно разбить на потоки (вообще складывается субъективное ощущение что гипертрейдинг хорошо работает на настольных компьютерах/ноутбуках где на разных ядрах работают монопточные не пересекаемые приложения)
•НЕ все приложения умеют работать с этой технологией (долгое время Microsoft рекомендовал для MS SQL Server выключать гипертрейдинг еще и потому что его внутренние алгоритмы уже распараллеливают работу на нужном уровне и остальные «улучшения» спорны)
https://support.microsoft.com/ru-ru/kb/322385 «все зависит от нагрузки», моими словами коротко – ни кто точно не знает, пробуйте и так и сяк 

ht

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

https://msdn.microsoft.com/ru-ru/library/ms143760(v=SQL.120).aspx влияние на стоимость владения лицензий в виртуалках
•Если важна производительность в пересчете на виртуальный процессор, может понадобиться отключить технологию Hyper-Threading. Технологию Hyper-Threading можно включать и отключать в параметрах процессора в BIOS, но обычно это операция на уровне сервера, которая действует на всю рабочую нагрузку, активную на сервере. Это обстоятельство делает разумным отделение рабочей нагрузки, действующей в виртуальных средах, от нагрузки, для которой технология Hyper-Threading обеспечит прирост производительности в среде физической операционной системы.
ИТОГО: Для локальных однопользовательских приложений или их использовании на серверах изолированно гипертрейдинг в теории должен улучшать количество одновременно выполняемых задач и сказывать положительно. Что же касается сложных продуктов как 1С:Предприятие 8 и СУБД на большое количество пользователей или по пересекаемым ресурсам/данным точно можно понять только проведя сравнительное тестирование.
Вы можете высказать свое мнение на нашем форуме http://www.gilev.ru/forum/viewtopic.php?f=18&t=1053

Настройка спящих сеансов

Спящие сеансы

spyashii-regim

При нештатном завершении клиентского приложения (обрыв связи или закрытие окна бразуера) клиентские лицензии «1С: Предприятие 8» могут блокироваться.

Освободить заблокированные клиентские лицензии можно перезагрузкой ПК.

При нештатном завершении клиентского приложения сеанс удерживается еще 20 минут. После этого в версиях до 8.3.5 сеанс удалялся. С версии 8.3.5 сеанс засыпает в в спящем состоянии по умолчанию удерживается еще сутки. Спящий сеанс не занимает клиентскую лицензию «1С: Предприятие 8».

В версии 8.3.5 время засыпания сеанса и время удаления неиспользуемого спящего сеанса можно изменить с помощью специальной обработки или в Конфигураторе 1С в диалоге Администрирование/ Параметры информационной базы, установив рекомендуемые параметры спящего сеанса:

  • время засыпания пассивных сеансов — 300
  • время завершения спящих сеансов — 10

ib-settings

Кстати, кто спит, а кто активен всегда можно посмотреть через консоль сервера на закладке сеансов. В соответствующей колонке «Спящий» есть признак Да/Нет.

Штатно (по версии фирмы 1С) завершить работу в веб-клиенте можно командой «Файл»-«Выход». С версии 8.3.8 добавили команду завершения работы в заголовок приложения, рядом с кнопкой О программе. Она отображается в виде гиперссылки с именем текущего пользователя.При нажатии на гиперссылку открывается диалог с именем пользователя и командой Завершить работу.

Платформа  каждые 5 секунд делает пинги клиетом сервер 1С (видны пакеты по 4 байта).  На основании «пингов» сервер отслеживает целостность соединения с клиентским приложением. Отсутствие пингов в течение примерно 2 минут серввер интерпретирует как разрыв соединения.

В редакции  8.3.7.2008 исправлена ошибка незавершения спящих сеансов https://bugboard.v8.1c.ru/error/000013447.html

Определение производительности рабочего сервера 1С

SELECT COUNT(*) FROM DBSchema

Этот запрос используется как эталонный для измерения скорости обращения к СУБД при определении производительности рабочего сервера в кластере. Результат этого замера участвует в формировании значения колонки «Доступная производительность» списка рабочих процессов консоли кластера. На основании этого значения выбирается рабочий процесс, с которым устанавливается новое клиентское соединение с сервером.

Ошибки в практике оптимизации производительности 1С

 

  • Изменения в системе делаются не по одному
    • Мигрируют с 8.2 на 8.3, с БП 2.0 на 3.0, с одного сервера на другой, несколько изменений в параметрах субд сразу…
    • Нельзя оценить вклад каждого изменения
  • «В нашей команде достаточно опытных разработчиков, настоящих профессионалов своего дела, поэтому через какое-то время мы всё же нагуглили решение.»
    • Изменения делаются «по лучшим практикам»
    • Потому что соседу помогло (добавить SSD)
    • Потому что так советует «авторитет/вендор» (использовать временные таблицы в запросах)
    • Не анализируются причины «лучших практик» и их уместность в конкретном случае
  • Заранее не оценивается ожидаемый эффект
    • Делается что легче
    • Анализ поверхностный
    • Не анализируется наиболее узкое место
    • Можно положить много сил на устранение второстепенных проблем, но не решим наиболее важную они будут не оценены

Влияние стереотипов и привычек на производительность 1С

ВНИМАНИЕ! СТЕРЕОТИП: Сервер нагружен слабо, процессоры слабо используются – поэтому все медленно

  • загрузка сервера должна обеспечивать запас мощности под «пики»
  • неверная оценка загруженности (включая короткий интервал наблюдения)
  • чем больше блокировок, тем меньше загруженность
Да, конечно если у Вас процессоры сервера загружены «по полной» это не означает проблем. Но зато это означает что просто так добавить пользователей, новый функционал, обработать больший объем данных ХОРОШО вы вряд ли сможете — запаса мощности нет!
Кроме того высокая нагрузка на сервер создает большую ВЕРОЯТНОСТЬ что в пиковый момент (максимальной интенсивности) у Вас возникнет ожидание не только оборудования, но и блокировок (потому что часто вероятность блокировок увеличивается пропорционально растущему времени транзакций).

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

Еще один фактор пониженной нагрузку — блокировки. Когда у Вас интенсивные ожидания на блокировках, вы ЖДЕТЕ (т.е. почти ничего не делаете). В условиях массовых блокировок оборудование часто выглядит как слабо нагруженным, но на самом деле работа парализована. Когда избыточные блокировки «уйдут», то обычно увеличивается количество операций в единицу времени, а значит растет нагрузка на сервер.

Вот поэтому надо записывать нагрузку. на сервер, сопоставлять ее с ожиданиями оборудования и блокировок. Стараться не допускать ситуаций, когда запас мощности сервера составляет меньше 30% по любым компонентам (а не только по процессору).

Флаг трассировки 2335

Флаг трассировки 2335 заставит SQL Server 2005 и 2008 генерировать более консервативный с точки зрения потребления памяти план исполняя запроса, не ограничивая при этом объём используемой SQL Server памяти для  кэша данных, запросов и т.п. Необходимость в этом флаге может возникнуть, если после увеличения значения «max server memory» наблюдается замедление исполнения запросов. Подробности в статье KB2413549.

Флаги трассировки

В SQL Server существуют два типа флагов трассировки: для сеанса и глобальные. Флаги трассировки сеанса действуют во время данного соединения и доступны только для этого соединения. Глобальные флаги трассировки устанавливаются на уровне сервера и доступны для каждого соединения с этим сервером. Некоторые флаги могут быть включены только как глобальные, а некоторые и как глобальные, и как для сеанса.

Применяются следующие правила.

  • Глобальный флаг трассировки должен быть включен глобально. В противном случае, флаг трассировки не повлияет на работу сервера. Рекомендуется включать глобальные флаги трассировки при запуске с помощью параметра командной строки -T.
  • Если флаг трассировки может иметь или глобальную область, или область сеанса, он может быть включен с соответствующей областью. Флаг трассировки, включенный на уровне сеанса, никогда не влияет на другой сеанс, и действие флага трассировки прекращается, если SPID, открывший сеанс, выполняет выход.

Флаги трассировки устанавливаются и снимаются с помощью любого из следующих методов:

  • Использование команд DBCC TRACEON и DBCC TRACEOFF.Например, DBCC TRACEON 2371: Чтобы включить флаг трассировки глобально, используйте DBCC TRACEON с аргументом -1: DBCC TRACEON (2371, -1). Чтобы отключить глобальный флаг трассировки, используйте команду DBCC TRACEOFF с аргументом -1.
  • Использование параметра запуска -T для задания установки флага трассировки при запуске.Параметр запуска -T включает флаг трассировки глобально. Невозможно включить флаг трассировки уровня сеанса с помощью параметра запуска. Дополнительные сведения о параметрах запуска см. в разделе 

Использование команды DBCC TRACESTATUS для определения активных в данный момент флагов трассировки.

Перечень флагов вы сможете посмотреть на msdb.

Флаг трассировки 1117

Флаг трассировки 1117

При наличии типа ожидания pagelatch рекомендуется вспомнить про логическую конкуренцию ресурсов файлов.

select   session_id, wait_duration_ms,   resource_description      from    sys.dm_os_waiting_tasks where   wait_type like ‘PAGE%LATCH_%’ and              resource_description like ‘2:%’
В рамках одной файловой группы может быть создано несколько файлов. Например, для базы tempdb рекомендуется создавать несколько файлов, что может в некоторых сценариях увеличить производительность системы.

Идея такая:
Если логических ядер <=8 то файлов tempdb должно быть равно количеству ядер (при том что диск достаточный для увеличения нагрузки)

Если логических ядер >8 то добавить еще 4 файла и посмотреть по факту. Надо, еще добавить, но при этом важно не переборщить, можно вместо логических ожиданий наплодить очередей к диску например.

Теперь предположим ситуацию: все файлы, входящие в файловую группу, имеют одинаковый размер. Создается большая временная таблица. Места в файле #1 не достаточно и разумеется происходит AutoGrow. Через время такая же таблица пересоздается, но вставка происходит в файл #2, потому что #1 временно заблокирован. Что в таком случае будет?AutoGrow для #2… и повторная задержка при выполнении запросов. Для таких случаев, был предусмотрен TF 1117. Работал он глобально и при нехватке места в одном файле вызывал AutoGrow для всех файлов в рамках одной файловой группы.

В MS SQL Server 2016 данный трейс-флаг включен по умолчанию для tempdb и может избирательно настраиваться для пользовательских баз:
ALTER DATABASE test
MODIFY FILEGROUP [PRIMARY] AUTOGROW_ALL_FILES
GO
ALTER DATABASE test
MODIFY FILEGROUP [PRIMARY] AUTOGROW_SINGLE_FILE
GO

Посмотрим на размер файлов:
USE tempdb
GO

SELECT
name
, physical_name
, current_size_mb = ROUND(size * 8. / 1024, 0)
, auto_grow =
CASE WHEN is_percent_growth = 1
THEN CAST(growth AS VARCHAR(10)) + ‘%’
ELSE CAST(CAST(ROUND(growth * 8. / 1024, 0) AS INT) AS VARCHAR(10)) + ‘MB’
END
FROM sys.database_files
WHERE [type] = 0

name physical_name size_mb auto_grow
---------- --------------------------------------------------- -------- ------------
tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 8.000000 64MB
temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 8.000000 64MB
temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 8.000000 64MB
temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 8.000000 64MB

Создаем временную таблицу:
IF OBJECT_ID('#t') IS NOT NULL
DROP TABLE #t
GO

CREATE TABLE #t (
ID INT DEFAULT 1,
Value CHAR(8000) DEFAULT ‘X’
)
GO

INSERT INTO #t
SELECT TOP(10000) 1, ‘X’
FROM [master].dbo.spt_values c1
CROSS APPLY [master].dbo.spt_values c2

Места чтобы вставить данные не хватит и произойдет AutoGrow.

AUTOGROW_SINGLE_FILE:
name physical_name size_mb auto_grow
---------- --------------------------------------------------- ----------- ------------
tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 72.000000 64MB
temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 8.000000 64MB
temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 8.000000 64MB
temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 8.000000 64MB

AUTOGROW_ALL_FILES:
name physical_name size_mb auto_grow
---------- --------------------------------------------------- ----------- ------------
tempdev D:\DATABASES\SQL_2016RC0\TEMP\tempdb.mdf 72.000000 64MB
temp2 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_2.ndf 72.000000 64MB
temp3 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_3.ndf 72.000000 64MB
temp4 D:\DATABASES\SQL_2016RC0\TEMP\tempdb_mssql_4.ndf 72.000000 64MB

Флаг трассировки 8048

В случае, если в вашей системе более 8 логических процессоров и наблюдается большое число ожиданий CMEMTHREAD и кратковременных блокировок:
SELECT waiting_tasks_count
FROM sys.dm_os_wait_stats
WHERE wait_type = 'CMEMTHREAD'
AND waiting_tasks_count > 0

SELECT spins
FROM sys.dm_os_spinlock_stats
WHERE name = ‘SOS_SUSPEND_QUEUE’
AND spins > 0

то использование TF 8048 помогает избавиться от проблем с производительностью.

В SQL Server 2016 данный трейс флаг включен по умолчанию.

флаг трассировки -T1118

-T1118

SQL Server вычитывает данные с диска кусками по 64Кб (так называемыми экстентами). Экстент – это группа из восьми физически последовательных страниц (по 8Кб каждая) файлов базы данных.

Имеются два типа экстентов: смешанные и однородные. На смешанном экстенте могут храниться страницы с разных объектов. Такое поведение позволяет очень маленьким таблицам занимать минимальное количество места. Но чаще всего таблицы не ограничиваются размером в 64Кб и когда требуется более 8 страниц для хранения данных по одному объекту, то происходит переключение на выделение однородных экстентов.

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

DBCC TRACEON (1118, -1);
GO

В 2016 версии такого уже не будет. Но для каждой пользовательской базы можно задать опцию MIXED_PAGE_ALLOCATION

смотрите также http://www.gilev.ru/trace2371/

Особенности работы сеансов по рабочим процессам

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

Проблемы при наличии двух сетевых карт на сервере

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

Одной из рекомендаций является понизить приоритет протокола ipv6 или выключить его совсем.

В ряде случаев эти ошибки обусловлены тем, что клиент запрашивает у сервера его адрес, а сервер вместо адреса в формате IPv4 вида 192.168.1.2 возвращает адрес в формате IPv6 в формате вида ::1 или fe80::e168:38a1:5a4d:d271%40 (адреса взяты для примера, ключевое там — много групп цифр, разделённых вместо точек двоеточиями).
Увидеть это можно, выполнив в командной строке команду
ping servername
где вместо servername надо подставить имя своего сервера. Если ответ будет в формате IPv6 — ваш сервер тоже может быть подвержен такой проблеме.

Ранее в нашем блоге давалось решение вида «отключить протокол IPv6 полностью»: http://www.gilev.ru/disableipv6/, на Инфостарте проблема тоже обсуждалась: http://infostart.ru/public/160388/, решений приводилось два — полное отключение протокола IPv6 полностью, и занесение IP-адреса сервера в файл hosts.
Первое решение может быть неудобно тем, что как минимум требует перезагрузить сервер, второе может быть неудобно или даже неработоспособно в случае нахождения сервера в нескольких подсетях одновременно (например, несколько сетевых карт).

А вот теперь сообщаем более технологичное решениепросто повысить приоритет протокола IPv4 над протоколом IPv6, тем не менее сохранив работоспособность IPv6. Решение не требует перезагрузки, вступает в действие моментально. Нужно открыть командную строку в режиме администратора, и выполнить там две команды:
netsh interface ipv6 set prefix ::/96 60 3
netsh interface ipv6 set prefix ::ffff:0:0/96 55 4

Всё, работает! Проверим на примере «чистой» Windows 2012 Server (жирным выделены команды, дальше в сокращённом виде приводится ответ операционной системы):

ping gilev_test
Обмен пакетами с gilev_test [fe80::21c0:ff89:967f:955a%19] с 32 байтами данных:
Ответ от fe80::21c0:ff89:967f:955a%19: время<1мс

Итак, возвращается адрес в формате IPv6 (fe80::21c0:ff89:967f:955a%19).Применим наше лекарство:

netsh interface ipv6 set prefix ::/96 60 3
ОК.

netsh interface ipv6 set prefix ::ffff:0:0/96 55 4
ОК.

Снова проверим ping:

ping gilev_test
Обмен пакетами с gilev_test [192.168.1.5] с 32 байтами данных:
Ответ от 192.168.1.5: число байт=32 время<1мс TTL=128

Как видим — результат резко изменился в нужную нам сторону, стал возвращаться адрес 192.168.1.5. Теперь проверим, что по адресу в формате IPv6 сервер по-прежнему пингуется, и мы ничего не сломали

ping fe80::21c0:ff89:967f:955a%19
Обмен пакетами с fe80::21c0:ff89:967f:955a%19 по с 32 байтами данных:
Ответ от fe80::21c0:ff89:967f:955a%19: время<1мс

P.S. в некоторых случаях если команды не помогли, то выполните дополнительную команду:
netsh interface ipv6 set prefix ::/96 1 3

Всё работает, как и должно быть. Пользуйтесь на здоровье!
Ваша команда Gilev.ru

Обнаружение повышения области блокировки таблицы

Определяем ID объекта — исследуемой таблицы в базе данных

USE [trade_debug] Select * from Sys.objects WHERE Sys.objects.name = ‘_Reference82’

где _Reference82 имя таблицы

ObjectID

Далее настраиваем трассировку SQL server profiler:
PRprop

Устанавливаем фильтр:

PRfilter

Отключение эскалации чревато дополнительной нагрузкой на сервер, это надо учитывать:

USE [trade_debug] ALTER TABLE _Reference82 SET (LOCK_ESCALATION = DISABLE)

Проверить режим эскалации блокировок можно с помощью скрипта:

USE [trade_debug] SELECT lock_escalation, lock_escalation_desc, name FROM sys.tables WHERE lock_escalation_desc=’DISABLE’

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

КЕЙС: Как мы ускорили обмены с 10 часов до нескольких минут

Если в Вашей компании используется обмен между информационной системой на платформе 1С:Предприятие 8 и сайтом, или вы интересуетесь приемами повышения производительности, то думаю, Вам будет интересно посмотреть, как мы решили следующую задачу.
Клиент обратился с проблемой неработающего обмена с сайтом.
В своей работе Заказчик использует информационную систему на основе «Управление торговлей ред. 11». Конфигурация регулярно выполняет обмен с сайтом. Обмен осуществляется через XML файлы и происходил очень долго. При выгрузке данных для сайта клиент столкнулся с тем, что скрипт загрузки со стороны сайта не успевал обработать выгруженные данные.
Чтобы улучшить ситуацию, Заказчик своими силами разбил выгрузку на порции. Но это не принесло полного решения проблемы.
Чтобы решить проблему, заказчик пригласил меня.
Если Вы не сталкивались с методами повышения производительности раньше, то отмечу, что так или иначе все сводится к нахождению «избыточной работы» и устранению ее.
Проблема оказалась комплексной. Со стороны 1С при выгрузке в файлы попадала избыточная информация. Т.е. передавалось больше данных, чем потом реально использовалось. А со стороны сайта модуль загрузки выполнял лишние действия.
Кроме этого, сама выгрузка, даже по небольшому количеству товаров, занимала длительное время.
Чтобы понять, «какая деятельность лишняя», нужно посмотреть максимально подробно, из чего состоит вся процедура выгрузки данных.
Замер производительности «отладчиком» операции «выгрузки» показал следующее распределение длительности между операциями. 80% времени выполнялся запрос, собирающий данные для выгрузки. Мне повезло, так как 80% времени означает, что если улучшить этот запрос, то можно не прилагать много усилий к другим операциям, ведь эффект на всю выгрузку будет виден сразу. Еще 14% процентов замера выгрузки проверялось какое-то условие. Возможно, на результаты замера свое влияние оказала посторонняя нагрузка (замер выполнялся не «в чистых условиях», на сервере работали и другие пользователи), но этот замер дал представление о проблеме.
Замер до оптимизации
Самой простой проблемой оказалось условие «Если». Полностью условие выглядело так:
Если Параметры.РежимПошаговойВыгрузки
    И НЕ Параметры.ВыгружатьКраткийПакетПредложенийВРежимеИзменений
    И НеОпределено = ВыгруженныеТовары.Найти(Параметры.ВыборкаЦен.Номенклатура) Тогда
Проблема заключалась в выражении ВыгруженныеТовары.Найти(Параметры.ВыборкаЦен.Номенклатура)
Здесь ВыгруженныеТовары — это массив позиций номенклатуры, выгружаемой на текущем шаге. Количество элементов задается в параметрах выгрузки и составляет 400. То есть количество невелико.
Данные этого массива в процедуре никак не использовались, поэтому было решено заменить массив на соответствие. Соответствие представляет собой индексированную коллекцию, и поиск по ней выполняется очень быстро.
В качестве ключа использовал ссылку на номенклатуру, а значение «Истина». После доработки условие стало выглядеть так:
Если Параметры.РежимПошаговойВыгрузки
    И НЕ Параметры.ВыгружатьКраткийПакетПредложенийВРежимеИзменений
    И НеОпределено = ВыгруженныеТовары[Параметры.ВыборкаЦен.Номенклатура] Тогда
и общее время  по этому выражению составило 34 секунды.
Количество повторений этого фрагмента определяется исходным алгоритмом.
Вторым проблемным фрагментом по замеру является запрос, выполняющий сбор данных для выгрузки.
 МассивРезультатовЗапроса = Запрос.ВыполнитьПакет();
В данном замере время его выполнения составило  более 8 часов. Запрос представляет из себя пакет из более 30 запросов.
Часть данного запроса получается на основе схемы компоновки данных с применением отборов. Отбор накладывается по номенклатуре по условию «в группе». При компоновке макета компоновщик, по возможности, добавляет в результирующий запрос условия, соответствующие отбору.
Например, запрос такого вида:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
                СвободныеОстаткиОстатки.Номенклатура КАК Номенклатура,
                СвободныеОстаткиОстатки.Характеристика КАК Характеристика,
                СвободныеОстаткиОстатки.ВНаличииОстаток КАК ВНаличииОстаток,
                СвободныеОстаткиОстатки.ВРезервеОстаток КАК ВРезервеОстаток
ПОМЕСТИТЬ ВремОстатки
ИЗ
                РегистрНакопления.СвободныеОстатки.Остатки() КАК СвободныеОстаткиОстатки
 после применения отбора примет такой вид:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
                СвободныеОстаткиОстатки.Номенклатура КАК Номенклатура,
                СвободныеОстаткиОстатки.Характеристика КАК Характеристика,
                СвободныеОстаткиОстатки.ВНаличииОстаток КАК ВНаличииОстаток,
                СвободныеОстаткиОстатки.ВРезервеОстаток КАК ВРезервеОстаток
ПОМЕСТИТЬ ВремОстатки
ИЗ
                РегистрНакопления.СвободныеОстатки.Остатки(,Номенклатура В ИЕРАРХИИ (&amp;П)) КАК СвободныеОстаткиОстатки
 После компоновки данных это условие добавилось к нескольким запросам с полем номенклатура. Данное условие плохо сказывается на скорости выполнения запросов.
Чтобы решить эту проблему, в исходный запрос схемы компоновки данных добавил запрос выборки номенклатуры во временную таблицу. И уже данные этой таблицы использовал в качестве фильтра в последующих запросах. Также настроил схему компоновки данных таким образом, чтобы отбор по номенклатуре применялся только для добавленного запроса выборки номенклатуры. После этих манипуляций результирующий запрос принял такой вид (фрагмент):
ВЫБРАТЬ
                Номенклатура.Ссылка
ПОМЕСТИТЬ втНоменклатура
ИЗ
                Справочник.Номенклатура КАК Номенклатура
ГДЕ
                Номенклатура.Ссылка В ИЕРАРХИИ(&amp;П)

;

ВЫБРАТЬ РАЗРЕШЕННЫЕ
                СвободныеОстаткиОстатки.Номенклатура КАК Номенклатура,
                СвободныеОстаткиОстатки.Характеристика КАК Характеристика,
                СвободныеОстаткиОстатки.ВНаличииОстаток КАК ВНаличииОстаток,
                СвободныеОстаткиОстатки.ВРезервеОстаток КАК ВРезервеОстаток
ПОМЕСТИТЬ ВремОстатки
ИЗ
                РегистрНакопления.СвободныеОстатки.Остатки(,Номенклатура В (ВЫБРАТЬ т.Ссылка ИЗ втНоменклатура как т)) КАК СвободныеОстаткиОстатки
 Также анализ запроса выявил и другие причины его медленного выполнения:
  • Соединение с подзапросами
  • Отсутствующие или неоптимальные индексы
  • Излишняя выборка данных
В общем, классика жанра.
Решив данные проблемы в комплексе, удалось сократить время выполнения результирующего запроса при полной выгрузке до 78 секунд.
Говоря об оптимизации в теоретическом контексте, часто забывается, что в реальной жизни любая коммерческая работа должна быть рентабельна. Несколько запросов пакета еще имели потенциал для ускорения, но полученный результат полностью устроил клиента, и на этом мы остановились.
Замер после оптимизации
После оптимизации время полной выгрузки не превышает 5 минут. Время выгрузки тестовой группы из 15 товаров – несколько секунд (до оптимизации –1.5 минуты).
Заказчик остался очень доволен и сказал много теплых слов. Всегда приятно не просто сделать хорошо работу, но и услышать слова благодарности.
Надеюсь, мой опыт пригодится Вам, и Вы тоже сможете помочь решить подобные проблемы.

 

Отзыв на курс Кухара Богдана «23 способа ускорить 1С»

С чего все началось с того, что по инерции ухватился за слова «ускорить работу 1с»

реклама на мисте   за регистрировался по ссылке и получил письмо на скачку видео

получил симпатичное письмо     ну собственно и посмотрел само видео

видео Кухара Богдана

Мы благодарны за то, что  Богдан попросил / разрешил дать обратную связь

отзыв   что с удовольствием и сделаем:

способ 1 от Кухара На работу пользователей влияет много факторов. Покупать лицензии на терминальный сервер, не проведя предварительно анализа причин замедления — деньги на ветер. Точнее это как в рулетку «повезет / не повезет».

Каким плюсом обладает терминальный сервер — он предоставляет пользователям «примерно равные по мощности аппаратные ресурсы». Естественно, если частота процессора на терминальном сервере будет выше чем на Вашем ноутбуке, то это может дать эффект. Все же логично, вы подключаетесь с более мощного компьютера по факту. Но для этого еще надо купить более мощный терминальный сервер. Если например на вашем ноутбуке будет частота 3,5 Гц, а на терминальном сервере 1,8 Гц, то Вы наверняка не улучшите, а ухудшите производительность. Дьявол в деталях.

Еще один момент — это физическая удаленность пользователя от сервера 1С:Предприятие. Использовать терминальный сервер имеет смысл, если он находится на том же «роутере / маршрутизаторе» что и сервер 1С, а компьютеры пользователей например в другом сегменте сети. Если компьютеры пользователей находятся также как и терминальный сервер в одном сегменте сети, не факт, что вы получите выигрыш от терминального сервера. Если Вы уверены, что с терминального сервера будет «быстрее», то до разворачивания службы терминалов зайдите на сервер под пользователем с правами локального администратора и запустите 1С:Предприятие — убедитесь в своей правоте на практике!

Способ 2 от Богдана Иногда люди легко попадаются на уловки маркетологов.

Можно сказать что будет «быстрее» и многие забывают куда более важный вопрос «А на сколько быстрее?».

Есть очень простой способ — запустить нагрузочный тест http://www.gilev.ru/tpc1cgilv/  в обычном варианте, и по методу 2 от Богдана. Что получилось у Вас?

Совет 3 от Богдана Хочется подколоть » запустил дефрагментацию на своем OCZ Vector, не помогло, что я делаю не так?»

Для тех кто не в курсе, на SSD полностью занятое пространство куда больше имеет эффекта на производительность. А вот с дефграментацией особо толку не будет.

Ради справедливости надо сказать, что если Вы на MS SQL Server решили использовать обычные HDD, то просто сразу отдавайте файлу весь диск или максимально много. Не делайте «шринк» базы данных! Тоже относится к tempdb!

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

Если говорить более широко, ЛЮБАЯ ФУНКЦИОНАЛЬНОСТЬ ТРЕБУЕТ РЕСУРСОВ.

На самом деле рекомендуем не ставить со скулем ни каких других ролей сервера. Чем большей ролей, тем больше они будут конкурировать за ресурсы сервера. И фтп сервер, и почтовый сервер и все что угодно будет создавать замедление. Чем активней другая роль, тем меньше достанется СУБД ресурсов.

Совет 5   Вообщем то совет пересекается с высказанным ранее — отключайте любой функционал, который не используете.

Все что работает «фоном» и потребляет ресурсы, уменьшает их для основных задач.

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

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

Совет 6 Звучит как  «перепишите Вашу программу» 🙂

На текущий момент по нашему опыту скорость в «толстом» клиенте по отрисовке интерфейса работает быстрее нежели в «управляемых формах». С высокой вероятностью вы получите обратный эффект.

Совет 7 Вообще использовать веб-сервер надо осторожно. Если у Вас все пользователи в локальной сети, то это фактически «лишнее звено».

Процитирую партнерский форум 1С https://partners.v8.1c.ru/forum/topic/1187394 о медленной работе веб-браузера «Проблема нам известна. Считаем ее достаточно важной.На данный момент ведутся задачи по данному направлению.»

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

Совет 8   Капитан очевидность — хороший вообщем то совет, только звучит более правильно он так «попробуйте разные варианты, выберите лучший» )))

Совет 9 Следуйте этому совету, если хотите себя дискредитировать. Быстрее работает то ПО, которое обладает меньшим функционалом как правило. Чем меньше функций программа умеет выполнять тем она быстрее работает.

Только вот ведь загвоздка, обычно бизнесу нужна не только производительность, но

1. отказоустойчивость

2. техподдержка продукта

3. безопасность

4. наличие специалистов

5. совместимость с другими приложениями

Хотите проблемы, ставьте старое ПО, все ошибки, которые исправлены в более поздних версиях, там будут Вам доступны!

Способ 10 ускорить 1с   Хочется напомнить про наши комментарии к способу №3 — заранее выделите нужное дисковое пространство под данные и логи, не изобретайте велосипед!

Способ 11 увеличить быстродействие 1с О! И снова об избыточном функционале.

Избыточность вредна. Но не нравится сам подход на этом слайде.

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

Если Вы начинающий админ, лучше оставьте галочки «по умолчанию», не торопитесь ломать систему.

Способ 12 Для начало надо объяснить, что MS SQL Server смотрит на возможности процессора (количество ядер) и сам автоматически прикидывает, какое количество рабочих потоков он сможет обслужить. При этом ресурсы под каждое соединение выделяются по мере их создания, а не заранее. Зная как работает 1С:Предприятие, только если у Вас сотни пользователей массово запускают 1с или очень активно пишут данные, есть смысл ковырять эти настройки. В большинстве случаев вы ничего не заметите.

Совет 13 по тюнингу 1с Вообщем то не плохой совет. Но сильного «буста» вы не увидите скорее всего. Это сработает на «слабых» серверах. Если у Вас слабый сервер, лучше обновите железо, это дальновидней.

Совет 14 оптимизации 1с Жуть, зачем блокировать базу? Используйте время минимальной загруженности. Если таблицы и индексы большие, то не надо все за один раз, в разное время обслуживайте разные объекты. Да, и переиндексацию надо делать не «тупо» раз в какой то период, а по мере набегания этой самой дефраментации индексов. Для анализа этой ситуации используйте http://www.gilev.ru/sqlsize/

Совет 15 Вообщем то если купить более быстрый диск то будет быстрее. Но у вот у нас к примеру уже SSD. И кстати, куда больше пользы для потоковой скорости 1С даст частота процессора как ни странно, обязательно изучите http://www.gilev.ru/bestproc1c/ наши рекомендации по подбору процессора, это 50% всей производительности железа.

Совет 16 как ускорить 1с Хороший способ. Только применять надо по другому — кладите туда tempdb!

А еще более актуальный вариант в ближайший год будет это использовать SSD для «расширенного буферного пула» в MS SQL Server 2014.

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

Способ 17 повышение производительности 1с Ну да, еще купите дисков, потому в 10 рейде например 3 диска 5го рейда заюзать не получится. А для SSD использование рейд-массивов это вообще отдельная история, они обычно в этом случаи изнашиваются зеркально ). Можно еще раз сказать про капитана очевидность — купите мощнее сервера!

Совет 18   Обычно виртуальные машины нужны не для повышения производительности, а для решения других задач:

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

— организовать отказоустойчивость

— организовать облако и быстрое выделение нужных мощностей

Ну если Вы хотите порушить решаемые задачи, тогда этот совет для Вас!

Способ 19 повышение быстродействия 1с Наверное эзотерические знания это не плохо. Не очень понятно, как на фоне покупки SSD, использования 10 рейда вместо 5го выглядит «слабый» сервер, но уж точно не надо перемещать на компьютер пользователя: — компьютер пользователя не оптимизирован под коллективную конкуренцию ресурсов; — на нем стоит не серверная операционная система, которая просто не позволит вам больше 10 подключений — пользовательский компьютер на ночь часто выключают — еще компьютер пользователя можно «тупо вынести с предприятия», а заодно пароли и т.п. — как вы будете отвечать за компьютер, на котором помимо сервера 1с еще работает другой пользователь, вы думаете он ребутнет, не сможет подвесить систему или запустить торрент на закачку фильмов?

Совет 20 оптимизации 1с Ну вот на самом деле здесь бы как раз порекомендовать использовать терминальный сервер и нет проблем. Используйте вай-фай!

Совет 21 улучшение 1с Ну вот это спорный момент. К пример у вас на сервере 100 баз размером 10 Гб каждой базы данных. Из этой логики нормально будет иметь оперативки 10-20 Гб. Советуем ориентироваться на показатели «Частоты попадания в кэш» у MS SQL Server, если активной подкачки с диска нет, значит памяти хватает.  Но спорить с тем что чем больше памяти тем лучше не будем. Сквозь весь курс проходит красной линией «купите мощнее сервер»…

Совет 22 Чтобы 1с работала лучше

Ну тут можно дать и более радикальный совет. Всегда ограничивайте MS SQL Server по максимальному объему оперативной памяти таким образом, чтобы операционной системе оставалось 5-10% от общего объема оперативной памяти (в том числе для нужд подкачки) , и не менее 2 Гб при этом.

Совет 23

 

Особенностям производительности файлового и клиент-серверного варианта посвящена очень хорошая статья http://www.gilev.ru/mssqlvsfile/ . Мы получили много откликов и только больше убедились в том, что лучший способ не искать «более хорошую программу», а разбирать проблемы, выяснять причины и устранять их.

Если вы думаете что замена MS SQL Server на Оракл или DB2 что то улучшит, то это мы хотим сэкономить Вам кучу времени и денег — правьте код 1С а  не меняйте MS SQL Server на что то другое!

Есть ли смысл комментировать, если не писать конструктивно. А теперь

НЕСКОЛЬКО СОВЕТОВ ОТ НАС:

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

Совет 2. Найдите самое узкое место. При чем и в железе, и в коде.

Используйте http://www.gilev.ru/querytj/ ,  http://www.gilev.ru/hardware/ . Начните устранять проблему с самого узкого места.

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

Совет 4. Если Вы администратор, сервера не загружены, а 1с «висит», не надо занимать позицию «я вот отвечаю за это, поэтому чем смогу помогу». Зовите программистов. В конце концов позовите нас!

Совет 5. Дорогой сервер — не означает что самый быстрый сервер. Разные конфигурации 1С могут по-разному нагружать аппаратные ресурсы. Делайте тест-драйв покупаемых серверов и проводите нагрузочное тестирование.

Совет 6. Если у Вас в системе много взаимоблокировок, а конфигурация на управляемых блокировках, включите версионирование. Это даже если не устранит проблему, то поможет ее быстрее локализовать. Если блокируемые ресурсы используют чтение, то версионирование устранит взаимоблокировки субд. Иначе у вас блокировки только блокировки на запись, вам надо уменьшать время транзакций (например разбивать на более мелкие порции записываемые данные). Используйте http://www.gilev.ru/deadlock/ для дальнейшего анализа.

Совет 7. Консультируйтесь не у толпы по вопросам производительности, у толпы нет финансовой ответственности за сказанное! Спрашивайте тех, кто занимается каждый день, в том числе нашей команда http://www.gilev.ru/forum/. Мы как минимум рискуем репутацией. В платных аудитах и работах мы несем денежные гарантии!

 

 

 

 

 

Медленное подключение по RDP из Windows 7 к серверу Windows Server 2003

пример http://social.technet.microsoft.com/Forums/ru-RU/03869b70-6e56-4f98-9bdc-25c65da7c72f/-

На клиенте Windows7 выполните

netsh interface tcp set global autotuninglevel=disabled
Если не поможет, дополнительно выполните

netsh interface tcp set global rss=highlyrestricted

 

Перемещение системной базы tempdb в MS SQL Server

 

TEMPDB представляет собой системную базу данных Microsoft SQL Server, в которой хранятся временные таблицы, созданные как самим сервером, так и пользователями. Эта база данных создается заново при каждом перезапуске Microsoft SQL Server. По умолчанию размер этой базы данных неограничен и увеличение его осуществляется при необходимости автоматически, порциями по 10% от текущего размера TEMPDB. Однако эти параметры могут быть переопределены пользователем. По умолчанию, минимальный размер этой базы данных, который устанавливается при старте Microsoft SQL Server, определяется размером системной базы данных MODEL. Очистка журнала транзакций в этой базе данных производится автоматически, при этом удаляются только неактивные записи журнала транзакций.
При работе 1С:Предприятия 8 в режиме клиент-сервер используются временные таблицы и переменные table. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п.
Проблема:
В процессе работы 1С:Предприятия 8.1 возможно значительное увеличение размера базы данных TEMPDB. Если размер диска, на котором расположена база данных TEMPDB, окажется недостаточным, работа 1С:Предприятия 8.1 может завершиться аварийно.
Решение:
Если эта проблема проявляется регулярно, то рекомендуется переместить TEMPDB на другой диск большего размера.
Эту операцию можно выполнить следующим способом:
определить логические имена файлов базы данных TEMPDB (колонка «NAME» результата выполнения процедуры). Для этого нужно в Query Analyzer выполнить следующую команду:

USE tempdb
GO
EXEC sp_helpfile
GO

изменить месторасположение файлов базы данных TEMPDB с помощью команды ALTER DATABASE. Для этого нужно в Query Analyzer выполнить следующую последовательность команд: USE master
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = ‘Новый_Диск:\Новый_Каталог\tempdb.mdf’)
GO
ALTER DATABASE  tempdb
MODIFY FILE (NAME = templog, FILENAME = ‘Новый_Диск:\Новый_Каталог\templog.ldf’)
GO

Если в результате перемещения у Вас перестал запускаться MS SQL Server, то смотрите http://www.gilev.ru/repeartempdb/

 

Влияние HDD на быстродействие 1С:Предприятие 8

О чем пойдет речь

Только вариант клиент-серверной версии 1C:Предприятие 8 под MS SQL Server.

Только кластеры NTFS и блоки RAID-массива (пусть даже это RAID0 из одного диска) в операционных системах Windows Server 2003 (и Windows XP).

Внимание! Действие статьи не распространяется на RAW-партиции и простые диски HDD, не входящие ни в какой RAID-массив с собственным контроллером.

Также маловероятна проблема в в Windows Server 2008 и Windows Vista.

Предмет оптимизации

«Размер блока и размер кластера желательно устанавливать одинаковыми, например, для баз данных SQL Server очень часто слышны рекомендации выбирать и там и там 64Кб. Однако, операционная система создает самый первый кластер (блок начальной загрузки MBR) размером в 63Кб. Эта особенность NTFS означает, что каждый последующий кластер будет сдвинут на 1Кб на предыдущий блок. Т.е. кластеры окажутся смещёнными относительно границ блоков массива. Такая ситуация приводит к тому, что одна операция чтения или записи кластера будет затрагивать два сектора и будет приводить к удвоению числа запросов ввода-вывода.»(цитата Александра Гладченко).

Источник Disk Partition Alignment for SQL Server (eng) и http://sqlblog.com/blogs/linchi_shea/archive/2007/02/01/performance-impact-of-disk-misalignment.aspx

Официальное подтверждение проблемы Microsoft и тут.

Средняя степень влияния

Практически все основные типы нагрузки ввода-вывода SQL Server получат выигрыш от этой оптимизации от 9 до 23%.

Способы определить наличие проблемы

1. С помощью DiskPart (Описание программы http://technet.microsoft.com/ru-ru/library/cc773140.aspx и http://support.microsoft.com/kb/300415/ru).

diskpart -i

Наличие цифры 32256 (потому что смещение offset 32256 / 512 байт на сектор = 63).

2. С помощью утилиты DiskExt.

3. С помощью обработки для 1С:Предприятие 8.1 NTFS.epf

Необходимо исправить геометрию RAID массива

1. Скопировать ВСЮ информацию с диска (предположим, что имя диска D:) на другой локальный диск (например диск E:) используя команду xcopy с параметрами копирования файлов и каталогов включая ownership и ACL.

xcopy D:\*.* E:\DiskD /E /K /O /X

Запустить Disk Management и посмотреть какой физический диск соответствует логическому диску D; допустим это диск 1.

Запустить Disk Management и удалить логический раздел D на физическом диске 1. (Т.е. чтобы выровнять раздел, нужно удалить смещённый раздел).

2) Внимание! Утилита DISKPART уничтожит данные на диске.

В командной строке запустить утилиту DISKPART и выполнить следующие команды:

DISKPART> select disk 1

Disk 1 is now the selected disk.

DISKPART> create partition primary align=64

DiskPart succeeded in creating the specified partition.

DISKPART> exit

Примечание. Команда «create partition primary align=64» создает новый раздел со смещением первого кластера на 64Кб, что позволяет выровнять границы кластеров и блоков и тем самым оптимизировать работу дисковой подсистемы.

3) В Disk Management создать диск (отформатировать)

4) Скопировать файлы обратно (если есть такая необходимость)

xcopy E:\DiskD\*.* D:\ /E /K /O /X

Примечание. Описание xcopy.

Флаги трассировки MS SQL server 2008, влияющие на производительность

661: Disable the ghost record removal process

Флаг трассировки 661 отключает системный процесс удаления фантомных записей. Фантомные записи появляются в результате исполнения операций удаления, после которых удалённые записи могут оставаться в файле как фантомные записи. Через некоторое время, удаленные записи вычищаются процессом удаления фантомных записей. Когда этот процесс отключается, удаленные записи не вычищаются. Поэтому, место, которое занимают удаленные записи, не высвобождается. Это влияет на занимаемое данными место и на производительность операций просмотра.
Флаг трассировки 661 всегда действует в контексте всего сервера, т.е. имеет глобальный контекст. Вы можете включать флаг трассировки 661 при запуске сервера или в пользовательском сеансе.

834: Use Microsoft Windows large-page allocations for the buffer pool

Флаг трассировки 834 применяется в SQL Server 2008 для включения механизма распределения буферному пулу больших страницы памяти, которыми умеют оперировать последние версии Microsoft Windows. У разных аппаратных платформ может быть разный размер страниц, он может изменяться от 2 до 16 Мбайт. Большие страницы распределяются при запуске и сохраняются на протяжении всей жизни процесса. Флаг трассировки 834 повышает производительность, увеличивая эффективность TLB буфера процессоров.
Флаг трассировки 834 применим только к 64-битным версиям SQL Server 2008. Включить флаг трассировки 834 может только та учётная запись, для которой разрешена локальная политика «Lock pages in memory». Включать флаг трассировки 834 можно только при запуске SQL Server.
Флаг трассировки 834 может препятствовать запуску сервера, если память сильно фрагментирована и это мешает распределению больших страниц. Поэтому, флаг трассировки 834 безопаснее использовать на серверах, которые обслуживают только SQL Server 2008.
Для получения более подробной информации о поддержке больших страниц Windows, перейдите на следующую страницу сайта Microsoft Developer Network (MSDN): Large-Page Support.

3502: Log Database Checkpoint Start and End times in the SQL Server ErrorLog

Флаг трассировки 3502 не влияет на производительность, но он нужен для контроля выполнения эталонных тестов TPC. Этот флаг трассировки заставляет SQL Server регистрировать в SQL Server ErrorLog время начала и окончания работы системного процесса контрольной точки.

8744: Disable pre-fetching for ranges

Флаг трассировки 8744 отключает предварительную выборку для таких операторов, как «Nested Loops». Неуместное использование этого флага может спровоцировать дополнительные физические чтения, при реализации плана с оператором «Nested Loops«.
Когда флаг трассировки 8744 включён при запуске сервер, он получает глобальный контекст. Когда он включен в сеансе пользователя, контекст ограничивается сеансом.

смотрите также http://www.gilev.ru/escalation/