Нагрузочное тестирование. В дни проведения ЧМ по футболу.

Публикация № 850217 24.06.18

База данных - HighLoad оптимизация

Нагрузочное тестирование. Подготовка к экзамену 1С:Эксперт. По мотивам доклада Виктора Богачева Инфостарт Event 2014. В дни проведения ЧМ по футболу.

Введение

Одно из требований к специалистам на экзамене «1С:Эксперт по технологическим вопросам». (http://1c.ru/rus/partners/training/expert.htm) - владение методиками и технологиями нагрузочного тестирования систем на платформе «1С:Предприятие 8». Изучим доклад Виктора Богачева о нагрузочном тестировании ООО «Деловые Линии» (Infostart Event 2014).

 
 Здесь краткий конспект.

 

Попробуем на тестовой базе повторить избранные места доклада:

Ситуация 1. При увеличении числа запросов к базе до 3-4 тысячи в секунду стали наблюдаться pagelatch из-за создания/удаления временных таблиц и индексов

Ситуация 2. При завершении сессий возникает нагрузка на сервер СУБД из-за уничтожения временных таблиц

Оборудование и ПО

Платформа 8.3.12, без совместимости. Управляемый режим блокировок. Сервер приложений – отдельно, 1С:Предприятие запущено на сервере СУБД (MS SQL 2012). Жесткий диск – SSD. В приложении к статье – база данных с обработкой нагрузочного тестирования. Кто захочет – cможет повторить все примеры.

Ситуация 1

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

Запрос1.Текст = "ВЫБРАТЬ

|             ""флаг запроса"" КАК Поле2

|ПОМЕСТИТЬ Таб1

|

|ИНДЕКСИРОВАТЬ ПО

|             Поле2

|;

|

|////////////////////////////////////////////////////////////////////////////////

|УНИЧТОЖИТЬ Таб1";

 

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

 

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

 

Количество запросов, latch проверяем с помощью монитора производительности: Мой компьютер - Управление – Производительность - SQL Server, Latches Object. Как и рекомендуют в документации.

Варианты и результаты теста:

  1. Процедура  «ПодключитьОбработчикОжидания». (Запрос1)
  2. Фоновые задания, ни временная таблица, ни индекс НЕ создаются. (Запрос2)
  3. Фоновые задания, индекс временной таблицы НЕ создается. (Запрос3)
  4. Фоновые задания, создается индекс временной таблицы. (Запрос1)
     
  1. При подключении обработчика ожидания несколько раз мне не удалось получить больше 1,6 тысяч запросов в секунду. Скорее всего, ПодключитьОбработчикОжидания, не обеспечивает параллельной работы: клиент «подвисает». О том же указано и в описании: …Подключает вызов указанной процедуры модуля управляемого приложения (модуля обычного приложения) или глобального общего модуля через определенный интервал времени. Вызов будет осуществляться только в "состоянии покоя", то есть в тот момент, когда программа не выполняет никаких действий… Поэтому метод «ПодключитьОбработчикОжидания» для нагрузочного тестирования использовать не будем.  
  2. Если в тексте запроса не создавать ни временных таблиц, ни индексов к ним - ожиданий latch не возникает.
  3. Из-за создания большого числа временных таблиц, появились ожидания latch.
  4. В случае создания временных таблиц, индексов возникают значительные ожидания latch: время теста 30 секунд, total latch wait time 2.4 секунд.
     

Еще одно замечание по нагрузочному тестированию нашел на ИТС, Влияние внешних обработок на производительность http://its.1c.ru/db/metod8dev#content:5940:hdoc : Компиляция модулей встроенных в конфигурацию выполняется однократно в процессе инициализации, тогда как для внешних обработок компиляция будет выполняться многократно, отдельно для каждого пользователя. Это приводит как к снижению производительности (компиляция модуля требует времени), так и существенному повышению нагрузки на CPU. Поэтому не рекомендуется выносить во внешние обработки функционал, который может одновременно использоваться большим количеством пользователей.

 

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

 

Посмотрим на ситуацию со стороны СУБД. Будем использовать sys.dm_os_latch_stats. Очистить существующую статистику DBCC SQLPERF ('sys.dm_os_latch_stats', CLEAR) - запустить нагрузочный тест. Выборка статистики по нагрузке Select * from sys.dm_os_latch_stats where wait_time_ms > 0

 

latch_class

waiting_requests_count

wait_time_ms

max_wait_time_ms

ACCESS_METHODS_HOBT_COUNT

48

7

1

BUFFER

184436

7492

309

 

Динамическое представление sys.dm_os_latch_stats указывает, что основной тип latch – BUFFER. Как указано в документации (https://msdn.microsoft.com/ru-ru/library/ms175066%28v=sql.120%29) Используется для синхронизации краткосрочного доступа к страницам баз данных. Кратковременная блокировка буфера необходима перед считыванием или модификацией любой страницы базы данных. Конфликт кратковременной блокировки буферов может указывать на наличие ряда проблем, в числе которых — «горячие» страницы и низкая производительность подсистемы ввода-вывода.

 

Представление sys.dm_os_wait_stats устанавливает различие между ожиданиями кратковременных блокировок страниц, вызванными операциями ввода-вывода и операциями чтения и записи на данной странице. Очистить существующую статистику DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) запустить нагрузочный тест. Выборка статистики по нагрузке Select * from sys. dm_os_wait_stats where wait_time_ms > 0

 

wait_type

waiting_tasks_count

wait_time_ms

max_wait_time_ms

LATCH_SH

21

1

0

LATCH_EX

45

6

0

PAGELATCH_SH

24552

1680

280

PAGELATCH_UP

88271

3460

267

PAGELATCH_EX

115741

2012

1

PAGEIOLATCH_UP

227

14

0

 

PAGELATCH и PAGEIOLATCH – соответственно доступ к страницам памяти и жесткого диска. LATCH – доступ к нестраничным ресурсам. Расшифровку типов ожидания можно посмотреть https://www.sqlskills.com/help/waits/ Очень хорошая, подробная статья. Приведу выдержку.

Common causes of PAGELATCH_XX contention are:

  • Allocation bitmap contention in tempdb (PAGELATCH_UP for multiple threads trying to change the same bitmap), and under extreme loads, in user databases
  • Table/index insert hotspot (PAGELATCH_EX for threads inserting onto the same page and possibly PAGELATCH_SH for threads reading from that page)
  • Excessive page splits from random inserts (PAGELATCH_EX for threads trying to insert/update rows on a page and possibly PAGELATCH_SH for threads reading from that page)

 Еще одна статья https://habr.com/post/216309/, на русском.

Для системного представления sys.dm_io_virtual_file_stats команда очистки не предусмотрена. Поэтому сначала выгрузим содержимое динамического представления во временную таблицу

 

use tempdb

go;

select * into MyTempDB01 from sys.dm_io_virtual_file_stats(null,null)

 

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

 

select tab1.database_id,

tab1.file_id,

tab1.num_of_reads-tab2.num_of_reads AS num_of_reads,

tab1.num_of_bytes_read - tab2.num_of_bytes_read AS num_of_bytes_read,

tab1.num_of_writes - tab2.num_of_writes AS num_of_writes,

tab1.num_of_bytes_written - tab2.num_of_bytes_written AS num_of_bytes_written,

tab1.io_stall-tab2.io_stall AS io_stall,

tab1.io_stall_read_ms-tab2.io_stall_read_ms AS io_stall_read_ms,

tab1.io_stall_write_ms-tab2.io_stall_write_ms AS io_stall_write_ms,

tab1.size_on_disk_bytes - tab2.size_on_disk_bytes AS size_on_disk_bytes

from  sys.dm_io_virtual_file_stats(null,null) AS tab1

inner join MyTempDB01 AS tab2

on tab1.database_id = tab2.database_id

and tab1.file_id = tab2.file_id

 

database_id

file_id

num_of_reads

num_of_bytes_read

num_of_writes

1

1

0

0

0

1

2

0

0

0

2

1

0

0

57

2

2

0

0

4672

 

Более подробно таблицу можно посмотреть в приложенном файле *.xls. Как видно, запись и чтение происходила только в базу ID = 2. Наверное, это TempDB. Сделаем запрос select DB_ID('tempdb') – получим результат = 2. Так и есть.

 

Удалим временную таблицу drop table dbo.MyTempDB01

 

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

USE master

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = tempdev, FILENAME = 'E:\tempdb.mdf')

