Инструкция для подготовки к нагрузочному тестированию

В каких случаях это делаем?

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

Наша сборка показала результат хуже чем другой вендор постгреса
Наша сборка показала результат хуже чем было на 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>

CODE

В виде файла можно скачать тут - 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

CODE

Предварительно нужно создать директорию '/var/log/postgresql/' и дать пользователю postgres права на нее:

sudo mkdir /var/log/postgresql/
sudo chown -R postgres:postgres /var/log/postgresql/

BASH

Версия СУБД

Получаем информацию о версии СУБД и билде:

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();"

SQL

Данные об ОС

Сведения об версии ОС и настройках ИБ:

cat /etc/*release
cat /etc/astra/build_version
sudo astra-modeswitch get
astra-security-monitor status
systemctl status auditd

BASH

Сведения о конфигурации сервера:

cat /proc/meminfo| grep 'Mem'
lscpu

BASH

Сбор данных оборудования

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

CODE

Запуск atop с указанием интервала и времени записи:
Используйте команду atop с ключами -w (для указания файла записи), -R (для сброса существующего файла) и -d (для указания интервала в секундах):

 sudo atop -w /path/to/outputfile 10 3600
   
   Здесь:
   - /path/to/outputfile - путь к файлу, в который будут записаны данные.
   - 10 - интервал в секундах между записью данных.
   - 3600 - общее время сбора данных в секундах (в данном случае 1 час).

CODE

Просмотр собранных данных:
Для анализа записанных данных используйте команду atop с ключом -r (для чтения из файла):

atop -r /path/to/outputfile

CODE

Дополнительные параметры (опционально):
- Если нужно ограничить сбор данных определенными аспектами (например, только сеть или CPU), можно использовать соответствующие ключи, такие как -c, -d, -m, -n, -s.

Пример использования с ограничением по CPU и памяти:

sudo atop -w /path/to/outputfile -C -M 10 3600

CODE

- -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 и т.д.

CODE

Итоговый список данных для передачи в tech-команду

Сервер приложений 1С:

Технологический журнал 1С.
Данные об ОС
Версия платформы 1С Предприятие, версия режима совместимости тестируемой базы
Данные atop (в случае необходимости)

Сервер СУБД:

Логи СУБД
Данные об ОС
Версия СУБД
Файл postgresql.conf, postgresql.auto.conf
Данные atop (в случае необходимости)