Диагностика проблем

Наличие мусора
Свободное место на диске
Оперативная память
Нагрузка на процессор
Нагрузка на диск
Таблица блокировок
Активность индексов
Поломка БД
Запрос дополнительной информации для первичной диагностики проблемы при обращении на ЛТП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 — используемые функции чтения/записи, которыми пишет СУБД.

Дата последнего изменения: 22.05.2024

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.