GO

ALTER DATABASE  tempdb

MODIFY FILE (NAME = templog, FILENAME = 'E:\templog.ldf')

GO

Имена для файлов, соответствующих tempdev, templog можно посмотреть в свойствах таблицы. После изменения настроек TempDB службу SQL Server необходимо перезапустить. В моем случае тестирование после переноса не выявило изменений.

 

У системного представления sys.dm_db_index_operational_stats(,,,) первый аргумент ID базы -берем из прошлого примера. DMV не содержит имени таблицы – приходится делать левое соединение с таблицей sys.objects

 

Select tab2.name, tab1.page_latch_wait_count

from sys.dm_db_index_operational_stats(2,NULL,NULL,NULL) AS tab1

left join sys.objects as tab2 ON tab1.object_id = tab2.object_id

where tab1.page_latch_wait_count > 0

 

Строки повторяются: одна для таблица, другая – ее индекс. Назначения таблиц – из документации: https://msdn.microsoft.com/ru-ru/library/ms179503%28v=sql.120%29.aspx

 

name

page_latch_wait_count

Назначения таблиц

sysrscols

102147

Порядок полей таблиц

sysrowsets

40659

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

sysallocunits

546855

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

sysallocunits

684

 

sysschobjs

57

Существует в каждой базе данных. Каждая строка представляет объект базы данных.

