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

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

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

Реализована возможность определения IP-адреса компьютера, который начал сеанс работы с информационной базой. IP-адрес может быть определен не всегда и не для всех режимов работы.
Реализовано свойство IPАдресКлиента для объектов АдминистрированиеСеанс и СеансИнформационнойБазы.Реализована возможность отображения IP-адреса клиентского приложения в консоли управления кластером и стандартной обработке управления серверами.

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

Реализовано индексирование файлов журнала регистрации. Индексация выполняется в фоновом режиме. Индексы хранятся в файлах с расширением .lgx в каталоге 1Cv8Log. Оптимизированы алгоритмы последовательного чтения файлов журнала регистрации.
Никаких дополнительных настроек для включения индексации не требуется. За счет индексации существенно ускорен отбор записей журнала регистрации по индексируемым полям.При открытии в конфигураторе файла журнала регистрации другой информационной базы, индексирование данного файла выполняется в фоновом режиме и индексный файл стирается после завершения работы с просматриваемого журнала регистрации.Для новой информационной базы значение параметра Разделять хранение журнала по периодам устанавливается в значение Неделя. Для существующих информационных баз рекомендуется установить разделение таким образом, чтобы размер одного файла журнала не превышал 100 Мбайт. Прекращена поддержка журналов регистрации, сформированных в системе «1С:Предприятие» версий 8.0 и 8.1.

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

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

Оптимизировано сравнение составных типов с не составными, если не составной тип может принимать значение NULL и в запросе используются временные таблицы.
Оптимизированы следующие операции:Сравнение вида A = B, где A – составной тип, а B – простой тип и может принимать значение NULL.
Сравнение вида ЕСТЬNULL(A, B) = C, где A – простой тип и может принимать значение NULL, а C – составной тип.
Сравнение вида Выражение1 В (ВЫБРАТЬ ….) и сравнение вида Выражение1 В (Список значений), где Выражение1 – поле ссылочного типа на несколько таблиц. При этом в списке выборки подзапроса или в списке значений должны находиться ссылки на разные таблицы и отсутствовать значение Неопределено.
Оптимизация применяется только в тех случаях, когда это не влияет на результат запроса. Оптимизация может привести к улучшению плана запроса и уменьшению времени компиляции запроса.

Если в запросе используется сравнение с пустой ссылкой, переданной в качестве параметра, то в СУБД передается запрос, в котором параметр заменен на константу. Оптимизация применяется в том случае, если кластер серверов использует СУБД IBM DB2, Microsoft SQL Server или Oracle Database.

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

При использовании файлового или клиент-серверного варианта (при использовании СУБД Microsoft SQL Server) оператор языка запросов В, который отвечает всем следующим критериям, всегда возвращает значение типа Булево:
Оператор В содержит подзапрос.
Подзапрос оператора В содержит операции ПЕРВЫЕ или УПОРЯДОЧИТЬ ПО.
В левой части оператора В и подзапросе содержатся значения разных типов или тип ЛюбаяСсылка.
Рекомендуется проанализировать подобные запросы и выполнить их рефакторинг, при необходимости. В режиме совместимости с версией 8.3.16 поведение не изменилось.

Библиотека OpenSSL обновлена до версии 1.1.0k.

Реализована возможность работы с СУБД Microsoft SQL Server 2019.

 

Подробнее:

https://dl03.1c.ru/content/Platform/8_3_17_1386/1cv8upd_8_3_17_1386.htm#19110485-11e0-11ea-8371-0050569f678a

 

Зачем аппаратному 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.14

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

Реализован упрощенный OLAP . Теперь можно работать на чтение с копией таблицы с ведомой СУБД.
Реализовано событие технологического журнала <DBCOPIES>.Механизм копий базы данных требует лицензию КОРП.

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

Добавлен альтернативный механизм управления сервером 1С программно и кроссплатформенно, реализован объект АдминистрированиеСервера . Дополнительно смотрите https://wonderland.v8.1c.ru/blog/razvitie-klastera-serverov/

Улучшен механизм счетчиков  потребления ресурсов — реализована возможность отбора по признаку использования безопасного режима работы и профиля безопасности (добавлены новые типы фильтров).Для выражений отбора счетчика потребления ресурсов реализована возможность сравнения на неравенство. Для выражений отбора счетчика потребления ресурсов реализована возможность объединять «по И» несколько условий на один тип фильтра.

Реализован пакетный режим работы тонкого и толстого клиентских приложений. Пакетный режим распространяется от начала запуска клиентского приложения до окончания работы обработчика ПередНачаломРаботыСистемы модуля приложения. После окончания работы обработчика пакетный режим автоматически отключается. В пакетном режиме запуска подавляется вывод любых диалогов системы. Признаком пакетного режима работы клиентского приложения является команда командной строки запуска /DisableStartupDialogs.

Больше не поддерживается интерфейс 8.2

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

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

Ускорено выполнение реструктуризации информационной базы при использовании СУБД Microsoft SQL Server и IBM DB2.

Уменьшилась вероятность одновременного закрытия множества соединений с Microsoft SQL Server, что положительно влияет на производительность работы с TempDB.

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

Для динамического списка реализована возможность указания полей, которые будут использоваться в качестве ключевых полей выборки. Повышена производительность при использовании динамических списков с отсутствующей основной таблицей. Например, для динамического списка без основной таблицы, стало возможно использование группировки. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/razvitie-dinamicheskikh-spiskov-s-proizvolnymi-zaprosami/

 Больше не поддерживается IE. У поля, имеющего вид ПолеHTMLДокумента, изменится с COMОбъект на ВнешнийОбъект. Ухудшится Windows-совместимость. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/perevod-klientskikh-prilozheniy-dlya-windows-na-ispolzovanie-webkit-optimizatsiya-otobrazheniya-html/

В тонком, толстом и веб-клиентах, форма снимает блокировку объекта через 1 минуту после снятия признака модифицированности.(раньше снималась при закрытии формы)При работе под управлением СУБД PostgreSQL, в технологический журнал (событие <plansql>) помещаются планы запросов для запросов UPDATEDELETE и INSERT. (Раньше был только SELECT)

 Реализовано отображение критических ошибок оптимизированного механизма обновления конфигурации базы данных в конфигураторе и в событии <EXCP> технологического журнала.

В технологическом журнале реализованы свойства DbmsDatabaseDBCopy для событий обращения к СУБД (DB2DBMSSQLDBPOSTGRSDBORACLE), событий EXCP и SDBL.

 Добавлен Механизм решения систем линейных алгебраических уравнений

смотрите https://wonderland.v8.1c.ru/blog/mekhanizm-resheniya-sistem-lineynykh-algebraicheskikh-uravneniy/

Подробнее http://downloads.v8.1c.ru/content//Platform/8_3_14_1565/1cv8upd_8_3_14_1565.htm

Особенности 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>.


Что такое производительность 1С

