- Докладчик
- Что вас сегодня ждет на мастер-классе?
- Запускаем тест
- Подготовка нагрузочного теста
- Перевод продуктива на Postgres
- А можно без нагрузочного теста?
- Смотрим как идет наш нагрузочный тест
- Бонус (домашнее задание)
- Заключительная часть мастер-класса
- Вопросы и ответы
Докладчик
Меня зовут Симонов Александр, я работаю в компании "Тантор Лабс", вендоре СУБД семейства Postgres, где занимаюсь вопросами на стыке 1С и самой СУБД. Как я здесь оказался? После универcитета попал в компанию "Магнит", где проработал 14 лет и возглавлял как разработку 1С, так и центр экспертизы 1С. В 2021 году, когда в компании начался проект импортозамещения, мы вместе с командой за год перевели на Postgres 10 ИС, в том числе активно используя нагрузочные тесты. Это было быстрое погружение в Postgres, очень ценный опыт. Мне понравилось переводить ИС на Postgres, мне в принципе нравится этот процесс. 2 года назад я перешел в компанию Sunlight, где руководил разработкой 1С, но спустя какое-то время я понял, что теряю накопленные компетенции по Postgres, и с начала этого года начал постепенно погружаться в работу в вендоре СУБД, в котором также приходится много работать с нагрузочными тестами. Круг задач после разработки 1С довольно специфичен, заставляет на многие вещи смотреть по-другому. Люблю не только технические вопросы, но и правильно выстраивать процессы разработки 1С - об этом хочу рассказать на одной из следующих профильных конференциях Инфостарта.
Что вас сегодня ждет на мастер-классе?
Цель доклада - показать, что несколько тысяч пользователей в базе 1С на Postgres сейчас - это ничего сверхъестественного, все больше это становится нормой.
В рамках мастер-класса сначала мы запустим нагрузочный тест на 3К пользователей и, пока он будет запускаться и идти своим чередом, поговорим о следующем:
- что это за тест и какое железо нужно для проведения такого теста;
- когда следует проводить нагрузочное тестирование, а когда им можно пренебречь, и какие для этого нужно учитывать факторы. Расскажу на примерах из своего опыта;
- посмотрим, как ведет себя оборудование во время теста, и попробуем сэмулировать проблемы производительности;
- приведу примеры, какие проблемы позволяют выявлять нагрузочные тесты.
В конце доклада вас всех ждет приятный бонус, который позволит каждому из вас запустить свой нагрузочный тест и расследовать типичные проблемы, с которыми сталкиваются технические специалисты при переводе баз 1С на Postgres.
Запускаем тест
Открываем справочник "Сценарии тестирования", в списке выделяем строку с наименованием "Полный тест (3000 пользователей)" и нажимаем "Выполнить". Тест будет запускаться примерно 20-25 минут, а мы пока поговорим о самом тесте и нагрузочном тестировании.
О тесте
Тест будем проводить на конфигурации "1С: Документооборот" редакции 2.1, профиль нагрузки смешанный.
Данный тест не синтетический, а написан под конкретного заказчика согласно его профиля нагрузки, определенного в ходе исследования. Разработала тест компания "ИТ-экспертиза".
Какие операции выполняют виртуальные пользователи:
- 50% пользователей выполняют OLTP-операции: записывают внутренние документы, стартуют бизнес-процессы, выполняют задачи, открывают формы, сопутствующие выполнению этих операций. Средняя длительность данных ключевых операций - до 3х секунд;
- 40% формируют отчеты - средняя длительность 4-120 секунд;
- 10% работают с обработками - средняя длительность 5-15 секунд.
Стенд
Стенд состоит из следующих компонентов:
Сервер приложений.
3 ВМ по 32 CPU, 128 Гб RAM, 300 Гб СХД.
Платформа 8.3.23.2157, ОС Astra Linux 1.7.5.
1 центральный сервер и 2 рабочих. На центральный через ТНФ вынесены сервисы журнала регистрации, полнотекстового поиска и лицензирования. Вообще, конечно, под сервис лицензирования правильно выделять отдельный сервер, но в данном тесте мы этого не стали делать.
Все остальные настройки кластера - по умолчанию.
Сервер СУБД.
Физический сервер Tantor XData version 1.0 c 96 CPU, 374 Гб RAM (c RAM есть нюанс, который рассмотрим ниже).
2 диска:
- основной - data-каталог, где находится сама база данных;
- второй - вынесены WAL, а temp_tablespaces нет. И мы сегодня рассмотрим, к чему это может привести.
Физически эти диски разные.
СУБД Tantor Special Edition 1C 16.2.1, ОС Astra Linux 1.7.5.
Терминальные сервера.
10 ВМ с характеристиками 16 CPU, 64 Гб ОЗУ, 100 Гб диск.
На каждой ВМ запускается 5 терминальных пользователей, каждый из которых открывает по 60 ВРМ (сеансов 1С).
Настройки Postgres
Думаю, что все уже умеют настраивать Postgres. Я лишь расскажу о некоторых нюансах.
Первый из них - это JIT. Данная настройка должна быть выключена - именно на этом тесте он дает деградацию более 10%. Также это приводит к повышенной утилизации процессора.
Вот пример, как в листинге плана запроса отображается, какое количество времени съедает JIT, при этом пользы от него никакой:
Это реальный пример запроса из данного нагрузочного теста. Запрос выполнялся 10.5 секунд, из них половину времени заняла JIT-компиляция. Зачем она нужна?
Документация гласит:
JIT-компиляция - процедура преобразования интерпретируемого варианта исполнения программы в программу на языке процессора. Например, вместо "WHERE a.col = 3" можно сгенерировать функцию, которую сможет выполнять непосредственно процессор, так что она будет выполняться быстрее.
В 1С эффекта от данного функционала нет. Если у вас включен JIT - отключите его, ваша система станет работать быстрее!
UPD: Начиная с версии 15.6.2 в Tantor SE 1C мы изменили значение по умолчанию с ON на OFF у JIT, чтобы уменьшить вероятность неоптимальной настройки СУБД под 1С у клиентов.
Второй нюанс - это как раз 2 настройки планировщика:
join_collapse_limit = 20
from_collapse_limit = 20
Данные параметры позволяют Postgres при планировании перебирать большее количество вариантов соединения таблиц, что может позволить как можно раньше выбрать соединение наиболее селективных таблиц, которые сильно сократят выборку. А, как мы знаем, в запросах 1С количество соединений более 10 может встречаться часто.
Вот пример как раз такого запроса, в котором 15 соединений. Если параметры стоят в 10, то мы получаем вот такой план. На скриншоте выделен отбор по регистратору регистра сведений - селективнейший отбор - но Postgres решает наложить его в конце, т.к. перебирая различные варианты соединения не учел вариант, что можно сразу этот отбор наложить. Если увеличить до 20, то он находит оптимальный вариант.
Давайте теперь поговорим о том, когда следует готовить и проводить нагрузочное тестирование. Для этого я расскажу вам примеры из своего опыта, а потом мы зафиксируем факторы, которые нужно учитывать при принятии решения, нужен ли нагрузочный тест или нет.
Подготовка нагрузочного теста
По сути, свой первый полноценный нагрузочный тест я разработал как раз при миграции на Postgres. Было это 3 года назад в "Магните", когда стартовал проект импортозамещения.
Но сначала немножко теории.
Уровни критичности систем
При принятии решения, писать нагрузочные тесты или нет, мы руководствовались двумя факторами:
- Т.к. Postgres для нас был чем-то новом и незнакомым, то мы, конечно, решили сделать осознанный шаг в неизведанное. Мы не могли себе позволить в продуктиве перевести систему на Postgres без понимания, что может нас будет ожидать в первые часы после перевода.
- Также в компании у каждой системы был свой уровень критичности. Они бывают следующие:
- Mission Critical - время восстановления в случае сбоя - 10 минут (в случае простоя такой системы бизнес теряет деньги, репутацию, не получает прибыль. Самый подходящий пример такой системы - это розница; если она не работает, то магазины не продают);
- Business Critical - время восстановления до 2 часов (в случае простоя бизнес-пользователи не могут выполнять свои основные функции. По сути компания платит сотрудникам за простой. Пример - ERP-система бек-офиса);
- Business Operational - время восстановления 4-6 часов (это, как правило, сервисные системы. Например, Итилиум или СППР. Функции свои бизнес выполнять сможет, но усложнятся привычные коммуникации);
- Office Production - время восстановления 1-2 дня (такие системы обычно не требуют резервирования. Продуктивных баз у нас такого уровня не было, лучше всего сюда для примера подходят копии баз в зоне разработки).
Системы уровня Business Critical и Mission Critical тестировать нужно, т.к. время простоя в случае инцидента может быть дороже, чем ресурсы, потраченные на тестирование.
И, конечно, для таких систем всегда используем принцип "1 инстанс СУБД - 1 база", и никаких совмещений СУБД и СП на одной машине.
Давайте теперь рассмотрим подходы для подготовки тестирования.
Системы для перевода
Для перевода мы выбрали 3 базы:
2 базы ДО, которые использовались как сервис для работы с задачами в КИС (расшифровывается, как корпоративная информационная система). На схеме изобразил, как были связаны базы: КИС Центр - это центральная база, где агрегируется вся информация, ей подчинена КИС ГКЦ.
И для каждой из этих баз КИС была поднята своя отдельная база ДО по той причине, что базы КИС, с которыми они связаны, имеют разный уровень критичности, и в случае инцидента в базе ДО на функционале, связанном с менее критичной базой, пострадала бы и более критичная база.
Но при этом эти базы ДО имели единую конфигурацию для удобства сопровождения.
Интерактивно пользователи в базах ДО не работали. На слайде приведено то количество пользователей КИС, которые выполняли функции, связанные именно с интеграцией с ДО. Вообще в КИС Центр работало 4 тысячи пользователей, в КИС ГКЦ 2 тысячи, уровень критичности указан именно баз КИС. По сути для проведения НТ нам требовалась и база КИС, т.к. все сценарии нагрузочного теста разрабатывались именно для нее.
СППР - по сути, задачник, аналог Jira, в нем был выстроен бизнес-процесс разработки как 1С ,так и других языков программирования.
По факту сейчас бы я для СППР не писал нагрузочный тест, а поступил бы по-другому и об этом я сегодня тоже расскажу, когда можно не проводить нагрузочный тест, но тогда мы решили для нее также написать его.
Составление сценария нагрузочного тестирования
Для подготовки сценария нагрузочного тестирования мы выбрали 2 разных подхода, давайте рассмотрим их.
По данным APDEX
Первый из них по данным APDEX.
Для ДО я понимал какие операции в ней выполняются, т.к. сам участвовал в ее внедрении со стороны разработки. Пользователи выполняли 5 основных действий:
- Запуск бизнес-процесса;
- Согласование/отклонение задачи;
- Просмотр отчета о прогрессе выполнения бизнес-процесса по документу;
- Работа со списком задач;
- Массовый старт бизнес-процессов, когда в систему загружали огромное количество заявок на расход, для которых бизнес-процесс согласования и использовался.
Все это было покрыто ключевыми операциями APDEX, и я мог из стандартного отчета БСП "Оценка производительности" получить информацию, сколько раз и какое действие выполнялось, с каким средним временем.
Я взял данные за целый рабочий день, но в рамках нагрузочного теста весь объем этих операций должен был выполниться за 1 час. Это один из принципов разработки 1С, принятый в компании - создавать решения с большим заделом масштабируемости.
Как запрограммировать ключевую операцию в сценарий?
Например, у нас есть ключевая операция "Согласование задачи "Заявка на расход".
Для начала нужно найти в коде, когда выполняется данная операция, затем составить список действий, которые должен выполнить пользователь для выполнения этой операции.
В нашем случае получается следующий порядок действий: Открыть форму списка "Мои задачи" → Найти в списке задачу по конкретному документу → Открыть форму задачи по документу → Нажать кнопку "Согласовано" на форме задачи.
Все эти действий программируем в сценарий.
Из отчета "Оценка производительности" каждую ключевую операцию можно расшифровать до конкретных пользователей и таким образом составить профиль пользователя для сценария, который ее должен выполнять.
И так делаем по каждой ключевой операции, здесь нет ничего сложного.
По данным ТЖ
Для СППР мой коллега собрал ТЖ за неделю работы и на основе его по событиям CALL составил картину, какие действия в базе сколько раз выполняются. На мой взгляд, это самый объективный способ, если вы хотите повторить реальную нагрузку в НТ.
Как определяется целевое время? Эта система APDEX была покрыта лишь частично, и среднее время бралось из среднего времени соответствующего события CALL.
Порядок действий:
- Собираем ТЖ события CALL с отбором по выполнению именно в тонком клиенте, фоновые задания нам не нужны.
- Агрегируем скриптами логи ТЖ: мы можем получить информацию в нужных разрезах до пользователя, количества выполнения и средней длительности.
- Но не все CALL'ы полезны, допустим 4 строка - это просто открытие формы отчета, а не его формирование и по сути нужно было из этих CALL'ов выкинуть все лишнее, это уже работа эксперта.
Чем хороши оба этих способа составления сценария нагрузочного теста? Тем, что нам не нужен бизнес для составления и утверждения сценария нагрузочного теста, т.к. мы сами можем получить все нужные данные из информационной базы.
Мы подготовили сценарии, провели тесты, по их итогам нашли несколько неоптимальных запросов, оптимизировали их. Этот процесс занял у нас примерно 2 месяца с учетом выполнения и других задач основной работы.
Мы готовы к переходу на Postgres.
Перевод продуктива на Postgres
Независимо от того, делали вы нагрузочный тест или нет, перед тем ,как выполнить переход в продуктиве, очень важно замерить тайминги в тестовой зоне, чтобы понимать технологическое окно, которое вам потребуется для перевода, а также составить план перехода, указать ответственных и обкатать порядок всех действий.
Вот проблемы с которыми я сталкивался при тестовом прогоне:
- При переводе через выгрузку/загрузку DT не хватало места под файл выгрузки. Сначала он грузится в темп сервера приложений, а затем сохраняется на диск, поэтому умножайте требуемое место на 2.
- Также при через выгрузку/загрузку DT выполняйте эти операции прямо на сервере приложений, чтобы уменьшить сетевые задержки.
- Ошибка "Поле таблицы не может принимать значение null"- если конфигурация была создана когда-то давно, то в ней могут быть таблицы, у которых в полях может быть null, потому что раньше платформа это позволяла и эти таблицы не реструктуризировали с тех времен. При загрузке из DT вы такие данные залить не сможете, т.к. Postgres вам будет явно говорить, что данное поле не может быть null согласно структуре метаданных, которые создает платформа 1С при загрузке из DT. Это не является ошибкой платформы. Для исправления необходимо на MS SQL найти проблемные таблицы и исправить данные в них, чтобы там не было null (проставить значение по умолчанию согласно типа поля).
- Ошибка "invalid memory alloc request size" - MS SQL позволяет хранить в полях до 2 Гб, Postgres до 1 Гб. Поэтому при загрузке таких таблиц, у которых запись будет содержать более 1 Гб можно получать такую ошибку. Нужно определить таблицу на которой это происходит, найти в ней запись большого размера и уменьшить ее размер (очистить или разбить на несколько записей, например)
UPD: В редакции СУБД Tantor Special Edition 1C, начиная с версии 15.6.2, решена проблема из п.4. Добавлен GUC "enable_large_allocations", позволяющий выделять память для объектов до 2 Гб.
А вообще используйте автономный сервер (утилита ibcmd). Он позволяет минимизировать промежуточные этапы и сразу льет данные напрямую в базу, таким образом вы решите проблемы указанные в первых 2х пунктах.
Итог первого перевода:
Перевод в продуктиве прошел гладко. Конечно, мы не сразу все системы переводили, а сначала одну посмотрели, что все работает стабильно, и потом следующую.
Для баз ДО мы после перевода ничего не оптимизировали, а для СППР "выстрелили" несколько отчетов из-за использования среза последних без отборов.
Вообще, первые дни после перевода у меня лично было волнение, что вдруг что-то перестанет работать, что вот вдруг Postgres возьмет посреди дня остановится. Но никаких проблем не было, и через месяц после перевода уже стало казаться, что это было очень легко, непонятно, что вообще переживали по поводу перехода на Postgres.
А можно без нагрузочного теста?
Далее я вам расскажу про перевод еще одной базы, чтобы ответить на вопрос "когда можно не делать нагрузочный тест?".
Это была база ТОиР.
Основными пользователями этой системы были внешние подрядчики, которые занимались ремонтом и обслуживанием магазинов сети. Она заходили в базу через веб-клиент, чтобы работать всего лишь с одним документом - "Заявка на ремонт".
Внутренние пользователи выполняли функции контроля исполнения заявок и отчетности. Отношение внешних и внутренних пользователей - 90/10.
Разрабатывали и сопровождали эту систему внешние подрядчики, поэтому перед переводом нам нужно было получить объективную картину проблем производительности системы.
У нас активно использовался эластик для работы с логами технологического журнала, в нем довольно просто было получить список топ-длительных запросов в разрезе контекстов исполняемого кода 1С. Также мы дополнительно пообщались с основными аналитиками ИС, чтобы получить от них список проблем производительности, которые по сути и подтвердили данные эластика.
Сервер СУБД MS SQL был следующей конфигурации: 96 CPU, 4 Тб ОЗУ. При этом процессор утилизировался в среднем на 30-40%, выделенные ресурсы выглядели избыточными.
А вот сервер Postgres по стандартам компании должен был быть максимум 24 CPU 128 Гб ОЗУ. Более мощный сервер тоже можно было получить, но это пришлось бы дополнительно обосновывать.
И мы поставили себе цель снизить нагрузку на CPU до 10% в среднем, чтобы после перевода на Postgres еще и иметь какой-то запас прочности.
Имея информацию о проблемах, критичности системы, характера ее нагрузки и опыт за плечами перевода других систем был составлен следующий план:
- Оптимизировать основную бизнес-операцию, которая больше всего нагружала систему. Это был динамический список, с которым работали внешние пользователи. Пришлось переделать архитектуру системы.
- Оптимизировать тяжелые отчеты, которые выполнялись минутами.
- Уменьшить размер базы с 2.5 до 1 Тб, выполнялось это очисткой неиспользуемых ОМД и хранимых файлов.
- Провести простейший тест, чтобы убедиться что на Postgres одновременно может работать 1500 пользователей.
Последний пункт для меня был самым большим риском, потому что такое количество пользователей на Postgres у нас еще не было. Мы решили для этого просто запустить 1500 ФЗ, которые выполняли простое действие.
В случае если после перевода будут проблемы производительности, то устранение в течении дня устраивало бизнес-пользователей, они готовы были подождать если какой-то отчет будет формироваться дольше.
А вот если бы возникла проблема с функцией, которую выполняли внешние пользователи, то решить ее нужно было экстренно в течение 2х часов. Мы были к этому готовы.
Таким образом решение не проводить нагрузочный тест обосновывалось следующими факторами:
- Вы можете протестировать главный риск другим способом. В нашем случае это одновременный запуск 1500 пользователей.
- У вас есть опыт перевода, вы знаете какие основные проблемы стоит ожидать и готовы к их быстрому решению после перевода.
- У вас есть поддержка от владельцев системы и их готовность находить общий язык с бизнесом.
В течение квартала мы выполнили все эти 4 пункта. Они намного лучше чем просто нагрузочный тест, т.к. они делают саму систему лучше!!!
После перевода в продуктиве несколько инструментов внутренних пользователей деградировали, мы их оптимизировали в течении 2х дней. Но потом еще на протяжении 2х недель сталкивались с неоптимальными запросами и оптимизировали их.
Как я сказал, у нас был эластик, и мы сами видели все проблемы, которые были в системе, что по сути было проактивным решением проблем, а не ожиданием жалоб от пользователей.
Смотрим как идет наш нагрузочный тест
Открываем базу 1С и проверяем, что тест успешно запустился и сейчас выполняется. Давайте посмотрим, как ведет себя оборудование.
Показатели оборудования
На сервере СУБД нагрузка растет по мере запуска сценариев, и в среднем в ходе теста по CPU будет утилизация 30-40%. Выше я говорил про нюанс с RAM, что ОЗУ на СУБД выделено 378 Гб, а тут графике 768 Гб. Дело в том, что Tantor XData - это физическая машина, и поэтому мы выделили часть памяти под Huge pages (огромные страницы), чтобы Postgres'у оставить ровно 378 Гб. В настройках Postgres'а огромные страницы явно отключены (huge_pages=off), и он не сможет использовать память, которая под них выделена.
На сервере приложений в момент запуска 3 тысяч тонких клиентов были пики утилизации CPU до 100%.
Аналогичные пики утилизации CPU были и на терминалах, где работают тонкие клиенты. На итоговый отчет производительности эти пики никак не повлияют, т.к. они были до фактического старта выполнения ключевых операций.
В чем основная суть этого дашборда? Для того чтобы нагрузочный тест считался успешно проведенным, он не должен "упираться" в оборудование. Как на СУБД, так и на СП, и на терминальных нагрузчиках. Иначе результаты нагрузочного теста не будут достоверными и каждый раз вы будете получать различные результаты по среднему времени выполнения ключевых операций, они могут сильно "скакать".
Допустим вы сравниваете 2 различные сборки СУБД: 15 и 16 Postgres. Разное время ключевых операций наведет вас на мысль, что что-то поменялось в самих механизмах СУБД, хотя по факту их время отличается по другим причинам (из-за утилизации оборудования).
Но есть исключение, допустим, у нас есть небольшие пики по CPU. Тут важно в тесте учесть, что ваши операции должны происходить равномерно в течении всего теста, чтобы не было такого, что они все пришлись на пик. Тогда если они равномерно распределены, то в пике они могли выполняться дольше чем обычно за счет утилизации ресурсов, но во все остальные выполнения время будет корректным и в итоге среднее время вы получите адекватное.
Давайте вернемся к СУБД, а именно к графику утилизации диска:
Что же так утилизирует диск? Для того чтобы ответить на этот вопрос, я делал этот тест, но с выносом временных таблиц на отдельный диск (за это отвечает параметр Postgres'а temp_tablespaces) и без выноса временных таблиц получил следующие результаты.
Из данного графика видно, что утилизируют диск именно временные таблицы. Но почему они это делают, если они должны создаваться в оперативной памяти? Тут дело во внутреннем устройстве Postgres'а: независимо от того какое значение у вас установлено в параметре temp_buffers при создании временной таблицы на диске создается файл размером 8 Кб на тот случай, если вдруг не временная таблица будет размером больше чем значение в temp_buffers и ее придется "скидывать" на диск. И так происходит при создании каждой временной таблицы, поэтому это и создает такую нагрузку на диск. Поэтому для высоконагруженных систем и рекомендуется выносить временные таблицы через параметр temp_tablespaces на отдельный диск/диски.
UPD: Мы планируем доработать СУБД Tantor Special Edition 1C, чтобы файл на диске создавался только в тех случаях, когда временная таблица "скидывается" на диск. Это поможет значительно уменьшить нагрузку на диски.
Эмулируем проблемы
Давайте теперь подумаем о тех случаях, которые могут быть в реальном продуктиве с большим количеством пользователей. Сами создадим проблемы и посмотрим как это повлияет на APDEX.
Большая временная таблица
Давайте поместим в временную таблицу 400 млн строк. Как обычно бывает: пользователь написал в консоли запрос, запустил его - он завис - и срубает свой сеанс в диспетчере задачи, думая, что никто не узнает, но по факту это же не так. Он продолжит выполняться.
Такая временная таблица будет размером больше чем значение temp_buffers (256 Мб), поэтому Postgres при создании такой временной таблицы будет делать следующее:
- 256 Мб данной временной таблицы действительно будет размещено в оперативной памяти
- Остальную часть временной таблицы начнет "скидывать" на диск файлами по 1 Гб
Запускаем наш запрос и видим, что действительно у нас начинает утилизироваться место на диске - растет размер data-каталога, где хранится сама база данных и куда также "скидывается" временная таблица файлами по 1 Гб:
Есть еще такой вариант, как вынести временные таблицы в оперативную память через temp_tablespaces - в этом случае data-каталог расти не будет, т.к. временная таблица будет размещаться в оперативной памяти. Но, как правило, оперативной памяти меньше, чем места на диске, поэтому в случае создания огромной временной таблицы память может закончиться, и такой сеанс получит ошибку:
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка СУБД:
53100: ERROR: could not extend file "pg_tblspc/6539232/PG_15_202209061/16439/t13_9297341": No space left on device
HINT: Check free disk space.
Все другие сеансы, которые в этот же момент, хотели поместить данные во временные таблицы, получат аналогичную ошибку и аварийно завершатся.
Но место в каталоге временных таблиц данные сеансы, которые завершились аварийно, удерживать не будут, поэтому все остальные сеансы, которые в момент проблемы не пытались поместить временную таблицу в оперативную память, продолжат успешно работать, и их последующие попытки поместить данные во временные таблицы завершатся успешно.
Давайте посмотрим, как создание такой временной таблицы повлияет на показатели APDEX. Я написал отчет "Текущий APDEX", который рассчитывает и показывает APDEX по каждой ключевой операции в разрезе минут:
Как видим, на производительности это никак особо не отразилось. Дело в том, что у нас еще есть запас по дисковой подсистеме, которая в среднем утилизирована на 40-50%:
Завершаем данный сеанс и далее сэмулируем еще одну проблему производительности, когда запускается неоптимальный функционал, утилизирующий большое количество ресурсов.
Неоптимальные запросы к базе данных
Запустим 50 фоновых заданий, которые будут выполнять запрос, который выполняется около 3х минут. По задумке сейчас процессор на СУБД будет утилизирован в 100%, и мы посмотрим, как это скажется на APDEX.
Он становится хуже, опускается до уровня "удовлетворительно". Это и есть проблема. Помимо того, что процессор утилизирован, в 100% начинается расти количество соединений на СУБД.
Мы можем это увидеть на графике "Sessions" в платформе Tantor:
Вообще, этот показатель Sessions (количество активных сессий на СУБД) - отличный триггер для мониторинга. Он может показывать не только проблемы с процессором, но и другие, например, с диском или памятью. Ведь в случае больших очередей к диску или нехватки памяти сессии начнут ожидать освобождения ресурсов, что приведет к росту их количества.
На прошлом месте работы у нас триггер был настроен так: мы понимали, какое количество активных соединений СУБД для нашей базы являлось нормальным - 40. Если количество активных сессий становилось более 40 и так держалось 5 минут, то срабатывал алерт, что есть проблема и ответственным нужно разобраться, что происходит с системой. Он очень хорошо нам помогал обнаруживать проблемы, и, как правило, после его срабатывания через какое-то время приходил бизнес и жаловался на производительность. Рекомендую использовать этот показатель для алертинга.
Вот так - во время запуска данных фоновых заданий был нагружен процессор:
И после окончания фоновых заданий мы видим, что APDEX пришел в норму после того, как освободились ресурсы процессора, которые нужны нашим сеансам нагрузочного теста:
Завершение нагрузочного теста
Сейчас мы прервем наш нагрузочный тест, чтобы посмотреть на итоговый отчет APDEX:
Можно подытожить, что 1С прекрасно работает с несколькими тысячами пользователей на Postgres. Проблемы для работы СУБД может создавать функционал приложения, за которым нужно следить для поддержания качества работы высоконагруженных систем.
Нам всем стоит привыкнуть, что с каждым годом количество таких высоконагруженных инсталляций 1С на Postgres будет только расти, к тому же сейчас идет много активных проектов миграции на 1С с ПО западных вендоров, ушедших из России.
Бонус (домашнее задание)
Я подготовил нагрузочный тест для всех, кто хочет лучше узнать Postgres - в нем запрограммированы 3 проблемы долгого выполнения запросов на Postgres. Решив их, вы сможете решать большую часть проблем возникающих при/после миграции на Postgres.
Для запуска теста необходимо запустить нагрузочный тест по сценарию "Инфостарт 2024":
По итогам теста вы получите вот такой отчет:
Проблемы запрограммированы в 3х ключевых операциях, выделенных на данном скриншоте.
Среди них есть ключевая операция "Тест центр. документ. операция по платежной карте. форма списка документов. открыть форму", которую нужно оптимизировать изменением настроек Postgres'а, менять запросы в ней нельзя!
А также вам нужно самим написать сценарий для документа "Операция (регламентированный учет)".
Сценарий следующий:
- Открываем форму всех проведенных и непроведенных документов
- Если в строке 1 субконто 3 имеет тип справочник "Физические лица", то меняем его на значение на любое другое. Например, меняем "Григорьева Любовь Петровна" на "Дубинин Петр Николаевич".
- Проводим документ.
- Необходимо понять, в чем будет проблема долгого проведения документа и как можно ее решить.
Разработанный сценарий для документа "Операция (регламентированный учет)" необходимо также добавить в сценарий "Инфостарт 2024" Нагрузочный тест должен завершится, конечно же, успешно.
Есть такой нюанс, что вы написали тест, но он в конце упал из-за какой ошибки. Как все-таки увидеть отчет на закладке "Производительность"? Для этого нужно программно заполнить ТЧ "Производительность операций" временем начала и окончания теста по UTC времени, т.е. минус 3 часа. Отчет на закладке "Производительность" строится по следующей логике: он выбирает из регистра сведений "Замеры времени" все записи, дата замера которых попадает в период между началом и окончанием теста, и рассчитывает по ним статистические показатели по методике APDEX.
Тест рассчитан на стенд: 4 CPU, 16 Гб ОЗУ. Настройки Postgres под данный стенд приложены на странице задания, в качестве СУБД подойдет бесплатная сборка Postgres от фирмы 1С.
Вам нужно найти и решить все 4 проблемы (3 запрограммированые и одну по документу "Операция (регламентированный учет)") и прислать по кнопке ниже - первым трем участникам, кто найдет все проблемы до 22 декабря включительно, мы вышлем мерч Tantor.
На конференции Инфостарт 10 октября я предложил слушателям решить это домашнее задание в срок 31 октября. Решил его только один участник, и он уже получил наш фирменный мерч.
Для новичков в нагрузочном тестировании
Если вы никогда не писали нагрузочные тесты, то специально для вас на скриншоте приведен чеклист, как их начать писать, чтобы в том числе запрограммировать самим операцию из домашнего задания.
Ссылка на ИТС раздел "Тест-центр" - https://its.1c.ru/db/kip#content:30:hdoc
Заключительная часть мастер-класса
Что позволяет выявить нагрузочное тестирование?
Нагрузочные тесты позволяют находить различные проблемы, я их разделил на 2 категории.
Проблемы стабильности работы:
- Именно данный тест, который мы запускали на мастер-классе, приводил к ошибке "missing chunk number" на третьем часе выполнения данного нагрузочного теста. Эта ошибка была связана с работой 64-битного счетчика транзакций и потребовала доработки СУБД для ее исправления.
- Для тестирования СУБД Tantor SE 1C я написал нагрузочный тест на конфигурации ERP, в рамках которого 400 пользователей за 30 минут выполняют 25 тысяч операций. Это тест с очень интенсивным выполнением операций. Спустя 15 минут после начала теста постоянно приходил OOM Killer, и каждый раз причиной его прихода был разный функционал, т.е. это не один какой-то мегазапрос, который утилизируют большое количество ОЗУ на сервере СУБД. Отсюда можно сделать вывод, что для такой интенсивной нагрузки 64 Гб ОЗУ на сервере СУБД недостаточно.
Проблемы производительности:
- Когда идет сравнение с MS SQL, то целью такого нагрузочного теста будет именно выявление ключевых операций, которые стали хуже после миграции и оптимизировать их.
- В текущей работе я использую нагрузочные тесты для:
- проверки новых фич, как они повлияли на производительность: какие ключевые операции стали быстрее, какие медленнее;
- при выпуске следующего мажорного релиза, чтобы увидеть как изменения в ванильном Postgres влияют на общую производительность. Например, при выпуске релиза 16.2 изменилось время проведения некоторых документов в худшую сторону.
Нагрузочный тест показывает мне общую картину, а дальше я уже спускаюсь на уровень ключевой операции, разбираю, у каких запросов поменялось время выполнения, смотрю их планы, чтобы разобраться, какие изменения в СУБД привели к этому. И далее даю обратную связь разработчикам СУБД, если тестирую какую-то новую фичу или ставлю им задачу на разработку, если какие-то запросы стали выполняться медленнее.
Подведение итогов
При принятии решения проводить нагрузочный тест или нет учитывайте:
- Уровень критичности системы
- Насколько вы ее хорошо знаете и сколько время у вас будет на решение проблем после перевода, если они возникнут
- Наличии у вас компетенций и опыта сопровождения систем на Postgres
- Ваши цели и развитие в плане Postgres и как экспертов 1С. Если у вас нет опыта перевода систем на Postgres, то написание и проведение нагрузочного теста позволит лучше узнать устройство Postgres, особенности его работы и развивает вас как технических специалистов
- Если у вас задача проверить, как будет работать Postgres, допустим, при росте количества пользователей или нагрузки в несколько раз, то тут ответить на вопрос можно только проведением нагрузочного теста
Как подготовить нагрузочный тест и определить целевое время ключевых операций:
- 2 способа мы рассмотрели в рамках текущего доклада
- На прошлой конференции были интересные доклады на эту тему
UPD: Мне понравился подход из доклада с прошлой конференции - Нагрузочное тестирование на раз, два, три
Всегда делайте тестовый прогон для расчета технологического окна на проведение работ по переводу ИС на Postgres.
После перевода следите сами за системой, будьте проактивными, не ждите от бизнеса информации о проблемах!
Вопросы и ответы
Подскажите, сколько времени надо для написания хорошего и качественного нагрузочного теста?
Коллеги, которые разрабатывали этот тест покинули уже зал и ответить не могут. Нагрузочный тест ERP на 400 пользователей, ко котором шла речь выше, я написал за неделю, он покрывает основные операции, которые делают пользователи.
UPD: Уточнил у коллег из ИТ-экспертизы: на разработку этого теста на 3 тысячи пользователей потратили вместе с отладкой месяц работы одного эксперта.
Поделись критериями какими-то для хорошего нагрузочного теста, какие ошибки совершают начинающие?
Ошибки обычно совершают, когда в обработках сценариев что-то упускают, и сами сценарии в итоге начинают завершаться раньше времени. Или какая-то операция падает с ошибкой, а при этом все остальные выполняются успешно, но тем не менее тест считается проваленным. И очень сложно находить такие ошибки, я поначалу много времени на это тратил. На ИТС написано, как писать правильно, но тем не менее все равно можно где-то допустить ошибку.
Можно поподробнее почему растет количество сеансов, когда мы сталкиваемся с ограничением ресурсов?
Потому что приходит на СУБД новое соединение, которое хочет выполнить запрос. Ему нужны ресурсы процессора, а именно воркеры, которые все заняты. И сессия остается ждать их освобождения, и она является активной. Так приходят еще и другие соединения, которые становятся в очередь и количество активных сессий растет.
Вы говорите, что есть технологии составления сценария нагрузочного тестирования без участия бизнеса. Скажите, насколько бизнес удовлетворен сценариями тестирования и переходом на Postgres?
Бизнесу мы сценарии не показывали, и он даже не знал, что мы перешли на Postgres. Он как выполнял свою работу, так и продолжил работать. В базе ДО почти все операции были OLTP, короткие по времени выполнения, Postgres очень хорошо справляется с таким профилем нагрузки, там бизнес ничего и не почувствовал. В части ТОиРа у нас были несколько отчетов, которые после перехода зависали на несколько минут и у нас с ними была договоренность, что у нас есть время на их исправление.
Подскажите, в момент создания большой временной таблицы начало резко снижаться место на диске. Это по причине нехватки оперативной памяти или Postgres создавал файлы под ВТшку определенного размера?
Создаваемая временная таблицу по объему была более 100 Гб, temp_buffers установлен в 256 Мб. Происходит следующее: первые 256 Мб временной таблицы Postgres помещает в оперативную память, все остальные строки начинает скидывать на диск файлами по 1 Гб, пока не поместит таким образом все 400 млн записей на диск.
UPD: Немного оговорился. На диск помещает не 400 млн записей, а 400 млн записей минус то количество записей, которое было помещено в оперативную память.
Вы переходили на Postgres, был ли какой-то положительный результат кроме денег, производительность улучшилась, какие плюсы. Меня конечно удивило, что вы прееходили с сервера СУБД с 4 Тб ОЗУ на можно сказать "домашнюю машинку", при этом сравнивали производительность и что вы ожидали увидеть?
Представьте, как это можно продать (имеется ввиду с точки зрения маркетинга, что переход на Postgres экономит деньги). Основная цель была это уйти с MS SQL и сэкономить деньги. Эффект какой мы увидели? Ну я для себя увидел эффект, что я боялся, что вот он ночью остановится и перестанет работать, или какая-то другая проблема. Но этого ничего не происходило. Он работал так же, как MS SQL, непонятно, чего боялись переходить.
UPD: сложно ответить на такой вопрос, какой еще можно увидеть эффект. Не стоит ожидать, что ваша система после перехода на Postgres станет работать быстрее. Тут главное, чтобы она продолжила работать так же стабильно и с той же производительностью, поэтому после перевода следует уделить особое внимание ваших специалистов, отвечающих за производительность, на такую систему.
Вопрос не совсем по тесту. Если у вас был опыт, то насколько отличается производительность работы Postgres'а не windows и на linux при одинаковых показателях сайзинга серверов?
На Windows никогда не запускали Postgres, только на линуксе.
Хотел спросить про платформу Tantor. Срабатывал ли мониторинг при таких инцидентах?
Да, там можно настроить, что при утилизации процессора выше определенного порога придет алерт.
UPD: Триггер на количество активных сессий также можно настроить:
Платформа Tantor сделана с упором в сторону Postgres или именно заточена под 1С?
Она сделана с упором на Postgres.
UPD: Платформа Tantor разрабатывается уже 5 лет для администрирования и сопровождения серверов Postgres (работает с СУБД любого вендора Postgres). У нас в планах внедрить в нее несколько фич, которые нужны именно администраторам и экспертам 1С. Следите за анонсами.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT 2024