sysschobjs

1

 

syscolpars

3

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

syscolpars

2

 

sysidxstats

40

 

sysiscols

1

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

sysobjvalues

12

Существует в каждой базе данных. Содержит по строке на каждое общее свойство сущности.

 

Любопытно, что таблица sysobjvalues в нашем случае производит гораздо меньше latch, чем топовые таблицы, а в докладе она наоборот, входит в топ. Возможно, изменилась архитектура ПО. Более подробно таблицу можно посмотреть в приложенном файле *.xls

 

Ситуация 2.

 Включим замер производительности. Создадим много временных таблиц с помощью 1С. Как известно, при завершении запроса 1С, СУБД использует не DROP TABLE, а TRUNCATE TABLE - оставляет временную таблицу для повторного использования. Чтобы временных таблиц было много - каждая временная таблица должна иметь уникальный набор столбцов. Более подробно – смотрите обработку в приложенной базе данных 1С. У меня временные таблицы выглядят примерно так, их около 10 тысяч.

 

 

Посмотрим активные сессии: select * from sys.dm_exec_sessions where program_name = '1CV83 Server'

 

session_id

login_time

host_name

program_name

status

51

2018-06-19 13:12:34.050

U1C01

1CV83 Server

sleeping

. . .

 

62

2018-06-19 13:12:34.050

U1C01

1CV83 Server

sleeping

 

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

kill 51

. . .

kill 62

 

Кстати, чтобы не повторять однообразные строки, можно использовать скрипт, на основе https://ru.stackoverflow.com/questions/733831

 

Посмотрим результаты замера производительности.

 Здесь до 13:04:15 идет создание временных таблиц, между 13:04:45 и 13:04:55 – завершение сессий SQL. Максимальные значения показателей latch более чем в три раза превосходят значения предыдущего эксперимента.

 

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

 

 

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

 

SELECT st.*, qs.*

FROM sys.dm_exec_query_stats AS qs 

CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st 

where qs.last_execution_time > DATETIMEFROMPARTS(2018,06,24,13,56,50,0)

--and qs.last_execution_time < DATETIMEFROMPARTS(2018,06,24,13,57,0,0)

ORDER BY execution_count DESC;

 

Это представление группирует исполняемые запросы по тексту. Видно, как часто встречаются одинаковые тексты запросов. Например, при присваивании имени временной таблицы выполняется запрос типа SELECT 1 WHERE OBJECT_ID('tempdb..#tt674') IS NOT NULL.

Отчеты по DMV dm_os_wait_stats, dm_db_index_operational_stats отличаются от ситуации 1 только в процентном соотношении распределений количества latch.

 