В нашей практике часто бывает так, что клиент не может самостоятельно сформулировать проблемы производительности. Как ему помочь?
Реальные клиенты не читали книжку 1С-Эксперт, ни один нормальный руководитель при решении этой задачи никогда не будет читать пункт 2.4 данной книжки, который называется “Бизнес-процесс решения проблем по ключевым операциям”.
Прежде чем начать что-то исправлять – надо сначала помочь клиенту сформулировать свои желания в критериях, которые можно объективно измерить. Есть огромное желание не делать данный пункт, пропустить его, так как он не кажется важным. И только многократный реальный печальный опыт может нас в этом переубедить, что мы вам дальше и покажем. Если нет объективных критериев – клиент (или пользователь клиента) всегда может потом сказать, что либо лучше не стало, либо сразу так хорошо было.
Есть другой ряд проблем, который менее очевидно и связан с формализмом при реализации данной методики.
Например, мы подпиской на все события проведения документов собираем статистику проведения данных документов. При анализе собранных значений, например по документу реализации товаров и услуг, может выясниться, что проведение этой операции имеет несколько явных пиков в районе 2 секунд, 10 секунд и 50 секунд. То есть ряд пользователей, как правило, видит время в районе 2 секунд, значительная часть пользователей видит время в районе 10 секунд, а часть в районе 50 секунд. При этом нельзя сказать, что такое разное поведение связано с конкретными пользователями. Одна из проблем, которая возникает при формализме, связана с нежеланием вникать в детали. Например, скорость может сильно зависеть от количества строк в табличных частях документа. Логично будет ожидать, что документ с десятком строк в ТЧ будет проводиться в течение нескольких секунд, в то время как 9000 строк вряд ли проведутся за то же время.
Конечно, бизнес может не различать объём или количество строк в ТЧ и для него критична любая операция, которая длится более пяти секунд, так как по каким-то специфичным особенностям бизнеса более долгая операция может приводить к возникновению убытка. Но в любом случае, в поиске решения нам придётся показать бизнесу, что решение напрямую связано с составом ТЧ и количеством строк в ней.
Хотелось бы пару фраз рассказать о выражении «плохой код»: разные пользователи информационной системы давать оценку качеству кода могут диаметрально противоположную. Настоящей дилеммой является выбрать приоритеты между скоростью работы каждого конкретного пользователя, или их одновременной коллективной работе и взаимодействием друг с другом. Одни задачи требуют максимальной производительности в рамках одного потока, например какая-то массивная загрузка данных, расчёт себестоимости. Другие задачи требуют аккуратного, не чрезмерного обращения к данным, неиспользование всех аппаратных ресурсов, чтобы обеспечить возможность коллективной работы в одной информационной системе на одном сервере всех пользователей. Далеко не всегда можно например сказать, что квотирование ресурсов целесообразно для решения однопоточной задачи, где важно как можно быстрее получить результат. Возникает необходимость на уровне бизнеса расставить приоритеты. Будет ли эта однопоточная задача важнее коллективной работы, или эта работа важнее однопоточной задачи.
Вот на слайде приведён пример однопоточной задачи, которая важнее коллективной работы.
Ещё один яркий пример неоднозначности того, что можно считать плохим кодом, является алгоритм партионного учёта (ФИФО/ЛИФО). Данный алгоритм может быть реализован различными способами, но при этом изначально задача партионного учёта для правильной работы требует монопольного захвата конкретной партии. С точки зрения алгоритма и целостности данных не могут два пользователя одновременно изменить информацию о партии. Однако, если подходить к этому вопросу с позиции коллективной работы, то должно быть очевидным, что требования алгоритма изначально являются плохими для обеспечения коллективной работы в этой информационной системе. На фоне выше сказанного можем привести пример реального кода, когда параллельность попираться совсем. В документах двигающих остатки в комплексной конфигурации перед тем как “свернуть резервы” накладывается блокировка на константу. У любой организации, у любых пользователей которые между собой не пересекаются блокировка все равно будет. Потому что блокируется константа — одна конкретная запись для любых документов данного вида, не зависимо от аналитики. И даже если такие документы будут быстро проводится, то о полноценной параллельности такого кода говорить не приходится, параллельности ввода данных нет.

Про виртуализацию и 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. Внутри тестовых серверов не происходит ничего, что могло бы объяснить такую разницу. Всё зависит от того, сколько и каких виртуалок ещё развёрнуто на тех же физических серверах, какую они генерируют загрузку процессоров, памяти, дисков и сети.
В жизни бывают ещё более сложные задачи, когда из-за несущественных на первый взгляд факторов может измениться скорость среды.

Как измерить всё?

Нередко клиенты к нам обращаются с формулировками вида “всё плохо” или “нет каких-то отдельных долгих операций, медленно работает всё”. Как замерять всё?

