OLTP-EMUL - це офіційний тест Firebird, який емулює реалістичне OLTP-навантаження на Firebird 2.5 та новіших версіях. Використовуйте його для перевірки продуктивності та регресійного тестування за багатьох одночасних ISQL-сесій. Уважно прочитайте цей посібник перед запуском тесту.

Клонування репозиторію

Windows

git clone --config core.autocrlf=true https://github.com/FirebirdSQL/oltp-emul

Linux / POSIX

git clone --config core.autocrlf=false https://github.com/FirebirdSQL/oltp-emul

Швидкий старт на основі роботи Павла Зотова (Москва). Питання щодо самого тесту: [email protected]. Підтримка IBSurgeon: [email protected].

1. Передумови

На хості, де запускатимуться ISQL-сесії, встановіть клієнт Firebird і переконайтеся, що доступні такі виконувані файли:

isql (у деяких POSIX-пакетах: isql-fb)
fbsvcmgr

2. Вибір і копіювання файлу конфігурації

У папці src оберіть конфігурацію за замовчуванням, що відповідає вашій основній версії Firebird та ОС, потім скопіюйте її без суфікса .default.

Firebird	ОС	Файл конфігурації
2.5	Windows	`oltp25_config.win.default`
2.5	Linux	`oltp25_config.nix.default`
3.0	Windows	`oltp30_config.win.default`
3.0	Linux	`oltp30_config.nix.default`
4.0	Windows	`oltp40_config.win.default`
4.0	Linux	`oltp40_config.nix.default`

# Windows copy .\oltp30_config.win.default .\oltp30_config.win

Linux

cp ./oltp30_config.nix.default ./oltp30_config.nix

3. Важливі налаштування

Відредагуйте скопійовану конфігурацію. Особливу увагу зверніть на:

fbc - шлях до isql на машині, що запускає сесії
clu - необов'язкова нестандартна назва двійкового файлу ISQL (наприклад, isql-fb у POSIX-пакетах)
dbnm - повний шлях і назва файлу бази даних на сервері (лише ASCII; не псевдонім, якщо ви хочете, щоб скрипт створив базу)
host, port, usr, pwd - параметри підключення
tmpdir - каталог для журналів ISQL і тимчасових тестових файлів
init_docs - документи для створення перед вимірюваним навантаженням (спершу спробуйте 3000-5000)
warm_time / test_time - фази прогріву та вимірювання, у хвилинах
sleep_min / sleep_max - пауза між транзакціями (встановіть sleep_max на 0, щоб вимкнути паузи)
sleep_ddl - необов'язкова UDF для пауз (краща за шелловий sleep / cscript); двійкові файли в util/udf64/
wait_for_copy - пауза після ініціалізації, щоб ви могли зробити знімок БД перед прогрівом/вимірюванням (корисно для повторних запусків)

Після ініціалізації тест виконує прогрів протягом warm_time хвилин, потім вимірює протягом test_time хвилин.

4. Windows і поради щодо firebird.conf

Виключіть антивірусне / системне сканування з tmpdir і тимчасових папок Firebird (FIREBIRD_TMP / TMP / TEMP і TempDirectories у firebird.conf). Вирівнювання FIREBIRD_TMP із TempDirectories зменшує уповільнення за багатьох ISQL-сесій.

Збільште щонайменше:

DefaultDbCachePages
LockHashSlots
LockMemSize
FileSystemCacheThreshold - має бути явно встановлено і бути більшим за DefaultDbCachePages (тест відхиляє відсутнє/закоментоване значення, крім деяких POSIX-розкладок пакетів)

Орієнтуйтеся приблизно на 25% оперативної пам'яті для кешу сторінок. Не встановлюйте DefaultDbCachePages вище 2048 для Classic / SuperClassic. Розмір сторінки жорстко задано як 8192.

Приклад середнього навантаження (~100 сесій):

Параметр	SuperServer 3.0+	[Super]Classic 3.0+	[Super]Classic 2.5
`DefaultDbCachePages`	~0.25 × RAM / 8192	1024	1024
`LockHashSlots`	8191	16001	16001
`LockMemSize`	4194304	16777216	16777216

Готові конфігурації дивіться в Калькуляторі конфігурацій та еталонних конфігураціях.

5. Запуск тесту

Відкрийте шелл, перейдіть до src і виконайте:

1run_oltp_emul <FbMajor> <NumSessions> [nostop]

FbMajor - 25, 30 або 40 для Firebird 2.5 / 3.0 / 4.0
NumSessions - кількість ISQL-сесій для запуску
nostop - необов'язково; пропускає інтерактивні паузи (корисно з планувальника)

Якщо файл бази даних не існує, а dbnm є повним шляхом (не псевдонімом), скрипт може створити базу. Неповні або порожні попередні БД перестворюються за потреби.

6. Звіти та зупинка

Після часу прогріву + вимірювання сесії зупиняються автоматично. Перша ISQL-сесія записує підсумковий звіт у tmpdir. З make_html = 1 у Windows також створюється HTML-звіт (повільніше).

Іменування звітів залежить від file_name_with_test_params:

Закоментовано (за замовчуванням) - напр. oltp**.report.txt
regular - імена з часовими мітками, зручні для перегляду багатьох запусків у списку файлів
benchmark - імена, придатні для порівняння налаштувань/варіантів DDL

Звіти включають архітектуру та налаштування, загальну та поінтервальну продуктивність (CNT_OK_PER_MINUTE / AVG_TIMES_PER_MINUTE), додаткові деталі моніторингу, винятки, статистику БД, співвідношення версій/записів, перевірку змінених таблиць та різницю firebird.log до/після.

Ви також можете виконати запити:

select * from srv_mon_perf_dynamic;
select * from srv_mon_perf_total;

Дострокова зупинка

Використовуйте 1stoptest.tmp (.bat / .sh), створений у tmpdir під час кожного запуску. Для багатохостових запусків можна натомість увімкнути ExternalFileAccess у firebird.conf, встановити use_external_to_stop у конфігурації OLTP та записати символ у цей файл зупинки (очистіть його перед кожним новим запуском).

Відтворювані базові показники

Встановіть wait_for_copy = 1, дочекайтеся завершення ініціалізації, скопіюйте БД, потім відновлюйте цю копію перед кожним порівняльним запуском, щоб кожне вимірювання починалося з однієї точки.

Що моделює навантаження

Сценарій відповідає бізнес-документам у стилі автосервісу:

Замовлення клієнта (або внутрішні) на запчастини
Замовлення об'єднуються та надсилаються постачальнику
Рахунок від постачальника (повний або частковий)
Надходження на склад; замовлені клієнтом запчастини резервуються
Продажі та списання зі складу
Скасування можливі на кількох етапах
Часткові/повні оплати та скасування, що впливають на залишки
Перша сесія створює звіти про продуктивність, винятки, статистику та перевірку