Флаги трассировки, влияющие на latch

 

  • 8048 – применяется в случае, если в вашей системе более 8 логических процессоров и наблюдается большое число ожиданий CMEMTHREAD и кратковременных блокировок.
  • 1117 - позволяет управлять параметрами роста таблицы TEMPDB. в случае, если используется несколько файловых групп.
  • 1118 - отключает смешанные экстенды. Влияет на GAM и SGAM. Pagelatch бывают PFS (pafe free space), IAM (index allocation map), GAM (global allocation map), SGAM (shared global allocation map).

 

Более подробно смотрите на ИТС – новая статья  Флаги трассировки для работы с MS SQL Server http://its.1c.ru/db/metod8dev/content/5946/hdoc/_top

 

Выполним команду DBCC TRACESTATUS (1118), результат ниже

TraceFlag

Status

Global

Session

1118

0

0

0

 

Выполним команды DBCC TRACEON (1118); DBCC TRACESTATUS (1118), результат ниже

TraceFlag

Status

Global

Session

1118

1

0

1

 

Проверим, как влияет на количество latch. Запустим нагрузочный тест. Ниже отчет монитора производительности. Длительность latch была значительной, почти 2,6 секунды и ощутимо уменьшилась.

 

Не знаю, насколько чисто мне удалось выполнить этот эксперимент. Повторял несколько раз - получается. У меня возникло ощущение, что для прекращения использования нового флага трассировки службу сервера иногда приходится перезапускать. Проверьте у себя – поделитесь впечатлениями.

Любопытно, что в стандартных отчетах MS SQL Manager Studio видны изменения флагов трассировки от стандартных установок: Max degree of parallelism и TraceFlag 1118.

Кстати

Свойство SQL request wait - длительность запросов, о котором Виктор рассказывает в докладе на минуте 17, описано https://docs.microsoft.com/ru-ru/sql/database-engine/configure-windows/configure-the-query-wait-server-configuration-option?view=sql-server-2014. Посмотреть список таких свойств свойств можно командой select * from sys.configurations.

 

Заключение

Уважаемый читатель, если Вы добрались до этой строчки, значит есть интерес. Ищу мотивацию писать дальше, повторить исследование для postgres. Лучше, если это будет нужно не только мне, а кому-то еще. Поэтому я беру на себя супер-обязательство: если тема будет интересна и наберет хотя бы 50 звездочек на Инфостарт, я изучу postgres и дополню статью. Ошибки и неточности этой статьи буду исправлять по мере возможности. Кроме этого, жду Ваших конструктивных замечаний. Все в ваших руках.

Скачать файлы

Наименование Файл Версия Размер
Нагрузочное тестирование

.zip 89,24Kb
4
.zip 89,24Kb 4 Скачать

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Andrefan 29.06.18 17:14 Сейчас в теме
Спасибо, интересно. Глубоко копнули. Не хватает итогового резюме: плюсов и минусов каждого из тестов с точки зрения нагрузки.
2. vasilev2015 2556 05.07.18 17:22 Сейчас в теме
вместо perfmonitor можно было использовать dm_os_performance_counters
3. Дмитрий74Чел 226 10.08.18 06:53 Сейчас в теме
Статья хорошая, но комментариев нет. Возможно потому что тест выполнен абстрактный, коллеги не видят его прикладной пользы.
Думаю многим было бы интересно увидеть результаты теста на типовой конфигурации (например, ERP), с результатами применения флагов трассировок.
6. vasilev2015 2556 13.08.18 13:20 Сейчас в теме
(3) Да, возможно. Для меня так тестировать - слишком трудозатратно. Первого шага достаточно.
4. zaharknyaz 13.08.18 12:41 Сейчас в теме
Спасибо, интересная статья. Вопрос-может ли как-то отрицательно повлиять флаг трассировки 1118, например раздует размер всех баз в инстансе(насколько я понимаю этот флаг включается глобально для всего SQLServer).
7. nvv1970 14.08.18 07:51 Сейчас в теме
(4) 1118 - это рекомендация не 1с. Это рекомендация самой МС. А в свои скрипты Гленн Берри включает описания в т.ч. тех же флагов, что и Скворцова в статье на КБ.
В 2016 все включено по дефолту и кажется эти флаги действия уже не имеют.
Юзайте свежее по.
9. vasilev2015 2556 14.08.18 08:59 Сейчас в теме
(7) Да, я заметил что многие флаги, которые есть в MS SQL 2012, в MS SQL 2016 уже включены.
5. vasilev2015 2556 13.08.18 13:16 Сейчас в теме
Здравствуйте ! Спасибо за интерес. Флаг трассировки хорошо документирован MS, посмотрите в первоисточник. Это будет надежнее моего ответа )).
8. nvv1970 14.08.18 07:54 Сейчас в теме
Отличная статья. Звезда.
Оставьте свое сообщение