Возможно, вы ещё не сталкивались с такой ситуацией, но мы думаем, что вы с ней столкнётесь. Продавцы железа, которое вы приобрели, утверждают что оно замечательное. Продавцы ОС и бизнес-приложений тоже говорят, что у них всё хорошо работает. Согласно рекомендациям из книжки 1С-Эксперта, вы посмотрели: нет ли ярко выраженной долгой операции, и в коде нет явно лидирующих операций. Возможно, ваша виртуалка тоже замечательная. Нет ожиданий ни на процессоре, ни на дисках, ни на СУБД!
На бумаге всё замечательно, а по факту работает очень медленно.
Для решения проблемы в качестве начальной точки отсчёта мы много лет назад разработали тест, который стал в среде 1С-ников известен как “тест Гилёва”, и показывает способность системы выполнять эталонный объём работы за единицу времени. Можно по-разному объяснять популярность теста, но лучше мы покажем практические примеры его применения.
Приведу один из наиболее ярких примеров, когда благодаря этому тесту мы смогли с минимальными затратами денег и времени выявить проблему с аппаратной частью сервера:
Есть некий сервер в виртуальной среде, внутри сервера по счётчикам всё в рамках приличий — ровно как я и говорил чуть раньше: нет ожиданий на процессоре, нет ожиданий на дисках, нет ожиданий на СУБД. При этом в 1С всё работает страшно медленно и очень печально. Простой документ открывается по 5 секунд, а проводится 10 секунд, простой отчёт формируется по 30 секунд, при этом опять же замеры в 1С не показывают каких-то мега-лидирующих операций, просто всё выполняется долго. Пользователи очень недовольны, требуют жертвоприношений. Оборудование сервера при этом достаточно адекватное нагрузке, на других проектах с подобным оборудованием у пользователей картина производительности радикально лучше.
Результат нашего теста на тот момент составил абсолютный антирекорд, меньше мы за несколько лет ещё не встречали.
В очередной раз мы пронаблюдали, что оценка теста хорошо коррелирует с оценкой комфортности работы пользователей. Следственные действия внутри сервера не выявили явных виновников, поэтому попробовали искать их снаружи. Решили проверить фактор виртуальной среды, использованной клиентом. У клиента был ещё один сервер с аналогичным оборудованием, попросили развернуть на нём такую же систему, но без виртуализации, так сказать на голом железе. Результат нашего теста вырос во много раз по сравнению со своим виртуализованным двойником. Пользователи немедленно обнаружили, что без виртуализации всё летает, документы открываются и проводятся за секунду, отчёты формируются за несколько секунд.
Рассмотрим ещё один пример применения нашего теста для оценки влияния среды.
Вот сервер клиента, с неким процессором он дал результат в 12 баллов. По субъективной оценке нашего теста, это соответствует оценке “Плохо”. При этом настройки электропитания в Windows выставлены в “максимальная производительность”. Утилита CPU-Z показывает номинальную частоту процессора, то есть заявлено 2 ГГц, и показывает 2 ГГц. Ну то есть вроде бы всё выглядит прилично, как заявлено — так и работает.
Если немного отвлечься в теорию, то частота процессора — это количество операций, выполняемых процессором в единицу времени (сферически). Наш тест позволяет увидеть — за сколько времени в реальной жизни одни и те же процессоры выполняют одну и ту же работу на разных серверах разных клиентов. В теории одинаковые процессоры с одинаковой частотой, выполняя одну и ту же работу, должны выдавать один и тот же результат. Но в жизни всё сложнее. Есть дополнительные факторы, которые оказывают влияние на скорость. В рассматриваемом примере тест выдал значение в два раза меньше, чем наблюдалось на других серверах с таким же процессором. На скорость работы процессора могут значительно влиять настройки BIOS, которые по умолчанию могут быть нацелены на энергосбережение в ущерб производительности. К примеру, включение технологии Turbo Boost у процессора по нашим наблюдениям даёт прирост результатов теста от 10 до 20%, а изменение настроек электропитания с “оптимальных или сбалансированных” на “максимальная производительность” — до двух раз, что в нашем случае и произошло, результат теста в общем итоге улучшился в два раза и составил 24 балла. Производительность 1С также соответственно выросла.
Вообще, в характеристиках оборудования может быть чересчур много маркетинга. Что мешает вендору слегка приукрасить преимущества и скрыть недостатки? Зато у вас есть наш тест, и вы можете сравнить разницу в производительности различного оборудования применительно к задачам 1С и в составе настроек этого оборудования.
Вот я рассказал два примера, а теперь ещё раз: как интерпретировать результат теста. Тест только показывает способность системы выполнить некий эталонный объём работы за единицу времени. Что является одним или несколькими факторами замедлений — тест не показывает. Более того, узкие места есть всегда. Они могут ухудшать работу как значительно, так и быть совсем незаметными.
Небольшие цифры баллов в тесте может быть косвенным признаком значимости узкого места.
Как вы возможно поняли, тест является синтетическим. Если у вас стоит потребность оценить скорость выполнения именно вашего объёма работы, который может совершенно по-другому исполняться на оборудовании, то конечно вам нужно написать свой тест. Он будет не универсальным, но даст точную оценку именно для вашей задачи.
25 баллов в нашем тесте для одного сервера может быть отличным достижением, в то время как 25 баллов для другого сервера достаточно плохо.
Ценность теста — в накопленной за многие годы статистике, которая позволяет для вашего конкретного компьютера сформировать сравнительную оценку. Неожиданным положительным побочным эффектом нашего теста оказалась возможность оценивать влияние такого фактора, как версия платформы 1С Предприятия. Не наша заслуга, но пользователи нашего теста на основе полученных результатов в своё время массово обратились в фирму 1С с жалобой на проседание скорости в очередном релизе платформы 1С:Предприятие. Падение производительности объективно можно было оценить только благодаря такой обширной статистике, что позволило фирме 1С не тратить много сил на перепроверку достоверности жалоб и успешно выпустить новый более быстрый релиз.
Не удивляйтесь, если наш тест покажет невысокие значения при том, что по отдельности каждая компонента должна работать быстрее. Влиять на конечную скорость может всё, даже несовместимость этих компонентов. Можно сверхбыстрый SSD подключить к шине SATA2 и урезать его скорость. А может сложиться и ещё хуже.

Итерационный подход

Очень сложно решать задачи, связанные с параллельностью работы пользователей. При диагностике мы ищем узкие места. Но часто в подобных ситуациях узких мест много.
Может быть даже целый каскад значимых узких мест, и количество их непредсказуемо.
Для бизнеса это плохо слабой предсказуемостью трудозатрат. Пока одно узкое место не расшито — можно не увидеть причин следующего узкого места, а значит и не оценить его стоимость. Такие проблемы решаются многоитерационным способом. Как говорят профессионал — это тот, кто много раз наступил на грабли.
Нам нравится считать себя профессионалами, и поэтому мы не сможем вам дать формулу подсчёта стоимости при итерационном подходе. Это вызывает сильное непонимание у бизнеса, и часто звучат фразы типа “не надо юлить и разводить нас на деньги”. Правильным ориентиром будет: сначала предварительная оценка эффекта от расшивания самого узкого места. Если количество блокировок не уменьшится, то это вовсе не означает, что не стало лучше. В апдексе будет например видно, что интенсивность ввода данных возросла. И только вследствие возросшей интенсивности появились новые блокировки.
Затем будет следующая итерация, где мы оцениваем суммарную интенсивность блокировок, группируя их по месту исполнения кода.
Используя правило Парето (расшифровать про 20-80), выясняем новое наиболее узкое место с учётом количества пользователей, которые страдают от этих блокировок, таблиц на которых возникают эти блокировки.
Можно не знать, как работает бизнес-логика приложения, но при этом понять, что избыточные блокировки часто возникают из-за отсутствия используемой аналитики, по которой различается конкурирующая активность различных пользователей. Например, мы часто видим, что во многих решениях закрытие месяца происходит по предприятию в целом, а не по организации в частности. Нет измерений и индексов с ведущей организацией. Из-за этого все организации вынуждены ждать ту, которая закрывает месяц в настоящее время.
Некоторые блокировки можно было бы вообще избежать при более активном взаимодействии программистов и бизнеса. Не зная точно, нужно ли накладывать блокировку, и не желая выяснять у бизнеса, программист использует пессимистичный стиль “пусть будет блокировка на всякий случай”. Мы часто переспрашиваем бизнес, а нам нередко отвечают “да мы эти таблицы вообще не используем, их можно отключить”.
Ещё одной итерацией в нашей практике часто бывает ситуация, когда якобы кто-то всех блокирует и всем плохо, но никто не знает — кто и что делает. Эта задача также легко программно решается, используя собираемые логи об активности пользователей. При желании можно написать код, который будет управлять наложением блокировок, анализируя текущую ситуацию более продвинуто, например оценивая роль сотрудника в компании, критичность бизнес-операции для бизнеса.
Я не буду пересказывать книжку “1С-Эксперт”, так как там достаточно большой раздел посвящён решению проблем с блокировками.
Главное здесь — не хвататься за всё сразу, а расставить приоритеты по каждому конкретному случаю и решать каждый случай отдельно, не позволяя другим сотрудникам компании пытаться всё смешать в одну кучу. Не позволяйте им обобщать и выбрасывать важные различия в деталях.

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.

РЕШЕНИЕ ПРОБЛЕМЫ С ЗАВИСАНИЕМ 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)

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

Переработан механизм реструкторизации, актуально для баз с большими размерами

Реализован новый механизм реструктуризации информационной базы. Основные отличия этого механизма:

  • При выполнении реструктуризации обрабатываются только те физические таблицы базы данных, в которых есть реальные изменения.
  • Максимальное количество изменений выполняется без создания копии таблицы и копирования информации между копиями.
  • Если копирование информации между версиями таблиц все-таки требуется, это копирование будет выполняться средствами СУБД во всех возможных случаях.

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

Для работы нового механизма реструктуризации требуется наличие Java 1.8 на компьютере, где установлен сервер «1С:Предприятия».

Для файла conf.cfg реализованы параметры JavaHomeJavaOptsUpdateDBCfg.
Смотрите дополнительно https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/

