10.6 Диагностика проблем
Скачать документ Наличие мусора
Свободное место на диске
Оперативная память
Нагрузка на процессор
Нагрузка на диск
Таблица блокировок
Активность индексов
Поломка БД
Запрос дополнительной информации для первичной диагностики проблемы при обращении на ЛТП1
Анализ проблем производительности и поломки БД:
Низкая производительность, симптомы:
долгое выполнение запросов;
долгое открытие окон в пользовательском интерфейсе;
жалобы на работу, вплоть до того, что вообще невозможно подключиться.
Поломка БД, симптомы:
зависание процессов СУБД;
аварийное завершение процессов СУБД РБД при выполнении запросов;
ошибки в логе firebird.log.
Проблема производительности требует анализа на всех уровнях:
прикладное ПО (толстый клиент, тонкий клиент, сервер приложений);
сеть (проблемы и ошибки сети, загрузка сети, антивирусы и файерволы);
гипервизор на сервере (конкуренция с другими ВМ, память, процессор);
ОС СУБД (постоянное потребление процессора на уровне 100%, очереди к диску, сеть, файловая система);
проблемы внутри БД (блокировки, мусор, отсутствие индексов, неоптимальные планы).
Все показатели требуется проверять в момент пиковой нагрузки на сервер или зависания и сравнивать с показателями системы, работающей в штатном режиме.
Примеры проведения диагностики проблем
Наличие мусора
Проверку наличия мусора можно осуществить утилитой gstat:
/opt/RedDatabase/bin/gstat -h /path/to/db.fdb
Пример вывода:
Database "/opt/db/red.fdb" Gstat execution time Wed Jun 30 15:53:27 2021 Database header page information: Flags 0 Generation 236121 System Change Number 24 Page size 16384 Server RedDatabase ODS version 12.0 Oldest transaction 234835 Oldest active 234836 Oldest snapshot 234836 Next transaction 234839 Sequence number 0 Next attachment ID 1604 Implementation HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc Shadow count 0 Page buffers 2048 Next header page 0 Database dialect 3 Creation date Aug 18, 2020 15:08:32 Attributes force write Variable header data: Database backup GUID: {C45D8AFE-4293-4EEA-B798-F0360284C9D6} Sweep interval: 0 Database GUID: {A5D296A8-833A-4377-F496-187F6ABB0D5E} *END* Gstat completion time Wed Jun 30 15:53:27 2021
Рекомендации:
Большая разница между OAT (Oldest active) и OIT (Oldest transaction) — повод для принудительной сборки мусора с помощью команды
gfix -sweep
.Большая разница между Oldest active и Next transaction — долгие транзакции, рекомендуется обратиться к разработчикам прикладного ПО для исключения длинных транзакций. Если такое исключение невозможно, то рекомендуется принудительное завершение таких транзакций (например, каждый день завершать транзакции старше 12-24 часов) и сборка мусора командой
gfix -sweep
.
Свободное место на диске
Проверка наличия свободного места на диске, в том числе в каталоге /tmp, производится командой:
df -h
Рекомендации:
- при отсутствии или недостаточном объеме свободного места необходимо его физическое увеличение либо удаление ненужных файлов.
Оперативная память
Проверка наличия свободной оперативной памяти и занятость swap осуществляется командой
free -m
Использование файла подкачки — плохой признак, который также может быть причиной низкой производительности. Интенсивность использования swap можно оценить с помощью утилиты atop
, см. параметры swout
и swin
, их активное изменение говорит о частом использовании swap.
Рекомендации:
проверьте параметры конфигурационного файла firebird.conf:
TempBlockSize
— минимальный размер блока сортировки и шаг его расширения (при необходимости). Позволяет несколько ускорить работу алгоритма сортировки за счёт выделения памяти большими блоками. Определение оптимальных для конкретной задачи настроек может быть произведено экспериментальным путем, принимая во внимание размеры файлов сортировки. При наличии больших сортировок рекомендуется увеличить значение параметра (максимально 2147483647 байт).TempCacheLimit
— для SuperServer и SuperClassic рекомендуется 64 Мб, для Classic = 8 Мб;TempDirectories
— указываются через точку с запятой, следуют в порядке очереди; пока не заполнится первая директория, вторая будет ожидать. Рекомендуется упорядочить каталоги по скорости доступа.Настройте использование swap:
Создайте файл /etc/sysctl.d/ram.conf:
nano /etc/sysctl.d/ram.conf
Со следующим содержимым:
vm.swappiness = 10
vm.dirty_ratio = 60
vm.dirty_background_ratio = 2
vm.min_free_kbytes = 1048576
После сохранения изменений выполните перезагрузку операционной системы.
Нагрузка на процессор
Проверка нагрузки на процессор:
top (atop, nmon)
Длительная 100% загрузка одного ядра — признак зависания.
Рекомендации:
принудительно завершите этот процесс (в случае с архитектурой Classic), предварительно сняв дамп для передачи на исследование разработчикам, после чего обратитесь в Техническую поддержку;
выполните команду
gfix -sweep
без активных подключений к БД;проверьте активность индексов и выполните пересчет селективности индексов (рекомендуется выполнять минимум 1 раз в неделю в период минимальной нагрузки);
низкая загрузка процессоров — ожидание блокировки, смотрите таблицу блокировок (см. п. «Таблица блокировок»).
проверьте трейс, возможно необходимо добавление индекса.
Нагрузка на диск
Проверка нагрузки на диск осуществляется командой:
iostat -xz (iostat -p sda -x -t 1)
где sda - имя исследуемого блочного устройства ввода/вывода.
Важное значение имеет длина очереди к диску aqu-sz
или avgqu-sz
(название параметра зависит от версии утилиты) — средний размер очереди запросов к диску.
Рекомендации:
Проверить опции монтирования для
SSD = noatime,discard
(не рекомендуется использовать опцию монтирования discard на программном рейде mdadm из NVME SSD).Необходимо понять, какие запросы выполняют наибольшее количество input/output-операций. В этом помогут таблицы мониторинга (
MON$
) и анализ трейса. Возможно, потребуется создание дополнительного индекса и пересчет селективности индексов (SET STATISTICS INDEX INDEX_NAME
).
Если на ЭВМ, на котором установлена СУБД РЕД База Данных, используется схема реализации компьютерной памяти NUMA (Non-Uniform Memory Access), то работу архитектуры можно проверить с помощью утилиты numastat.
В выводе утилиты промахов по памяти (numa_miss
— сколько раз промахнулись и вынуждены обращаться к памяти другого процессора) должно быть на порядок меньше попаданий (numa_hit
), в идеале параметр numa_miss
должен быть равен 0.
Рекомендации:
Если значение numa_miss
высокое, следует привязать процессы Ред Базы к одному из процессоров (numactl -C 0 /opt/RedDatabase/bin/rdbserver
), а к другому процессору можно привязать сервер приложений или веб-сервер, если он расположен на том же сервере.
Дополнительно необходимо протестировать производительность дисковой подсистемы с помощью утилиты fio:
fio fio.conf
Пример конфигурационного файла:
[ro]
blocksize=16k
directory=/mnt/ssd
rw=randread
direct=1
size=15g
ioengine=psync
iodepth=5
runtime=600
iodepth=5
ioengine=psync
[wo]
blocksize=16k
directory=/mnt/ssd
rw=randwrite
direct=1
size=15g
ioengine=psync
iodepth=5
runtime=600
iodepth=5
ioengine=psync
Основные параметры конфигурационного файла:
блоки
ro
иwo
(на чтение и на запись) — размер блока 16Кб, можно установить 8Кб, если размер страницы в БД равен 8;directory
— каталог, в котором будет проводиться тестирование;rw-randread
— рандомное чтение/запись;direct=1
— флагo_direct
;size=100
— размер файла 100Мб (из этого файла производится рандомное чтение/запись);runtime=60
— время тестирования;iodepth=5
— глубина очереди к диску, которую fio выдает в файл;ioengine=psync
— используемые функции чтения/записи, которыми пишет СУБД.
Параметры, на которые необходимо обратить внимание в выводе теста fio:
-
IOPS
— количество операций чтения и записи в секунду; lat
— задержка диска, необходимо ориентироваться на среднее (avg) значение.
Таблица блокировок
Примеры использования:
- печать всей таблицы:
/opt/RedDatabase/bin/rdb_lock_print -a -d /path/to/db > /path/to/lock_table.txt
- печать блокировок с очередями
/opt/RedDatabase/bin/rdb_lock_print -n -l -o -d /path/to/db > /path/to/lock_table.txt
- поиск зависшего процесса
/opt/RedDatabase/bin/rdb_lock_print -q 30 -d /path/to/db
В выводе rdb_lock_print -a -d
можно увидеть следующие параметры:
Length
— максимальный размер таблицы блокировок на момент снятия снапшота;Used
— текущий размер таблицы блокировок;Mutex wait
— время ожидания мьютексов в процентах;Hash slots
— ширина хэш-таблицы, которая используется для поиска блокировок. Число должно быть простым, чтобы хэш-алгоритм производил хорошее распределение;Hash length
(min/avg/max) — длина хэш-таблицы;Owners
— число соединений к серверу.
Рекомендации:
Если в пиковые нагрузки в параметре
Hash length
значенияavg
> 3 или max > 10, то необходимо увеличивать параметрLockHashSlots
(в firebird.conf), значение должно быть простым числом (максимум 65521).Высокий
Mutex wait
считается проблемой, нужно проверить селективность индексов и их активность.Встречается, что все процессы висят на ожидании одной блокировки. Это можно увидеть по выводу команды:
/opt/RedDatabase/bin/rdb_lock_print -c -n -l -o -d | grep "Pending"
Максимальное число и покажет проблемную блокировку. По типу и ключу можно попытаться понять, какая это блокировка, страница или другой ресурс. Это позволит предоставить рекомендации прикладному разработчику.
- Повисший процесс, который выдаст
rdb_lock_print -q 30
, рекомендуется завершить, предварительно сняв дамп.
Активность индексов
Определить неактивные индексы можно запросом:
select rdb$index_name from rdb$indices where (rdb$system_flag is null or rdb$system_flag = 0) and RDB$INDEX_INACTIVE > 0 order by rdb$foreign_key nulls first
Рекомендации:
- активируйте все индексы:
EXECUTE BLOCK AS DECLARE VARIABLE stmt VARCHAR(1000); BEGIN for select 'ALTER INDEX '||rdb$index_name ||' ACTIVE;' from rdb$indices where (rdb$system_flag is null or rdb$system_flag = 0) and RDB$INDEX_INACTIVE > 0 order by rdb$foreign_key nulls first into :stmt do EXECUTE STATEMENT :stmt; END
- активируйте нужные индексы вручную.
Поломка БД
Поломка БД — это изменения в файле, нарушающие целостность и приводящие к ошибкам.
Основные причины:
аппаратные (память, диск);
комплексные (батарейка рейд-контроллера);
программные (ошибки в коде СУБД).
При поломке БД ошибки могут встречаться как непосредственно при работе пользователей, так и в файле firebird.log.
Критические ошибки в файле firebird.log:
internal Firebird consistency check (cannot find tip page);
Error while trying to read from file;
Error while trying to write to file;
internal Firebird consistency check (can't continue after bugcheck);
internal Firebird consistency check (decompression overran buffer);
Pointer page (sequence NUM) lost;
Pointer page (sequence NUM) inconsistent;
Missing index root page;
Transaction inventory pages lost;
Transaction inventory pages confused;
internal Firebird consistency check (can't continue after bugcheck);
internal Firebird consistency check (cannot continue after replication failure).
При подозрении на поломку необходимо выполнить проверку файла базы данных через утилиту gfix. Для проверки требуется монопольный доступ к базе (при сбоях проверки добавьте ключ -ignore
):
/opt/RedDatabase/bin/gfix -v -full
Если ошибки не обнаружены, вывод команды будет пуст.
При обнаружении ошибок вывод команды будет иметь примерно следующий вид:
Summary of validation errors Number of record level errors : 93 Number of data page errors : 25 Number of index page errors : 29 Number of database page errors : 14
Рекомендации:
- выполните проверку:
/opt/RedDatabase/bin/gfix -v -full
- проверьте лог firebird.log на предмет наличия ошибок или отправьте его в службу техподдержки;
- проверьте оборудование (диск, ОЗУ);
- выполните ремонт БД по результатам анализа проверки.
Запрос дополнительной информации для первичной диагностики проблемы при обращении на ЛТП1
Все показатели требуется смотреть в момент пиковой нагрузки на сервер или зависания. Сбор данных необходимо производиться под учетной записью с правами администратора (sudo). Для диагностики необходимо установить следующие пакеты:
sudo dnf install numactl sysstat atop htop fio
1. Подробное описание проблемы:
проблема присутствует постоянно или в определенные моменты;
снижение производительности — общее или при определенных операциях;
проводились ли какие-либо работы на сервере (обновление, замена оборудования и пр.).
2. Характеристики оборудования (ОЗУ, ЦПУ, hdd или ssd).
3. Вывод команды:
df -h
4. Вывод команды:
sudo gstat -h /path/to/db.fdb
5. Вывод команды:
sudo rdb_lock_print -l -n -o -d /path/to/db.fdb
6. Вывод команды:
sudo rdb_lock_print -q 30 -d /path/to/db
7. Вывод утилиты top (atop, htop)
для определения нагрузки на ЦПУ.
8. Вывод команды:
free -m
9. Вывод утилиты numastat
(при наличии NUMA-архитектуры):
numastat
10. Вывод утилиты iostat
для оценки очереди к диску (выполнение займет ~1 минуту):
iostat -xzm -t 1 60 > /tmp/iostat.txt
При этом сформируется файл /tmp/iostat.txt, который необходимо предоставить.
11. Копия firebird.log, firebird.conf, databases.conf и replication.conf (при наличии) из каталога установки СУБД.
12. Копия /var/log/messages за интервал наблюдения проблемы и в течение месяца до нее.
13. Копия /etc/fstab.
14. Вывод команд:
sudo dmesg -T > /tmp/dmesg.txt
sudo journalctl -p err > /tmp/journalctl.txt
При этом создадутся файлы dmesg.txt и journalctl.txt в каталоге /tmp.
15. Проверить активность индексов запросом:
select rdb$index_name from rdb$indices where (rdb$system_flag is null or rdb$system_flag = 0) and RDB$INDEX_INACTIVE > 0 order by rdb$foreign_key nulls first
16. Протестировать производительность дисковой подсистемы, на которой расположена БД. Сделать это можно с помощью утилиты fio
:
sudo fio /tmp/fio.conf
Файл fio.conf необходимо создать с помощью любого текстового редактора, например nano
:
sudo nano /tmp/fio.conf
Пример конфигурационного файла:
[ro]
blocksize=16k
directory=/mnt/ssd
rw=randread
direct=1
size=15g
ioengine=psync
iodepth=5
runtime=600
iodepth=5
ioengine=psync
[wo]
blocksize=16k
directory=/mnt/ssd
rw=randwrite
direct=1
size=15g
ioengine=psync
iodepth=5
runtime=600
iodepth=5
ioengine=psync
Основные параметры конфигурационного файла:
блоки
ro
иwo
(на чтение и на запись) — размер блока 16Кб, можно установить 8Кб, если размер страницы в БД равен 8;directory
— каталог, в котором будет проводиться тестирование;rw-randread
— рандомное чтение/запись;direct=1
— флагo_direct
;size=100
— размер файла 100Мб (из этого файла производится рандомное чтение/запись);runtime=60
— время тестирования;iodepth=5
— глубина очереди к диску, которую fio выдает в файл;ioengine=psync
— используемые функции чтения/записи, которыми пишет СУБД.
Дата последнего изменения: 13.03.2024
Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.