См. также

Простой способ проверки быстродействия

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

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

10.04.2023    2088    vkrivov@yandex.ru    14    

32

Пример многопоточной обработки (БСП)

Обработка документов HighLoad оптимизация Обработка справочников БСП (Библиотека стандартных подсистем) Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

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

13.02.2023    6229    4    echo77    8    

76

Нагрузочное тестирование в 1С:ERP

HighLoad оптимизация Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

02.11.2022    4107    Tavalik    23    

34

MS SQL Server: ваши статистики не работают! Так ли все плохо на самом деле?

HighLoad оптимизация Бесплатно (free)

Состояние и качество статистик критически важны для эффективной работы системы. Но у заметной части типовых конфигураций статистики просто не могут работать эффективно. О том, почему так происходит и что с этим делать, на конференции Infostart Event 2021 Post-Apocalypse рассказал Александр Денисов.

27.09.2022    3382    Филин    11    

37

Утилита тестирования сервера 1С от HADGEHOGs

HighLoad оптимизация Мониторинг Платформа 1С v8.3 Россия Бесплатно (free)

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

21.09.2022    13414    1022    Hadgehogs    56    

132

Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

От быстродействия запросов, которые обращаются к крупным таблицам, напрямую зависит скорость работы всей базы в целом. Артем Кузнецов, тимлид команды 1С в компании ООО «Финтех решения» на конференции Infostart Event 2021 Moscow Premiere рассказал, как оптимизировать производительность при поддержке больших систем. Показал, на что следует обращать внимание при код-ревью запросов, как оптимизировать RLS, виртуальные таблицы, индексы и условия, и как доработка архитектуры решения может ускорить работу базы.

29.08.2022    6453    Chernazem    44    

109

Ускорим проведение в 1С:Управление холдингом

HighLoad оптимизация Запросы Платформа 1С v8.3 1С:Управление холдингом Бесплатно (free)

В 1С:Управление холдингом есть "нехороший" запрос, который съедает значительную часть времени проведения документов. Если его подправить, то проведение заметно ускорится.

10.08.2022    5363    sapervodichka    64    

74

Методика похудения для 1С – 100%

Свертка базы HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

28.07.2022    6059    1CUnlimited    39    

45

Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории

HighLoad оптимизация Механизмы платформы 1С Запросы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

11.07.2022    5826    it-expertise    27    

57

10 «заповедей» эксплуатации крупной информационной системы 1С

Управление ИТ-подразделением Внедрение ИТ-системы HighLoad оптимизация Бесплатно (free)

Крупные системы 1С давно уже перешагнули и десятки терабайт, и тысячи пользователей, но во многих случаях подход к эксплуатации таких систем остаётся не на должном уровне. Антон Дорошкевич на конференции Infostart Event 2021 Post-Apocalypse поделился более чем 10-ти летним опытом эксплуатации подобных систем, сведя его к 10 «заповедям», соблюдение которых сделает 1С надёжнее, а труд разработчика – благодарнее и благороднее.

11.07.2022    7973    a.doroshkevich    33    

86

Решение проблем подвисания 1С “в онлайне”. Инструмент - консоль управления блокировками и процессами 1С и PostgreSQL (MS SQL - тестируется)

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 Управляемые формы 8.3.14 Конфигурации 1cv8 Абонемент ($m)

Обработка-консоль, улучшенная версия консоли администрирования 1С для решения проблем с производительностью, поиска и устранения блокировок и длительных запросов. Тестировалось на платформе 8.3.14, 8.3.17, 8.3.20 УФ.

1 стартмани

04.07.2022    7532    65    victor_goodwill    23    

38

Производительный режим работы RLS

HighLoad оптимизация Роли и права Платформа 1С v8.3 8.3.14 8.3.6 8.3.8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х Бесплатно (free)

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в данном материале.

14.06.2022    9403    Neti    7    

97

Любовь. Быстродействие. 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

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