Новый функционал «Система взаимодействия»

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

Реализовано событие технологического журнала <WINCERT>.

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

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

Повышена скорость работы поиска по началу строки в языке запросов при работе с СУБД PostgreSQL.

При работе с СУБД PostgreSQL реализовано преобразование операции языка запросов ПОДОБНО `ТЕКСТ%` в более оптимальную операцию SQL-запроса.В режиме совместимости с версией 8.3.10 поведение не изменилось.

 Улучшена производительность и масштабируемость при использовании на стороне сервера «1С:Предприятия» объектов HTTPСоединение и FTPСоединение в том случае, если используется несколько соединений из различных сеансов.

 

Ускорена работа с временными таблицами, при использовании СУБД Microsoft SQL Server

следующих версий:

  • 2012, версия 11.0.5548.0 и старше.
  • 2014, версия 12.0.2430.0 и старше.
  • 2016.

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

 

Оптимизирована работа с большими временными таблицами под управлением СУБД PostgreSQL.

Оптимизированы операции удаления записей из временных таблиц при выполнении некоторых операций в СУБД PostgreSQL и IBM DB2.

Уточнение отображения в линуксе

При работе под управлением ОС Linux, параметр рабочего процесса Занято памяти, вычисляется на основании значения VmRSS (resident set size). Значение параметра Занято памяти стало меньше в абсолютном выражении и более точно соответствует реальности.Рекомендуется провести переоценку параметров перезапуска рабочих процессов в свойствах рабочего сервера.

Добавлен платформенный вариант версионирования данных (для аудита) https://wonderland.v8.1c.ru/blog/istoriya-dannykh/

подробнее http://downloads.v8.1c.ru/content//Platform/8_3_11_2867/1cv8upd.htm

Нагрузка, создаваемая запросами Postgres

SELECT
pg_database.datname AS Database,
pg_stat_statements.query AS Query,
pg_stat_statements.calls AS ExecutionCount,
pg_stat_statements.total_time ExecutionTime,
pg_stat_statements.shared_blks_read + pg_stat_statements.shared_blks_written AS Memory,
pg_stat_statements.local_blks_read + pg_stat_statements.local_blks_written AS IO,
pg_stat_statements.temp_blks_read + pg_stat_statements.temp_blks_written AS Temp

