SQLRU.net
Разработка приложений баз данных

Начало » Использование СУБД » Firebird, HQbird, InterBase » Как определить причину тормозов Firebird за 95 минут? (Пошаговая инструкция)
Как определить причину тормозов Firebird за 95 минут? [сообщение #1628] Wed, 15 February 2023 13:04
Alexey Kovyazin в настоящее время не в онлайне  Alexey Kovyazin
Сообщений: 21
Зарегистрирован: June 2022
Junior Member
Перед тем, как публиковать на форуме сообщение с просьбой помочь с производительностью Firebird, выполните следующие шаги, результаты которых поместите в свое сообщение (собранные данные в 80% случаев помогут определить причину медленной работы)

1) Определите производительность своего "железа" с помощью теста Insert/Update/Delete https://ib-aid.com/dbtest – займет 10 минут

Это займет 5-10 минут, и позволит определить однопоточную производительность ВМ или железного сервера с точки зрения Firebird.
Тест представляет собой скрипт, который вставляет, обновляет и удаляет 1 млн записей в тестовой базе данных, которую нужно расположить на том же разделе, где находится основная БД. Размер тестовой БД 3.6ГБ (не забудьте ее удалить после завершения скрипта).
В результате работы скрипта возвращается время операции и время коммита операции. Поделив 10000000 на продолжительность операции+продолжительность коммита, получим количество операций в секундах, и сможем определить, в какую часть графика/таблицы на странице теста попадаем: если в верхние 25%, то отлично, в районе середины — приемлемо, нижняя часть таблицы — плохо.
Также важно смотреть на длительность коммита — если она более 10 секунд, то имеем проблемы с записью на диск.
Другие тесты, такие как CrystalDiskMark, могут дополнить результаты теста.
Не могут заменить результаты теста рассказы о том, что «у нас супербрендовый сервер», «мы все проверяли много раз», «сервер очень дорогой».
Поместите в сообщение результаты теста и характеристики сервера (ВМ/железо, количество ядер ЦПУ, частота ЦПУ, размер RAM, тип дисков)

2) Сгенерируйте конфигурацию с помощью калькулятора конфигураций https://cc.ib-aid.com/democalc.html — 10 минут

2.1) Перед тем, как применять конфигурацию, проверьте, не прописан-ли кэш в в заголовке БД
с помощью команды
gstat -h путь_к_бд.fdb 
наличие в заголовке БД явно прописанного размера кэша: если в строке Page Buffers увидите значение, отличное от 0, то значения из конфигурационных файлов firebird.conf/databases.conf будут проигнорированы. Если видите ненулевое значение, уберите его с помощью команды
gfix -buffers 0 localhost:путь_к_бд.fdb -user SYSDBA -pass yourpass
и перезапустите Firebird

2.2) Калькулятор конфигураций генерирует гарантированно безопасную конфигурацию, исключающую частые ошибки вроде «хочу как можно больше памяти использовать».
Обратите внимание, что для 3-ки и 4-ки настройки кэша для самых нагруженных БД делаются в файле databases.conf
Переименуйте старый файл конфигураций, создайте новый и скопируйте туда конфигурацию, затем перезапустите Firebird для применения новой конфигурации.

Добавьте в сообщение файлы конфигурацию Firebird.

3) Соберите базовые данные о транзакциях, соединениях, блокировках — займет 5 минут

3.1) gstat - транзакции, соединения
В течении рабочего дня, в моменты, когда есть нагрузка (обычная или повышенная), два раза, с интервалом примерно 1 минута, выполнить команду
gstat -h путь_к_бд.fdb
и результаты сохранить.

Куда смотреть:
1) Разница между Oldest Interesting и Oldest Snapshot – несобранный мусор. Более 1 миллиона — точно есть проблема
2) Разница между Next и Oldest Active – длительная активная транзакция, блокирующая сборку мусора. Более 1 миллиона — точно есть проблема.
3) Вычисляем количество новых транзакций в секунду. Разница между измерениями — Next2 – Next1 / интервал в секундах. Если количество более 100 в секунду — точно есть проблема с частыми транзакциями.
4) Вычисляем количество соединений в секунду. Разница между измерениями Next Attachment ID2 – Next Attachment ID1 /интервал измерения в секундах. Если более 100, есть проблема.

3.2) Блокировки
В течении рабочего дня, в моменты, когда есть нагрузка (обычная или повышенная), однократно выполнить команду
fb_lock_pint -c -d путь_к_бд.fdb
Добавьте в сообщение результаты этих команд.

4) Соберите данные о выполняющихся запросах с помощью Trace API — 10 минут настройка и 1 час сбор данных

4.1) Соберите трейс
Согласно инструкции
https://ib-aid.com/en/articles/how-to-run-firebird-tracing-f or-visualization
запустите трейс и соберите лог запросов в течении 1 часа.

4.2) Сгенерируйте отчет на основе трейса
По вышеуказанной инструкции, сгенерируйте отчет по производительности из собранного лога трейса (в виде зипа) в https://cc.ib-aid.com (понадобится бесплатная регистрация).

В результате получите отчет в виде html, скачайте его, выложите на drive.google.com и предоставьте к нему доступ через ссылку.


5. Опубликуйте сообщение в форуме со всеми собранными данными, ожидайте ответа.
5.1 Если нужен гарантированный ответ, обращайтесь в платную техподдержку Firebird компании iBase - support@ibase.ru
5.2 Если используете приложения МИС Инфоклиника, РДУ Спектр, Аварда, сразу обращайтесь в платную техподдержку Firebird компании iBase - support@ibase.ru




[Обновления: Thu, 24 August 2023 12:41] от Модератора

Известить модератора

Предыдущая тема: FB 5.0 Производительность, оптимизация
Следующая тема: Архив "старого" скруля
Переход к форуму:
  


Текущее время: Fri Mar 29 04:17:39 GMT+3 2024

Общее время, затраченное на создание страницы: 0.00520 секунд