26.05.2022    4244    vasilev2015    20    

34

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

HighLoad оптимизация Администрирование СУБД Платформа 1С v8.3 8.3.14 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

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

24.05.2022    4326    avolsed    15    

33

Несколько слов про платформенный механизм оптимизации RLS

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    3901    ivanov660    23    

69

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

HighLoad оптимизация Механизмы типовых конфигураций Запросы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    5923    it-expertise    92    

68

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

HighLoad оптимизация Технологический журнал Платформа 1С v8.3 Бесплатно (free)

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    13699    ivanov660    18    

147

Привилегированные отчеты

Роли и права HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Расширение позволяет настроить для пользователей выполнение отчетов в привилегированном режиме. 1) Убирает тормоза формирования отчета, возникающие при наложении прав пользователя на запросы отчета; 2) Позволяет обойти ошибки формирования отчета из-за отсутствия прав на часть объектов у пользователя.

4 стартмани

24.01.2022    11311    27    sapervodichka    36    

102

Ускорение работы конфигуратора 1С с большими прикладными решениями

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Ускорение работы 1С конфигуратора с большими прикладными решениями путем размещения системных каталогов 1С на RAM диске.

13.01.2022    7462    stg2005    105    

40

AMD RYZEN 5600X: погоня за попугаями

HighLoad оптимизация Бесплатно (free)

Все по-взрослому...

08.12.2021    8630    starik-2005    333    

39

Инструкция по получению плана запроса через Extended Events

HighLoad оптимизация Бесплатно (free)

Доброго времени суток, коллеги. Хочу рассказать, как можно посмотреть план запроса через механизм Extended Events. Я хочу ответить на вопрос - как разработчику через SQL Management Studio посмотреть, что запрос, который он сделал, работает оптимально. На Инфостарте есть несколько статей, которые посвящены трассировкам в этом механизме. Мне, когда я не понимал, как это правильно делать, не хватало простой пошаговой инструкции. Я напишу инструкцию, выполняя которую можно будет увидеть план запроса, который выполняется из базы данных.

22.11.2021    3106    Andrei_Ivanov    3    

46

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB-интеграция HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    4971    sorter1    3    

47

Изыскания на тему записи в регистр сведений

HighLoad оптимизация Платформа 1С v8.3 Платформа 1C v8.2 Конфигурации 1cv8 Абонемент ($m)

Уважаемые коллеги, здравствуйте! Сегодня хочу поделиться с Вами своими изысканиями на тему записи в регистр сведений в контексте оптимизации одной операции. Однажды мы столкнулись со следующей проблемой: поступили жалобы от разработчиков сайта, что наш веб-сервис очень медленно реагирует, точней, обработка запроса не укладывается в таймаут 5 секунд, и сайт получает ошибку 500. Стали разбираться, и вот что выяснили.

1 стартмани

21.09.2021    14100    0    METAL    57    

104

Адекватный параллелизм в 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    15578    Shmell    8    

59

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

HighLoad оптимизация Бесплатно (free)

В статье описан подход, позволяющий создавать счетчики производительности Windows для 1С:Предприятие.

09.08.2021    5091    blackhole321    8    

50

Распространенные ошибки разработчиков, приводящие к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

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

02.08.2021    16600    ivanov660    77    

142

Parameter sniffing и генерация планов для разработчиков 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    15811    vasilev2015    17    

35

Поиск причин блокировок СУБД

HighLoad оптимизация Платформа 1С v8.3 Управление блокировками Конфигурации 1cv8 Бесплатно (free)

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    8534    vasilev2015    14    

84

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

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    8176    AlexKriulin    37    

78

Соединение вложенными циклами

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    5302    vasilev2015    22    

61

Анализ блокировок СУБД: таблица изменений плана обмена 1С

HighLoad оптимизация Платформа 1С v8.3 Бесплатно (free)

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

18.12.2020    5979    zhichkin    11    

36

Контекст всегда важен. История проблем производительности

HighLoad оптимизация Бесплатно (free)

Небольшая история о проблемах производительности из-за нехватки процессорных мощностей. А также описание основных показателей работы CPU.

26.11.2020    10214    Infostart    21    

133

Анализ проблем производительности по динамике мониторинга RAS 1C

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

07.10.2020    7963    ivanov660    13    

69