FROM
pg_stat_statements AS pg_stat_statements
INNER JOIN pg_database AS pg_database
ON pg_database.oid = pg_stat_statements.dbid
ORDER BY
ExecutionTime DESC
with s AS (SELECT
CASE WHEN sum(total_time) = 0 THEN 1 ELSE sum(total_time) END AS sum_time,
CASE WHEN sum(blk_read_time+blk_write_time) = 0 THEN 1 ELSE sum(blk_read_time+blk_write_time) END as sum_iotime,
CASE WHEN sum(total_time-blk_read_time-blk_write_time) = 0 THEN 1 ELSE sum(total_time-blk_read_time-blk_write_time)
END as sum_cputime,
CASE WHEN sum(calls) = 0 THEN 1 ELSE sum(calls) END AS sum_calls,
CASE WHEN sum(rows) = 0 THEN 1 ELSE sum(rows) END as sum_rows
FROM pg_stat_statements
)
SELECT
'all_users@all_databases' as "user@database",
100 AS time_percent,
100 AS iotime_percent,
100 AS cputime_percent,
(sum_time/1000)*'1 second'::interval as total_time,
(sum_cputime/sum_calls)::numeric(20, 2) AS avg_cpu_time_ms,
(sum_iotime/sum_calls)::numeric(20, 2) AS avg_io_time_ms,
sum_calls as calls,
100 AS calls_percent,
sum_rows as rows,
100 as row_percent,
'all_queries' as query
FROM s
UNION ALL
SELECT
(select rolname from pg_roles where oid = p.userid) || '@' || (select datname from pg_database where oid
(100*total_time/(SELECT sum_time FROM s))::numeric(20, 2) AS time_percent,
(100*(blk_read_time+blk_write_time)/(SELECT sum_iotime FROM s))::numeric(20, 2) AS iotime_percent,
(100*(total_time-blk_read_time-blk_write_time)/(SELECT sum_cputime FROM s))::numeric(20, 2) AS cputime_percent,
(total_time/1000)*'1 second'::interval as total_time,
((total_time-blk_read_time-blk_write_time)/calls)::numeric(20, 2) AS avg_cpu_time_ms,
((blk_read_time+blk_write_time)/calls)::numeric(20, 2) AS avg_io_time_ms,
calls,
(100*calls/(SELECT sum_calls FROM s))::numeric(20, 2) AS calls_percent,
rows,
(100*rows/(SELECT sum_rows from s))::numeric(20, 2) AS row_percent,
query
FROM pg_stat_statements p
WHERE
(total_time-blk_read_time-blk_write_time)/(SELECT sum_cputime FROM s)>=0.005
UNION ALL
SELECT
'all_users@all_databases' as "user@database",
(100*sum(total_time)/(SELECT sum_time FROM s))::numeric(20, 2) AS time_percent,
(100*sum(blk_read_time+blk_write_time)/(SELECT sum_iotime FROM s))::numeric(20, 2) AS iotime_percent,
(100*sum(total_time-blk_read_time-blk_write_time)/(SELECT sum_cputime FROM s))::numeric(20, 2) AS cputime_percent,
(sum(total_time)/1000)*'1 second'::interval,
(sum(total_time-blk_read_time-blk_write_time)/sum(calls))::numeric(10, 3) AS avg_cpu_time_ms,
(sum(blk_read_time+blk_write_time)/sum(calls))::numeric(10, 3) AS avg_io_time_ms,
sum(calls),
(100*sum(calls)/(SELECT sum_calls FROM s))::numeric(20, 2) AS calls_percent,
sum(rows),
(100*sum(rows)/(SELECT sum_rows from s))::numeric(20, 2) AS row_percent,
'other' AS query
FROM pg_stat_statements p
WHERE
(total_time-blk_read_time-blk_write_time)/(SELECT sum_cputime FROM s)<0.005 ORDER BY 4 DESC;

Использование индексов 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

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

Реализована поддержка СУБД PostgreSQL версии 9.6.

 Смотрите также http://1c.ru/news/pressrelise.jsp?id=1847

Повышена масштабируемость кластера серверов в том случае, если:

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

Снижено количество оперативной памяти, используемой сервером «1С:Предприятия», если в прикладном решении используются пакетные запросы.

Упрощена диагностика использования циклических ссылок при работе встроенного языка.

Реализована возможность дополнительно обработать данные, которые получил динамический список для отображения. Реализовано событие ПриПолученииДанныхНаСервере. Дополнительно смотрите https://wonderland.v8.1c.ru/blog/obrabotka-i-oformlenie-dannykh-dinamicheskogo-spiska/

В технологическом журнале реализовано отражение событий, связанных с:

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

Реализовано событие технологического журнала <LIC>.

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

Реализовано журналирование событий, возникающих при первом соединении сервера «1С:Предприятия» с СУБД Microsoft SQL Server, в технологическом журнале. Журналирование выполняется с помощью события <DBMSSQLCONN>.

В документации данное изменение описано здесь и здесь.

Изменен подход к хранению истории исполнения фоновых и регламентных заданий. В клиент-серверном варианте история хранится в разрезе информационных баз. Для каждой информационной базы хранится история:

  • до 1 000 фоновых заданий, созданных из встроенного языка;
  • до 1 000 регламентных заданий;
  • до 1 000 системных фоновых заданий (формируемых самой системой).

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

Реализовано в версии 8.3.10.2168 в новое событие SCRIPTCIRCREFS  режим автоматического поиска циклических ссылок

Особенности 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>

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

 

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

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

SELECT COUNT(*) FROM DBSchema

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

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

 

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

Причины проблем с производительностью

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

Можно ли говорить об улучшениях работы без использования объективной статистики длительности операций?
Все все знают… вроде… и должны бы делать… но тогда бы не было проблем 🙂
Наше русское «авось» надо уметь оценивать в деньгах. Стоимость решения проблемы с производительностью в день когда она только возникла 5-10% от максимальной стоимости решения.
Через неделю уже это 25%. Через полгода эта проблема будет погребена под другими и вот тогда бизнесу за решение уже придется заплатить «по полной стоимости поиска проблемы», так как придется заново выяснять вес/влияние/значимость вклада проблемы с другими сопутствующими коэффициентами увеличения стоимости…

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

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

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

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

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

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

Объективное измерение производительности информационной системы

Эта заметка будет полезна администраторам информационных систем, которые хотят улучшить ситуацию с производительностью их системы. И вот на что рекомендуем обратить внимание:
1. Скорость операция с точки зрения пользователя – АПДЕКС
2. Загруженность оборудования – оценка запаса мощности

Одна из ошибок, которая часто совершается при повышении производительности информационной системы — спрашивать пользователей «а стало ли лучше сейчас?».

APDEX –статистика длительности операций — это:

  1. Объективная оценка
  2. Позволяет найти общую метрику для IT-специалистов и бизнеса
  3. Это замер начала и окончания операции
  4. Хранение в базе данных
  5. Бывает нужен программист
  6. Позволяет навести порядок в вопросах производительности
  7. В последних конфигурациях 1с механизм уже встроен
Совет пользователям, админы которых после этого поста все равно не будут применять этот подход:

Если хочешь попить чаю, создай предлог «все медленно работает»

Пудри мозг админу «зачем тебе замеры, этим программист должен заниматься» — не позволяй собрать объективные метрики

Если программист или админ спрашивает помогли ли правки, нагло ври что ничего не помогло. Если кричат громче, то твоя возьмет!

Админам на заметку:
  1. Если программист не хочет заниматься апдексом (типа «у меня нет времени»), то это не означает что можно все оставить как есть
  2. Если не будет объективных замеров, то и достигнутое улучшение объективно нельзя будет оценить
  3. Иногда важнее не уметь все делать, а организовать достижение конечного результата в том числе с привлечение других специалистов – главное результат

При хостинге 1cFresh АПДЕКС обязательно! :

  • Особенности «1СФреш»
  • Влияние пользователей одного клиента на работу пользователей другого клиента – потому что физически данные в одной таблице на одних дисках
  • Представители разных клиентов могут давать противоречивую информацию о работе
  • Но нужно следить чтобы сами замеры не были проблемой
  • Высокая конкуренция потенциально может создать блокировки на объектах фиксации – а апдекс во фреше не пишет однопоточно
  • Или доработать АПДЕКС

http://www.gilev.ru/apdex/ — онлайн сервис — «то что доктор прописал»!

  1. Во всех сервисах используется регистрация, ее надо пройти один раз
  2. Видео примера https://youtu.be/cSTYlitD8GM?t=8m
  3. Нужно придумать логин и указать почтовый ящик, куда будут приходить различные сообщения
  4. Во втором письме будет необходимо пройти по ссылке для активации учетной записи в сервисах

Настройка сервиса

  1. Описана http://www.gilev.ru/setupapdex/
  2. Клиентскую часть скачать http://www.gilev.ru/1c/cloud/ApdexClientWork82.cf и объединить с конфигурацией продуктива

Есть отличия от апдекса БСП

  1. Другой состав полей, собираем текст запроса
  2. Более эффективный способ записи без блокировок асинхронно (сначала замеры кэшируются, а потом записываются через фоновое задание )
  3. Отчеты строятся на сайте http://www.gilev.ru/apdex/

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

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

Флаг трассировки 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.4

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

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

Общие реквизиты, которые являются разделителями в режиме Независимо и совместно, не могут быть выбраны в список реквизитов ПоляБлокировкиДанных. Реализована возможность указывать такие реквизиты в качестве имени пространства блокировок объекта БлокировкаДанных. Система вызовет исключение в том случае, если в объекте БлокировкаДанныхиспользуется значение разделителя, отличное от значения, используемого в сеансе.

Изменения реализованы для следующих объектов:

  • Справочники;
  • Документы;
  • Планы видов характеристик;
  • Планы счетов;
  • Планы видов расчета;
  • Планы обмена;
  • Бизнес-процессы;
  • Задачи;
  • Константы.

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

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

Для сервера «1С:Предприятия» реализованы лицензии с ограниченным количеством одновременно обслуживаемых сеансов клиентских приложений —  МИНИ-СЕРВЕР на 5 подключений.

Подробнее здесь

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

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

Возможность помещения в технологический журнал информации о работе с внешними источниками данных. Для этого в конфигурационный файл технологического журнала добавлено событие <EDS>

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

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

Табличные пространства не создаются автоматически и должны быть созданы администратором базы данных. Если дополнительных табличных пространств не создано — используется табличное пространство по умолчанию (pg_default).

Расширен состав свойств для события технологического журнала <call> в том случае, если событие генерируется для процесса rphost (свойство process равноrphost), а также в том случае, если процесс rphost выполняет обращение к виртуальным ресурсам системы.

Добавлены свойства, отображающие:

  • Report — имя объекта метаданных выполняемого отчета;
  • Method — имя вызванного метода;
  • SessionID — номер сеанса;
  • Memory — объем памяти в байтах, занятой, но не освобожденной за вызов;
  • MemoryPeak — объем памяти в байтах, занятой, но не освобожденной за вызов. Пиковое значение;
  • InBytes — количество прочитанных за вызов данных с диска, в байтах;
  • OutBytes — количество записанных за вызов данных с диска, в байтах;
  • Context — контекст события.

 

Возможность помещения в технологический журнал информации о работе с внешними источниками данных. Для этого в конфигурационный файл технологического журнала добавлено событие <EDS>.

 

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

Подробнее здесь

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

Файловая версия 8.3.8 работает существенно быстрее чем версии 8.3.6, 8.3.7

Реализована поддержка веб-сервера Apache 2.4 для ОС Windows и Linux.

Для динамического списка реализована поддержка работы с пакетным запросом.

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

В языке запросов реализовано упрощение некоторых выражений вида <ВЫРАЖЕНИЕ> ИЛИ ИСТИНА.

Оптимизированы операции удаления записей из временных таблиц при выполнении некоторых операций в СУБД PostgreSQL и IBM DB2.

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

 

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

Если блокировка устанавливается для дальнейшей работы с остатками, то не рекомендуется указывать значения оборотных субконто при наложении блокировки (возможно использование как свойства БлокироватьДляИзменения, так и явное использование управляемой блокировки). Если блокировка устанавливается для дальнейшей работы с оборотами — следует указывать все необходимые значения субконто, в том числе и значения оборотных субконто (возможно использование только явного вызова управляемой блокировки).

В режиме совместимости с версией 8.3.7 поведение не изменилось.

 

Реализовано событие технологического журнала <FTEXTSKIP>.

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

Для выполнения реструктуризации таблиц базы данных с изменением типов полей необходимо установить нужный режим режим совместимости и выполнить операцию реструктуризации информационной базы в конфигураторе (Главное меню — Администрирование — Тестирование и исправление).

В режиме совместимости с версией 8.3.7 поведение не изменилось.

При работе со всеми СУБД изменена структура индексов по полям составного типа. В результате уменьшено количество индексов. Такое построение индексов осуществляется при отключенном режиме совместимости и после выполнения реструктуризации соответствующего объекта конфигурации.
Для выполнения реструктуризации таблиц базы данных с изменением индексов необходимо установить нужный режим режим совместимости и выполнить операцию реструктуризации информационной базы в конфигураторе (Главное меню — Администрирование — Тестирование и исправление).
В режиме совместимости с версией 8.3.7 поведение не изменилось.

Ошибка 10161406 исправлена в 8.3.8.1747

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

 

Более подробно тут

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

При работе с СУБД PostgreSQL и IBM DB2 ускорено удаление записей о фактическом периоде действия регистра расчета при удалении больших наборов записей.

Реализована поддержка СУБД Oracle Database версии 12.1.0.2 (Linux)

Доступно клиентское приложение, работающее под OS X 10.8 и старше (только в варианте 64-разрядного приложения)

Реализована поддержка дистрибутива Astra Linux Special Edition 1.4

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

При выполнении запроса, обращающегося только к данным табличных частей, исключено соединение с таблицей родительского объекта.
Оптимизировано чтение из СУБД объектов типа ДокументОбъект, СправочникОбъект, БизнесПроцессОбъект, ЗадачаОбъект, ПланВидовРасчетаОбъект, ПланВидовХарактеристикОбъект, ПланОбменаОбъект, ПланСчетовОбъект — чтение сопровождается неявным созданием транзакции только при наличии у объекта табличных частей и если СУБД используется «грязное» чтение вне транзакции.

Оптимизирована работа с условным оформлением в управляемой форме. Ускорено открытие управляемой формы с большим количеством элементов условного оформления.

Ускорена работа конфигураций (включая открытие форм) с большим количеством ролей.

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

Программные лицензии. Начиная с версии 8.3.7.1949 изменение нумерации сетевых адаптеров не будет приводить к нарушению привязки лицензии (если не поменялись другие параметры). Это актуально для работы в виртуальных средах.

Реализовано событие технологического журнала <CONFLOADFROMFILES>.

 

Реализовано событие технологического журнала <INPUTBYSTRING> для отслеживания событий, связанных с вводом по строке.

 

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

 

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

В 8.3.7 могут быть избыточные блокировки на константах и регламентах.

Подробнее описание тут

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

Реализована поддержка СУБД PostgreSQL версии 9.4.

Реализована возможность использования логических выражений в описании поля выборки и в выражениях фильтрации результатов запроса (предложение ГДЕ).

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

В технологическом журнале, в событияхSCALL и CALL, реализованы новые поляIName и MName , которые содержат дополнительную информацию о внутренних вызовах системы. Информация может использоваться специалистами фирмы «1С» при разборе обращений, направляемых в службу поддержки.

Реализовано отражение в технологическом журнале операций обновления индекса полнотекстового поиска. Реализованы события технологического журнала FTEXTCheck и FTEXTUpd. Реализован элемент технологического журнала ftextupd.

Реализовано событие технологического журнала <MAILPARSEERR>.

 

Подробнее описание здесь.

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

Обычно влияет сразу на всех пользователей в толстом клиенте. Поэтому после регистрации информационной базы в списке баз пользователя информационной системы НАЧИНАЕТ работать кэширование конфигурации на стороне клиента и ускоряет работу.

конфигуратор

 

см. также http://www.gilev.ru/systemperfomance/

Hyper-threading не всегда гарантия лучшей производительности

1. Статья на сайте Microsoft (в машинном переводе на скриншоте)
hyper

 

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

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

вхостегипер

 

см. также http://www.gilev.ru/systemperfomance/

Нагрузка на файлы

SELECT d.name, f.name, f.type_desc, f.physical_name,
[read b/ms] = num_of_bytes_read * 1.0/sample_ms,
[avg read latency] =
(1.0*s.io_stall_read_ms / (COALESCE(NULLIF(s.num_of_reads,0),1))),
[write b/ms] = num_of_bytes_written * 1.0/sample_ms,
[avg write latency] =
(1.0*s.io_stall_write_ms / (COALESCE(NULLIF(s.num_of_writes,0),1)))
FROM sys.master_files AS f
INNER JOIN sys.databases AS d
ON f.database_id = d.database_id
INNER JOIN sys.dm_io_virtual_file_stats(default, default) AS s
ON d.database_id = s.database_id
AND f.[file_id] = s.[file_id]
order by 8 desc

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

Определяем 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’

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

NUMA – Non Uniform Memory Access

На русский язык это можно перевести как Неравноценный Доступ к Памяти.

Современные многосокетные сервера, по сути, представляют собой несколько изолированных односокетных компьютеров, объединенных на одной материнской плате. Каждый процессор монопольно владеет своими слотами оперативной памяти, и только он имеет к ней доступ. Аналогично, каждый процессор имеет свои персональные PCI-E шины, к которым подключены различные устройства материнской платы, а так же слоты расширения PCI-E. Процессоры соединены между собой высокоскоростной шиной обмена данными, по которой они получают доступ к «чужим» устройствам, делая запрос на это соответствующему процессору-хозяину. По понятным причинам, доступ процессора к «своей» памяти происходит гораздо с меньшими накладными расходами, чем к «чужой».

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

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

;

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

 

Повышение параллельности работы пользователей в компании Авилон

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

Авилон отзыв

Проект сделан с использованием технологий http://www.gilev.ru/online/
Ориентировочная стоимость  аналогичных работ – 150 000 руб.

Другие отзывы о проделанных нами работах можно посмотреть здесь http://www.gilev.ru/results/

Улучшения по производительности при отключении режима совместимости 8.2.13

Почему мы рекомендуем отключать режим совместимости с 8.2.13

Улучшения в версии 8.2.14

  • Оптимизировано выполнение запроса вида «ТипЗначения(Поле1) = ТипЗначения(Поле2)», если «Поле1» и «Поле2» содержат значения ссылочного типа.
  • Оптимизированы выборки, выполняемые порциями (используемые в методах «Выбрать()», а также при реструктуризации), для всех СУБД.
  • Оптимизирован ряд механизмов сервера 1С:Предприятия для повышения масштабируемости и производительности при большом количестве работающих пользователей.
  • Оптимизирована работа с файлами на диске (включая временные файлы) для следующих механизмов: полнотекстовый поиск, справка, объект «ИнтернетПочта».
  • Оптимизирована работа кластера серверов с данными сеанса.
  • Ускорена работа функций «ПолучитьСоединенияИнформационнойБазы()» и «ПолучитьСеансыИнформационнойБазы()» при большом количестве зарегистрированных пользователей.
  • Повышена производительность и масштабируемость модуля расширения веб-сервера.
  • В веб-клиенте оптимизировано обновление табличного документа после выполнения интерактивного редактирования, а также после программного изменения отдельных ячеек табличного документа.
  • Уменьшено количество серверных вызовов в части функциональности в веб-клиенте.
  • Ускорена работа механизма управляемых блокировок.
  • При отключенном режиме совместимости изменен режим хранения констант и настроек регистров накопления. Для каждого объекта используется своя таблица базы данных. Это означает улучшенную параллельность работы пользователей. При включении режима совместимости (в значение «Версия 8.2.13» или «Версия 8.1») выполняется обратная конвертация для обеспечения возможности запуска прикладного решения с помощью версии 8.2.13. Требуется реструктуризация!

Улучшения в версии 8.2.15

  • Для полей управляемой формы, отображающих реквизит составного типа, ускорено открытие списка быстрого выбора в тех случаях, когда в составной тип входят ссылочные типы с разными настройками быстрого выбора.
  • Уменьшено влияние режима отладки на скорость работы в режиме «1С:Предприятие» для тонкого клиента, толстого клиента, сервера и внешнего соединения.
  • Увеличена производительность работы системы в случае использования двух и более разделителей или одного разделителя с типом «Строка».
  • Оптимизирован запуск клиентского приложения.
  • Оптимизировано открытие формы веб-клиента при использовании большого количества элементов в условном оформлении формы.
  • Оптимизировано открытие формы отчета в веб-клиенте, который содержит большое количество элементов условного оформления.
  • Для блокировочных СУБД (Microsoft SQL Server, IBM DB2) изменение пользователя информационной базы в транзакции более не конфликтует с процессом аутентификации, кроме случая, когда аутентификацию пытается выполнить пользователь, данные которого изменены, и транзакция, в рамках которой были выполнены изменения, не завершена.
  • Для нового независимого и непериодического регистра сведений, индекс по измерениям является кластерным. При создании первого регламентного задания, индекс по идентификатору задания также является кластерным. Требуется реструктуризация! Для создания необходимых индексов в существующей информационной базе можно выполнить одно из следующих действий:
    • Выполнить реструктуризацию базы данных.
    • Выполнить загрузку информационной базы из файла «.dt».

Улучшения в версии 8.2.17

  • Реализована поддержка СУБД Microsoft SQL Server 2012.
  • Для работы с Microsoft SQL Server 2008 R2 возможно использование Native Client. При использовании Native Client возможно использование протокола SHARED MEMORY, если оба сервера находятся на одном компьютере. Использование протокола SHARED MEMORY (при использовании Native Client) возможно, начиная с версии Microsoft SQL Server 2005. Можно получить значительное ускорении при использовании SHARED MEMORY.

Улучшения в версии 8.2.18

  • Реализована поддержка Native Client для СУБД Microsoft SQL Server 2005 и Microsoft SQL Server 2012.
  • Оптимизирован сервис нумерации кластера серверов «1С:Предприятия», в результате чего исключено снижение производительности сервера при длительной работе.
  • Оптимизирована работа тонкого и толстого клиентов, работающих с файловой информационной базой, расположенной на сетевом ресурсе, при многопользовательском доступе. Ускорены различные операции с информационной базой, включая открытие и редактирование форм объектов, просмотр форм списков, запись объектов, проведение документов и т.д.
  • Повышена масштабируемость сервера «1С:Предприятия» при работе с высокой нагрузкой и большим количеством одновременно работающих пользователей.
  • Ускорена работа функций СтрЧислоСтрок() и СтрПолучитьСтроку() при работе в тонком клиенте, толстом клиенте и на стороне сервера.
  • Оптимизировано получение писем с помощью объекта ИнтернетПочта.
  • Ускорена работа функции ЗначениеЗаполнено() в том случае, если параметром функции выступает выражение, состоящее из получения свойства какой-либо переменной (как «через точку» так и с помощью операторного способа ([])) любого уровня вложенности.
  • В таблицу журнала документов добавлен индекс по полю Ссылка. В результате повышается скорость работы динамического списка журнала документов, а также поиск по ссылке в журнале документов.
  • Оптимизирована генерация запросов для СУБД Microsoft SQL Server:
    • Сокращено количество повторяющихся планов запросов;
    • Сокращено количество компиляций запросов в Microsoft SQL Server;
    • Уменьшен размер кеша планов запросов Microsoft SQL Server;
    • Уменьшено время работы некоторых запросов;
    • Улучшились создаваемые планы запросов в некоторых случаях.

     

  • Оптимизирована работа динамического списка и динамической выборки из базы данных в случае наличия упорядочивания выборки по убыванию.Для Microsoft SQL Server эти операции оптимизированы дополнительно, а также оптимизирована операция реструктуризации.
  • При работе в клиент-серверном варианте в режиме управляемых блокировок, изменен механизм генерации новых ссылок для объектов информационной базы. Ссылки генерируются строго последовательно для всех соединений сервера «1С:Предприятие» с сервером СУБД. В результате сокращена фрагментация таблиц и индексов в базе данных, а также повышена скорость вставки и чтения записей таблиц базы данных.
  • Оптимизирован механизм балансировки нагрузки в кластере серверов.
  • Оптимизировано получение из базы данных прикладных объектов без табличных частей при вызове метода ПолучитьОбъект() и при обращении к свойствам «через точку» от ссылки.
  • Оптимизирована работа сервера «1С:Предприятия» при выполнении запросов к объектам, на которые наложены ограничения доступа к данным.
  • При работе с СУБД Microsoft SQL Server оптимизированы операции, использующие конструкцию IN (…) с одним значением в списке.
  • Оптимизирован запуск клиентских приложений, фоновых и регламентных заданий.
  • Ускорена работа системы при частом выполнении фоновых заданий и вызовов web-сервисов.
  • Ускорено открытие управляемых форм.Оптимизация наиболее заметна в случае многопользовательского доступа (с помощью тонкого клиента) в файловом варианте информационной базы, расположенной на сетевом ресурсе.
  • Ускорена работа некоторых видов запросов в файловом варианте информационной базы, например:
    • Запросы вида ВЫБРАТЬ ПЕРВЫЕ 1 …;
    • Сравнение двух списков с помощью оператора языка запросов В: … (Объект, СчетФактура) В (&СписокОбъектовИПартий) ….

     

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

Улучшения в версии 8.2.19

  • Оптимизирован запуск системы при большом количестве запусков, выполняемых с небольшими интервалами между запусками.
  • Проведена оптимизация внутренних механизмов платформы, улучшающая производительность и масштабируемость кластера серверов «1С:Предприятия».
  • Для независимых регистров сведений без измерений реализовано создание отдельных индексов по разделителям. Требуется реструктуризация!
  • Для разделителей с режимом разделения Независимый и совместный реализован дополнительный индекс в объектных таблицах, включающий значение разделителя, а также первичный ключ таблицы. Индекс позволит избежать эскалаций блокировок в СУБД при некоторых сценариях работы с таблицей.
  • При работе в веб-клиенте оптимизированы следующие операции с табличным документом: открытие, построчная прокрутка, постраничная прокрутка.

ВАЖНО. ДЛЯ ПОЛУЧЕНИЯ ЭФФЕКТА ОТ ВЫКЛЮЧЕНИЯ СОВМЕСТИМОСТИ НАДО СДЕЛАТЬ «РЕСТРУКТУРИЗАЦИЮ» В «ТЕСТИРОВАНИИ И ИСПРАВЛЕНИИ»!

 

Отзыв на курс Кухара Богдана «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

 

Как включить отладку на сервере 1С

Если требуется включить отладку на сервере 1С 8.2, необходимо проделать следующее:

— запустить редактор реестра
regedit
— открыть в нём раздел
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\1C:Enterprise 8.2 Server Agent
— найти параметр
ImagePath
— изменить его, добавив параметр -debug .
Например, было:

«C:\Program Files (x86)\1cv82\8.2.17.169\bin\ragent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d «C:\Program Files (x86)\1cv82\srvinfo»

стало:

«C:\Program Files (x86)\1cv82\8.2.17.169\bin\ragent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d «C:\Program Files (x86)\1cv82\srvinfo»

— перезапустить службу 1C:Enterprise 8.2 Server Agent.

Для сервера 1С 8.1 всё делается точно так же, изменения только в названии служб и пути к файлу запуска ragent.

Сервер как «демон» ОС Linux

Если в отладочный режим необходимо перевести сервер «1С:Предприятия» работающего в режиме «демона» в ОС Linux, то необходимо выполнить следующие операции:

1. Остановить сервер «1С:Предприятия».

/etc/init.d/srv1cv83 stop

2. В конфигурационном файле srv1cv83 установить значение параметра SRV1CV8_DEBUG в значение 1.

SRV1CV8_DEBUG=1

3. Сохранить конфигурационный файл.

4. Запустить сервер «1С:Предприятия».

/etc/init.d/srv1cv83 start

Примечание.  Для RPM-системы нужно править не скрипт (/etc/init.d/srv1cv83), а конфигурационный файл, который находится тут /etc/sysconfig/srv1cv83

Процессор — пороги счетчиков

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

 

Processor\% Processor Time

Порог: усредненно порог для процессоров составляет 65 процентов.

Значение: Этот счетчик является основным показателем деятельности процессора. Высокие значения многих не обязательно плохо. Однако, если значения других счетчиков процессора растут линейно ( % Privileged Time или Processor Queue Length) , то это обозначает проблемы. Убедитесь, что у вас схема энергоснабжения в режиме максимальной производительности.

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

ЗагруженностьПроцессора

Processor\% Privileged Time

Порог: значение более 75 процентов означает узкое место.

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

System\Context Switches/sec

Порог: При контексте менее 5000 в секунду на процессоре не стоит волноваться. Если переключение контекста превышает 15000 в секунду на один процессор, то есть проблемы.

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

Processor(*)\% Processor Queue Length

Порог: не больше 2х на 1 ядро, т.е. 16 ядер – 32 очереди

Значение: При нехватке ядер процессора возникает ожидание в виде очередей. Убедитесь, что у вас схема энергоснабжения в режиме максимальной производительности. Рекомендуется добавить ядер. Можно заменить на процессор из той же серии, но с большим количеством ядер. При этом старайтесь не увеличивать количество ядер в «ущерб» частоте процессора.

Для анализа используйте онлайн-сервис.

Типичные ошибки при подборе процессоров

» Процессоры и платформы фирмы ХХХ хорошие, остальные плохие».
«Процессоры и платформы одной фирмы за сильно меньшую цену обеспечивают сильно лучшие эксплуатационные характеристики — производительность, энергопотребление и тепловыделение и т.п.»

И то и другое, мягко говоря, маркетинг.

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

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

«Купим сейчас с одним процессором, потом докупим при нужде еще один/три»

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

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

Воспользуйтесь нашими услугами по побору серверов.

Влияние 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/

Виртуализация сервера приложений 1С с аппаратным ключом

13f561e539d0

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

Многие знают, что для работы сервера приложений 1С необходим аппаратный HASP-ключ, выпускаемый в формате LPT-переходника или USB-донгла. В отношении виртуализации у компании 1С мнение весьма специфичное – раньше представители компании заявляли о невозможности работы сервера в виртуальной среде, а теперь предлагают приобрести программный ключ защиты вместе с новым комплектом ПО за 40000р.

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

В рамках статьи, в качестве платформы виртуализации, мы будем рассматривать гипервизор Microsoft Hyper-V Server 2008 R2. Выбор, в основном, обусловлен функциональными возможностями, которые представляет гипервизор в своем «бесплатном» исполнении. В частности – поддержка кластеризации с «живой миграцией» виртуальных машин между узлами.

К сожалению, в Hyper-V не реализовано полноценного механизма подключения USB-устройств к виртуальным машинам. Это создает некоторый дискомфорт, в случае необходимости подключения к виртуальному серверу дополнительных внешних устройств, в том числе аппаратных ключей. В процессе виртуализации (P2V) физического сервера, вообще отрезаются все упоминания о шине USB и устройствах, подключенных к ней.

У основных конкурентов — VMWare и Citrix, существуют рабочие механизмы для перенаправления устройств на шине PCI с bare-metal гипервизоров на виртуальные машины. С помощью этого же механизма, можно перенаправлять на виртуальную машину и USB-устройства.

Сам факт проброса USB-устройств непосредственно из гипервизора сводит к нолю преимущества, получаемые от использования кластера Hyper-V с его функционалом «живой миграции». При перемещении виртуальной машины с одного гипервизора на другой, необходимо будет каждый раз перетыкать ключ и заново настраивать переадресацию. Становится понятно, что нам необходимо более гибкое решение.

В данном случае, нам на помощь придет отличная программа USB-Redirector, осуществляющая проброс любого USB-устройства по локальной сети с одного сервера на другой. Стоимость самой скромной Windows-редакции данной утилиты — 65 евро, а для осуществления задуманного больше и не надо. Существует большое количество, как аппаратных, так и программных реализаций данной технологии от самых разнообразных разработчиков. Однако в рамках статьи мы рассмотрим именно программу от Incentives Pro, как наиболее экономичное решение рассматриваемой задачи.

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

После установки серверной части, мы должны выбрать в консоли программы те устройства, к которым необходимо предоставить доступ по сети. Для проброса устройства по сети, серверу USB Redirector не требуется даже драйвера для устройства, он понадобится только на сервере 1С с клиентским приложением.

usb-server_PNG

При использовании технологии Live Migration в кластере Hyper-V, виртуальная машина перемещается между узлами кластера, не прерывая сетевых соединений. Так как промежуток времени, когда виртуальная машина не доступна по сети, пренебрежимо мал, пользователи не испытывают дискомфорта в работе с сервером приложений 1С.

usb-client_PNG

devman-usb_PNG

Для корректной работы вышеописанной схемы, необходимо разрешить на обоих серверах доступ по порту 32032 для USB Redirector Service. Сама программа не создает правила для встроенного брандмауэра, так что их придется настраивать вручную.

На видео представлена процедура настройки клиентского и серверного приложений.

После удачного дистанционного подключения нашего HASP-ключа, в диспетчере устройств появятся виртуальные USB-девайсы, драйвера на которые уже должны стоять на сервере. В случае использования LPT-ключа, можно воспользоваться переходником LPT-to-USB, китайские реализации которого можно с легкостью найти в розницу.

Андрей Ивашенцев