Инструкция для подготовки к нагрузочному тестированию
В каких случаях это делаем?
Данную инструкцию нужно применять тогда, когда мы хотим разобраться в результатах нагрузочного теста нашей сборки:
- Наша сборка показала результат хуже чем другой вендор постгреса
- Наша сборка показала результат хуже чем было на mssql
- Клиент говорит, что получил плохой результат и просит помощи/совета в чем узкое место.
ВАЖНО!!! Не следует собирать эти данные при первичном нагрузочном тестировании, тем более для сравнения со сборкой постгерса другого вендора, иначе из-за сбора логов СУБД можно получить результат хуже.
То есть первичный прогон должен быть без сбора этих логов, а вот при повторном прогоне нужно собрать эти логи, чтобы разобраться с плохими результатами первичного прогона.
Сервер приложений 1С.
Собираем технологический журнал 1С:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="ПутьДляСбораЛогов/EXCP" history="24">
<event>
<eq property="name" value="EXCP"/>
<eq property="p:processName" value="ИмяБазы"/>
</event>
<event>
<eq property="name" value="EXCPCNTX"/>
<eq property="p:processName" value="ИмяБазы"/>
</event>
<event>
<eq property="name" value="QERR"/>
<eq property="p:processName" value="ИмяБазы"/>
</event>
<event>
<eq property="name" value="ATTN"/>
</event>
<event>
<eq property="name" value="PROC"/>
</event>
<event>
<eq property="name" value="ADMIN"/>
</event>
<property name="all"/>
</log>
<log location="ПутьДляСбораЛогов/LOCKS" history="24">
<event>
<eq property="name" value="TLOCK"/>
<eq property="p:processName" value="ИмяБазы"/>
<ge property="Durationus" value="100000"/>
</event>
<event>
<eq property="name" value="TTIMEOUT"/>
<eq property="p:processName" value="ИмяБазы"/>
</event>
<event>
<eq property="name" value="TDEADLOCK"/>
<eq property="p:processName" value="ИмяБазы"/>
</event>
<property name="all"/>
</log>
<log location="ПутьДляСбораЛогов/Sql" history="24">
<event>
<eq property="Name" value="DBPOSTGRS"/>
<eq property="p:processName" value="ИмяБазы"/>
<ge property="Durationus" value="1000000"/>
</event>
<property name="all"/>
</log>
<log location="ПутьДляСбораЛогов/sdbl" history="24">
<event>
<eq property="Name" value="SDBL"/>
<eq property="p:processName" value="ИмяБазы"/>
<ge property="Durationus" value="1000000"/>
</event>
<property name="all"/>
</log>
<log location="ПутьДляСбораЛогов/call" history="24">
<event>
<eq property="Name" value="CALL"/>
<eq property="p:processName" value="ИмяБазы"/>
<ge property="Durationus" value="1000000"/>
</event>
<property name="all"/>
</log>
<log location="ПутьДляСбораЛогов\mini" history="24">
<event>
<ne property="name" value=""/>
</event>
</log>
</config>
В виде файла можно скачать тут - logcfg.xml
В самом файле необходимо заменить 2 параметра:
- ПутьДляСбораЛогов – сменить на каталог, куда будут собираться логи ТЖ. ВАЖНО: у пользователя, под которым запущена служба сервера 1С, должен быть права на чтение и запись к указанному каталогу.
- ИмяБазы – заменить на имя базы как оно задано в кластере серверов 1С, которую планируется тестировать.
Сервер СУБД
Настройка Tantor
Если выполняется сравнение с СУБД от другого вендора, то настройки нужно взять аналогичные, чтобы сравнение было корректным!
Если просто тестируется наша сборка, то настроить ее нужно согласно инструкции.
Логи СУБД
Добавляем в файл postgresql.auto.conf следующие настройки для сбора подробных логов СУБД:
log_directory = '/var/log/postgresql/'
log_destination = 'csvlog'
log_lock_waits = on
log_statement = 'all'
log_min_duration_statement = -1
log_min_duration_sample = 0
log_statement_sample_rate = 0.2
log_transaction_sample_rate = 0.2
log_min_messages = 'WARNING'
shared_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = '1s'
auto_explain.log_analyze = true
auto_explain.log_verbose = true
auto_explain.log_buffers = true
auto_explain.log_format = text
Предварительно нужно создать директорию '/var/log/postgresql/' и дать пользователю postgres права на нее:
sudo mkdir /var/log/postgresql/
sudo chown -R postgres:postgres /var/log/postgresql/
Версия СУБД
Получаем информацию о версии СУБД и билде:
sudo -u postgres /opt/tantor/db/15/bin/psql -c "select tantor_version();"
sudo -u postgres /opt/tantor/db/15/bin/psql -c "select tantor_build();"
Данные об ОС
Сведения об версии ОС и настройках ИБ:
cat /etc/*release
cat /etc/astra/build_version
sudo astra-modeswitch get
astra-security-monitor status
systemctl status auditd
Сведения о конфигурации сервера:
cat /proc/meminfo| grep 'Mem'
lscpu
Сбор данных оборудования
При проведении нагрузочного теста, если у заказчика не собираются и не визуализируются данные оборудования графаной или заббиксом, то мы можем попросить их собрать показатели оборудования и сами визуализировать их. Это поможет нам убедиться, что в рамках нагрузочного теста узким местом не является, допустим, CPU.
Установка atop и сбор данных
Установка atop (можно устанавливать 2.3 - 2.7):
# На Ubuntu/Debian:
sudo apt update
sudo apt install atop
# На Red Hat/CentOS:
sudo yum install atop
# Если он уже установлен, то проверить версию можно:
atop -V
Запуск atop с указанием интервала и времени записи:
Используйте команду atop с ключами -w (для указания файла записи), -R (для сброса существующего файла) и -d (для указания интервала в секундах):
sudo atop -w /path/to/outputfile 10 3600
Здесь:
- /path/to/outputfile - путь к файлу, в который будут записаны данные.
- 10 - интервал в секундах между записью данных.
- 3600 - общее время сбора данных в секундах (в данном случае 1 час).
Просмотр собранных данных:
Для анализа записанных данных используйте команду atop с ключом -r (для чтения из файла):
atop -r /path/to/outputfile
Дополнительные параметры (опционально):
- Если нужно ограничить сбор данных определенными аспектами (например, только сеть или CPU), можно использовать соответствующие ключи, такие как -c, -d, -m, -n, -s.
Пример использования с ограничением по CPU и памяти:
sudo atop -w /path/to/outputfile -C -M 10 3600
- -C - включает мониторинг процессов (CPU).
- -M - включает мониторинг использования памяти.
Визуализация бинарного файла atop c помощью grafana
1. перенести посредством scp необходимый для визуализации бинарный atop лог в свою домашнюю директорию на сервер 10.177.143.33
для аутентификации необходимо использовать freeipa креды
2. зайти по ssh на сервер 10.177.143.33 b создать в домашней директории файл log_to_graph со следующим содержимым
#!/bin/bash
cp $1 /opt/atop-graph/src/
cd /opt/atop-graph/
./convert $2
./push $2
rm ./src/*
rm ./dst/*
3. дать права на запуск файла log_to_graph
chmod 744 log_to_graph
4. запустить команду
sudo ./log_to_graph <atop_binary_log> <atop_version>
где
<atop_binary_log> имя лог файла загруженного в пункте 1
<atop_versions> версия atop которым был сгененирован лог фал. доступные версии - 2.7 2.4 2.2 (если нужны будут другие версии сообщите)
5. перейти по ссылке https://10.177.143.33:3000/
username: admin
password: admin
в правом верхнем углу, открывшейся страници, нажать на пиктограмму в виде квадрата и выбрать нужный дашборд CPU, Disk, Memory и т.д.
Итоговый список данных для передачи в tech-команду
Сервер приложений 1С:
- Технологический журнал 1С.
- Данные об ОС
- Версия платформы 1С Предприятие, версия режима совместимости тестируемой базы
- Данные atop (в случае необходимости)
Сервер СУБД:
- Логи СУБД
- Данные об ОС
- Версия СУБД
- Файл postgresql.conf, postgresql.auto.conf
- Данные atop (в случае необходимости)