13. Настройка производительности РЕД Базы Данных

Производительность конкретной системы зависит от аппаратного и программного обеспечения. Причины плохой производительности могут быть с обеих сторон - слабая дисковая подсистема, мало памяти, плохое управление транзакциями в приложении, плохие запросы и т.д.

В первом разделе будет описано, как подобрать эффективное аппаратное обеспечение для РЕД Базы Данных. Далее даются рекомендации по диагностике производительности системы. Заключительная часть главы посвящена проблемам производительности и пути их устранения.

13.1. Выбор аппаратного обеспечения

Прежде чем подобрать эффективное аппаратное обеспечение для БД, следует понять, как РЕД База Данных использует его компоненты: CPU, RAM, HDD/SSD.

Основные операции взаимодействия БД с аппаратным обеспечением

При старте СУБД процесс сервера занимает в RAM минимальный объем (несколько мегабайт) и не производит никаких интенсивных операций с CPU или RAM.

При соединении с базой данных сервер запрашивает у ОС оперативную память в размере страничного кэша базы. Фактически эта память сразу не используется, но выделение её осуществляется сразу при первом подключении к базе. Потом сервер начинает читать метаданные базы. CPU практически не задействован на этом этапе.

Когда клиент начинает выполнять SQL-запросы (включая хранимые процедуры), сервер выполняет соответствующие операции, обращающиеся к аппаратной части. Среди этих операций можно выделить следующие базовые операции, потребляющие определенный набор системных ресурсов. Они представлены в таблице ниже с указанием интенсивности потребления (1 означает небольшую интенсивность, 10 – максимальную):

Таблица 13.1 Потребление системных ресурсов

Чтение страниц БД с диска

Запись страниц БД на диск

Чтение страниц БД из кэша

Запись страниц БД в кэш

Чтение страниц данных из GTT

Запись страниц данных в GTT

Сортировка записей

Обработка SQL запроса

CPU

1

1

1

1

1

1

5

10

RAM

5

5

5

5

5

5

5

2

Disc IO

10

10

1

1

1

1

1

1

Видно, что наиболее тяжелыми операциями являются те, которые включают работу с диском, так как дисковая подсистема является наиболее медленным компонентом аппаратной части.

Процессор

При выборе процессора следует принять во внимание следующие вещи:
Преобладание сложных запросов

СУБД всегда исполняет один запрос на одном ядре, поэтому сложные или плохо оптимизированные запросы могут занимать до 100% одного ядра, заставляя остальные запросы переместиться на менее загруженные ядра. Поэтому чем больше ядер, тем меньше шанс, что все процессорные мощности будут заняты.

Если преобладают простые SQL-запросы и все запросы хорошо отлажены, то CPU не будет являться узким местом производительности, и можно выбрать модель с меньшим количеством ядер.

Если преобладают медленные запросы, возвращающие большое количество данных, то необходим процессор с большим количеством ядер.

Число активных соединений

Для грубой оценки необходимого количества ядер в CPU можно пользоваться правилом: от 10 до 30 соединений на 1 ядро. 10 соединений/ядро – приложение с преобладанием сложных и медленных запросов, 30 соединений/ядро – приложение с преобладанием простых, хорошо отлаженных запросов.

Память

При выборе RAM следует уделить внимание двум моментам:
Модули памяти должны быть с коррекцией ошибок (ECC RAM)

ECC RAM значительно снижает количество ошибок при работе с памятью и настоятельно рекомендуется для использования в промышленных системах.

Правильно рассчитать объем RAM

РЕД База Данных 5.0 архитектуры Classic запускает отдельный процесс для обслуживания каждого соединения, SuperClassic запускает отдельный поток для каждого соединения, но практически с той же структурой потребления памяти - каждое соединение имеет свой независимый страничный кэш. SuperServer запускает один процесс с общим страничным кэшем для всех соединений с каждой базой данных. При подключении к нескольким базам для каждой из них будет выделен свой объем страничного кэша, заданный настройками в файлах конфигурации или в самой базе данных.

На потребление памяти влияют следующие параметры:

  1. Количество соединений.

  2. Размер объектов метаданных (пропорционален количеству таблиц, триггеров, хранимых процедур и др.).

  3. Размер страничного кэша (определяется параметрами в заголовке БД или в firebird.conf или в свойствах конкретного соединения).

  4. Размер кэша для сортировок (определяется параметром в firebird.conf).

  5. Размер таблицы блокировок (важнее для Classic/SuperClassic).

  6. Объекты СУБД в памяти (запросы, блобы, управляющие структуры и т.д.).

Ниже представлены формулы приблизительного расчета необходимого объема памяти для РЕД Базы Данных:

  • для Classic:

    Количество соединений * (Кол-во страниц в кэше * Размер страницы + Размер кэша для сортировок)

  • для SuperClassic:

    Количество соединений * (Кол-во страниц в кэше * Размер страницы) + Размер кэша для сортировок

  • для SuperServer:

    (Кол-во страниц в кэше * Размер страницы) + Размер кэша для сортировок

Реальное потребление памяти может отличаться, так как в этом расчете не учитывается объем памяти под метаданные, под битовые маски индексов, и т.д., что может увеличить расход памяти, но одновременно предполагается, что память под сортировки будет использована полностью во всех соединениях, чего обычно не происходит.

Количество RAM сверх рассчитанного минимального будет эффективно использоваться операционной системой для кэширования файла БД.

Когда база данных уже находится в эксплуатации, можно просто посмотреть средний размер памяти, используемый процессом СУБД.

Дисковая подсистема

Чтобы уменьшить конкуренцию за дисковый ввод-вывод между операциями с файлом БД, сортировками и резервными копиями, а также уменьшить шанс одновременной потери и базы данных и резервных копий, рекомендуется иметь 3 разных диска (или raid-массива):

Для базы данных

Для работы с базой данных лучше всего использовать SSD-диски, так как они обеспечивают высокую скорость произвольного доступа. Обязательно следует использовать диски промышленного класса с увеличенным числом циклов перезаписи, иначе велик риск потери данных из-за поломки SSD. SSD c наличием Enhanced Power Loss Data Protection существенно повысит производительность.

При этом рекомендуется оставлять до 30% свободного места на диске (из-за повышенного износа) и планировать замену диска примерно раз в 3 года.

Наилучшим выбором является использование SSD эксклюзивно для работы с базой данных, так как любые операции ввода-вывода сокращают срок службы дисков.

Если SSD диск оказывается слишком дорогим решением или размер БД слишком велик, то можно подобрать альтернативные варианты в порядке уменьшения приоритета:

  1. HDD с интерфейсом SAS.

  2. Диски SATA с интерфейсом nSAS.

  3. Обычные диски SATA.

Для временных файлов

Так как временные файлы на диске возникают только при отсутствии достаточного количества RAM, то лучше всего вообще избегать их появления на диске.

Но всё-таки РЕД База Данных требует указания папки, где будут храниться временные файлы (параметры TempTableDirectory и TempDirectories). Обычно этот параметр оставляют со значением по умолчанию, т.е. используется стандартный временный каталог ОС. Чтобы предупредить исчерпание свободного места на системном диске, в firebird.conf указывают второй диск в качестве дополнительного резервного места.

Следует учитывать, что при создании индекса размер данных сортировки может быть очень большим и СУБД будет выгружать её данные на диск. Это может привести к созданию больших файлов (десятки гигабайт для больших таблиц) в каталогах, заданных в TempDirectories.

Аналогичная ситуация с большими временными файлами в десятки гигабайт может произойти при использовании очень больших временных таблиц (GTT) в каталоге TempTableDirectory.

Для резервных копий

При резервном копировании происходит чтение файла базы данных (всего или части), и запись резервной копии (полной или частичной). Операции записи при создании резервной копии идут последовательно, это означает, что обычные недорогие жесткие диски с интерфейсом SATA (HDD SATA) хорошо подойдут для хранения резервных копий, так как скорость последовательной записи у них довольно велика.

На диске для резервных копий всегда должно оставаться свободное место в размере последнего бэкапа + 10%. В этом случае есть возможность создать свежий бэкап, убедиться в корректном завершении процесса копирования и только потом удалить предыдущий бэкап.

Под «отдельными дисками» понимается, что физически потоки данных должны идти через разные каналы ввода-вывода. Если создать 3 логических диска на одном физическом диске, никакого улучшения производительности не произойдет. Однако, если 3 логических диска будут организованы на устройстве хранения данных (СХД), оснащенном многоканальными контроллерами, то производительность может возрасти, так как устройство может распределять потоки данных между контроллерами.

При наличии в контроллере дисковой подсистемы возможности кэширования записи (режим write back) желательно её включить, но только при условии гарантированного сохранения данных кэша в случае потери питания (использование BBU, кэш на базе flash и т.д.). Если сохранение данных кэша не гарантировано, его следует отключить (режим write through).

RAID

Для базы данных и бэкапов следует увеличивать надежность дисковой подсистемы путем объединения дисков в RAID.

Для SSD дисков следует обязательно использовать RAID1 - это 2 "зеркальных" диска, на которые одновременно пишутся изменения, что значительно уменьшает шанс полной потери данных.

Для HDD дисков, используемых для бэкапов, достаточно использовать RAID1, который обеспечит надежное хранение бэкапов и приемлемую скорость записи и чтения.

HDD диски, используемые для БД, необходимо объединять в RAID10 (минимум 4 диска), который обеспечит оптимальное сочетание стоимости, надежности и производительности.

13.2. Диагностика системы

Чтобы собрать информацию о производительности системы, следует выполнить следующие шаги:

  • Измерить параметр IOPS произвольной записи, используя IOMeter на Windows и fio на Linux

  • Измерить параметр IOPS произвольного чтения.

  • Измерить скорость последовательной записи:

  • Дисковая подсистема довольно часто становится узким местом в работе. Поэтому очень важно уметь диагностировать проблемы с дисками. Одним из основных инструментов для наблюдения за производительностью дисковой подсистемы являются счетчики производительности:

    • % Disk Write Time (процент загруженности диска операциями записи)

    • % Disk Read Time (процент загруженности диска операциями чтения)

    • Avg. Disk sec/Write (среднее время в секундах, требуемое для выполнения диском одной операции записи)

    • Avg. Disk sec/Read (среднее время в секундах, требуемое для выполнения диском одной операции чтения)

    • Disk Read Bytes/sec (средняя скорость чтения)

    • Disk Reads/sec (количество обработанных за секунду запросов на чтение)

    • Disk Write Bytes/sec (средняя скорость записи)

    • Disk Writes/sec (количество обработанных за секунду запросов на запись)

  • Включить аудит событий, изменив параметры в конфигурационном файле fbtrace.conf:

    • enabled = true,

    • time_threshold = 1000,

    • log_statement_finish = true.

    и проверить полученные с помощью него логи.

  • Собирать данные менеджера блокировок с регулярными интервалами:

    rdb_lock_print -a -d </path/to/db> > db_lock_print.txt

  • Мониторить характеристики процессора, используя CPU-Z. Диспетчеру задач Windows доверять не стоит.

  • С помощью утилиты gstat проверить нет ли старых активных транзакций, которые препятствуют сборке мусора:

    gstat -h </path/to/db>

  • Проверить таблицы мониторинга или сохранить результаты этих таблиц во внешние файлы:

    MON$DATABASE;MON$ATTACHMENTS;MON$TRANSACTIONS;MON$STATEMENTS; MON$IO_STATS; MON$RECORD_STATS;
MON$MEMORY_USAGE;

13.3. Узкие места и их устранение

Узкое место записи данных на диск с БД

Признаки

  • Высокий показатель % Disk Write Time (>75%)

  • Среднее значение счетчика Disk Writes/sec близко или превышает параметр IOPS произвольной записи.

  • Запросы Insert/update/delete, которые обрабатывают небольшое количество строк и обычно выполняются за время менее 100 мсек, выполняются за одну и более секунды и появляются в журнале аудита.

Рекомендации

  • Убедиться, что количество кэшируемых страниц достаточно большое. Для архитектуры суперсервер значение параметра DefaultDbCachePages рекомендуется рассчитать по формуле:

    \[\texttt{DefaultDbCachePages} = \frac{\texttt{MemorySize}}{4*\texttt{PageSize}},\]

    где MemorySize - общий объём памяти; PageSize - объём страницы.

    Для архитектуры классик значение параметра рекомендуется рассчитать по формуле:

    \[\texttt{DefaultDbCachePages} = \frac{\texttt{MemorySize}}{4*\texttt{ConnNum}*\texttt{PageSize}},\]

    где MemorySize - общий объём памяти; PageSize - объём страницы; ConnNum - предполагаемое максимальное количество соединений.

    Установить другое значение кэшируемых страниц можно с помощью утилиты gfix:

    GFIX –buffers 400 <db_name>

  • Улучшить показатели параметра IOPS произвольной записи можно применением следующих мер:

    1. Избегайте применять RAID5. Лучше использовать RAID1 или RAID10.

    2. Используйте SSD для хранения БД.

  • Разобраться какие запросы выполняют столько IO-операций (с помощью таблиц мониторинга и аудита).

  • Как временный, запасной вариант, можно установить режим асинхронной записи данных - в этом случае изменения и новые данные хранятся в памяти и периодически сбрасываются на диск подсистемой ввода/вывода операционной системы. Общепринятое название такой конфигурации - forced writes off. По умолчанию БД устанавливается с включенным режимом принудительной записи - forced writes - синхронная запись. В этом режиме изменения и новые данные сразу записываются на диск.

    Затем в конфигурационном файле firebird.conf отключить параметры MaxUnflushedWrites и MaxUnflushedWriteTime.

Узкое место чтения данных с диска БД

Признаки

  • Высокий показатель % Disk Read Time (> 75%)

  • Среднее значение счетчика Disk Reads/sec близко или превышает параметр IOPS произвольного чтения, измеряемый в течение нескольких минут.

  • Запросы на чтение и обновление выполняются чрезвычайно долго и появляются в журнале аудита.

Рекомендации

  • Убедитесь, что ОС можно использовать всю оперативную память для кэширования. Для этого можно проверить установленные границы размера файла системного кэша в результате использования утилиты SetSystemFileCacheSize. Она должна показывать:

    Current cache working set size
min: none set
max: none set

    Если утилита показывает что-то иное, установите FileSystemCacheSize=0 в конфигурационном файле firebird.conf. При внесении изменений потребуется перезагрузка.

  • Убедитесь, что достаточно оперативной памяти доступно для кэширования.

  • Определите, какие запросы выполняют столько IO-операций (с помощью таблиц мониторинга и аудита).

Проблемы с троттлингом процессора (только для Windows)

Признаки

  • Измерения с помощью CPU-Z показали, что тактовая частота процессора ниже заявленной.

Когда система перегружена, все остальные операции начинают занимать больше времени, и система все больше склоняется к образованию "узких мест" в других местах (подсистемах, уровнях) из-за взаимных блокировок.

Рекомендации

  • В разделе Электропитание панели управления Windows выберите план «Высокая производительность». Далее «Настройка плана электропитания» \(\to\) «Изменить дополнительные параметры питания», далее выберите пункт «Управление питанием процессора», где «Минимальное состояние процессора» должно быть 100%. С помощью CPU-Z убедитесь, что проблема решена.

  • Если предыдущий шаг не помог, значит BIOS или прошивка снизили частоту процессора. Прочтите руководство Server's BIOS и выберите настройки, которые соответствуют параметру «Performance Optimized». Возможно потребуется отключить Intel SpeedStep в BIOS.

  • Не исключено, что тактовая частота процессора снижена из-за проблем с охлаждением. Измерьте температуру процессора и чипсета (например, с помощью утилиты Open Hardware Monitor).

Проблемы с сортировкой

При выполнении сортировок РЕД База Данных выполняет ее в памяти (в адресном пространстве процесса сервера), пока размер используемой памяти для всех выполняемых одновременно сортировок не достигнет предела, установленного параметром TempCacheLimit в firebird.conf. При превышении этого лимита создается временный файл (с соответствующим флагом операционной системы) в папке временных файлов, и в нем выполняется сортировка. В случае, если в системе есть свободная память (RAM), то файл сортировки будет кэширован на уровне ОС и сортировка будет производиться в памяти. Измерения показывают, что запросы с большими сортировками выполняются в 2 раза быстрее в ОЗУ, а не на диске. Поэтому рекомендуется установить параметр TempCacheLimit = 2147483647 в firebird.conf для 64-битных систем и TempCacheLimit = 1000000000 для 32-битных систем.

Информацию о том, сколько памяти занимают временные файлы, можно узнать из таблицы мониторинга MON$STATEMENTS. Также, при включенном логировании операций типа finish, в трейсе отразится объём кэша, выделенного для сортировки.

Имя временного файла формируется следующим образом:

<тип временного объекта>_att<id подключения>_stmt<id запроса>_<случайная строка>

Например: /tmp/rdb_sort_att342316_stmt106_M2OSLu.

Проблемы со сборкой мусора

Признаки

  • Большая разница между «Oldest transaction» и «Next transaction» при выводе статистики: gstat -h

  • Большая разница между Oldest active (или Oldest Snapshot) и Next transaction.

  • Запросы выполняются неожиданно долго.

Удержание Oldest active и Oldest Snapshot возможны по следующим причинам:

  • некоторое приложение работает и держит открытой хотя бы одну транзакцию, например, пользователь не закрыл приложение и какая-либо его форма очень долго открыта;

  • приложения работают длительное время, и «теряют» идентификаторы транзакций в коде;

  • используемая библиотека компонент или драйвер работает с «транзакцией по умолчанию», которая может длиться очень долго.

Рекомендации

  • Посмотреть таблицы мониторинга, чтобы узнать, какая транзакция активна больше всего времени, принять необходимые меры по ее закрытию и провести принудительную сборку мусора gfix -sweep n <db_name>.

  • Сборку мусора (sweep) выполнять по крайней мере раз в неделю (gfix -sweep n <db_name>). Можно запланировать запуск команды с помощью планировщика Windows.

  • Выполнять периодическое резервное копирование-восстановление БД по крайней мере раз в год или после крупного изменения в данных.

Длительное ожидание блокировок

Признаки

  • Запросы выполняются неожиданно долго.

  • В менеджере блокировок высокий процент (более 20%) попыток (Mutex wait), которые были заблокированы, когда владелец старался обратиться к таблице блокировок.

Рекомендации

  • Обычно причина высокого показателя Mutex wait заключается в недостаточно оптимальной структуре хэш-таблицы. Не рекомендуется, чтобы среднее значение «Hash lengths» было больше 3 или максимальное больше 10. Рекомендуемое число слотов (LockHashSlots): 65521. В качестве значения размера хэш-таблицы лучше указывать простое число.

Неэффективное использование таблиц мониторинга

Признаки

  • Запросы выполняются неожиданно долго.

  • Дамп лок-таблицы показывает цепочки ожидания для блокировки 19-го типа (series 19).

Сбор информации для таблиц мониторинга требует глобальной блокировки базы данных и является достаточно длительной операцией. Не рекомендуется обращаться к таблицам мониторинга на рабочем сервере чаще, чем раз в несколько минут.

Рекомендации

  • Автоматические процессы, процедуры или триггеры не должны обращаться таблицам мониторинга так часто. Эта проблема должна быть перенаправлена на разработчиков приложений для исправления.

Проблемы с блокировками транзакций

Признаки

  • DML-запросы выполняются неожиданно долго.

  • Дамп лок-таблицы показывает цепочки ожидания для блокировки 4го типа.

Эта проблема вызвана одновременным обновлением одинаковых наборов записей в режиме WAIT разрешения блокировок или неправильным выбором параметров транзакций (например, использование параметра no_rec_version).

Рекомендации

  • Этот вопрос должен быть переадресован разработчикам приложения на исправление.

Узкое место в подсистеме памяти

Признаки

  • Запросы, обрабатывающие большие объемы данных, выполняются неожиданно долго.

  • Большое потребление ресурсов центрального процессора, где сервер является основным их потребителем.

  • Мониторинг процессора показывает, что процент времени нахождения в режиме ядра высок (20% и более).

Причина таких признаков заключается в том, что во время чтения страницы БД должны быть скопированы с кэша файловой системы на буферный кэш РЕД Базы Данных. Существуют ограничения в пропускной способности памяти, что особенно заметно в крупных многопроцессорных конфигурациях, тогда каналы обмена с памятью становятся узким местом.

Рекомендации

  • Исключить проблемы уровня ОС.

  • Уменьшить размер страниц (с 16К до 8К) и увеличить размер буферного кэша.

  • Оптимизировать проблемные запросы (проверить по таблицам мониторинга и с помощью аудита).

  • Убедиться в правильной настройке кэша сервера (возможно он слишком мал), проверить параметры конфигурационного файла:

    • TempBlockSize - можно увеличить до 2 или 3Мб, но не до 16Мб;

    • TempCacheLimit - сделать значение больше суммарного размера временных файлов в каталогах TempDirectories;

    • TempDirectories - каталоги для хранения данных сортировок указываются через точку с запятой, следуют в порядке очереди, пока не заполнится первая директория, вторая не будет использоваться. Указать первой директорией RAM диск, потом SSD или HDD;

    • TempTableDirectory задать каталог для хранения данных глобальных временных таблиц и временных блобов.

  • Достигнуты границы масштабируемости ядра Windows. Переходите на ОС, которая позволяет полное профилирование системы (Linux, Unix).

Проблемы с блокировкой страниц

Признаки

  • Запросы выполняются неожиданно долго.

  • Дамп лок-таблицы показывает цепочки ожидания для блокировки 3-го типа (series 3).

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

Если проблема не в этом, то причины могут быть следующие:

  • много одновременных соединений выполняют крупные изменения в разных записях одинаковых таблиц (может быть выведено из журнала аудита).

  • чрезвычайно высокий рост числа транзакций, генерируемых приложениями (может быть выведено из быстрого роста счетчиков транзакций).

Если и эти причины исключены, то можно получить номера страниц, используя ключ Key - идентификатор заблокированно ресурса, и выяснить, какие именно страницы вызывают проблемы и какие таблицы, индексы или другие структуры являются узким местом.

Рекомендации

  • Разрешить проблемы, описанные выше.

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

  • Можно обратиться в техническую поддержку РЕД Базы Данных, если все указанные причины исключены, а проблема осталась.

Долго выполняемые запросы

Признаки

  • Пользователи отмечают плохую производительность, зависание клиента или зависание всей системы, если запрос выполняется сервером, когда удерживается некоторая блокировка.

  • В случае зависания проблемный запрос можно увидеть в таблице MON$STATEMENTS со строкой MON$STATE <> 0.

  • Проблемы с производительностью при определенных запросах.

  • В таблице мониторинга MON$RECORD_STATS количество неиндексных чтений гораздо больше, чем индексных (MON$RECORD_SEQ_READS > MON$RECORD_IDX_READS).

Рекомендации

  • Если определили проблемный запрос в MON$STATEMENTS, завершите его удалением соответствующей строки.

  • Запустите запрос отдельно с включенным отображением плана и статистики:

    set stats on;
set plan on;
<запрос>
.........................
Current memory = 2574604
Delta memory = -5660
Max memory = 2653012
Elapsed time= 0.03 sec
Cpu = 0.000 sec
Buffers = 512
Reads = 1
Writes 0
Fetches = 92
    Current memory

    Объём памяти, используемой сервером (в байтах).

    Delta memory

    Показывает, на сколько байт изменилось использование памяти (значение Current memory) за время выполнения запроса.

    Max memory

    Максимальное использование памяти, которое было зафиксировано с момента запуска сервера.

    Elapsed time

    Время выполнения запроса.

    Cpu

    Время использования CPU.

    Buffers

    Количество кэшированных страниц.

    Reads

    Показатель дискового I/O, сколько страниц считано с диска в кэш сервера (тех, которые еще не находились в кэше). Первое выполнение запроса показывает точные данные. При повторном вызове, если Reads = 0, то все нужные страницы уже в кэше, а если значение больше 0, то в кэше не хватает места, чтобы поместить необходимые страницы, то есть на самом деле считано страниц Buffers + Reads.

    Writes

    Страницы, записанные из кэша на диск (или в кэш операционной системы). Insert, update, delete - влияют на этот показатель, также влияет сборка мусора при select.

    Fetches

    Индикатор операций с памятью (включая CPU). Сколько было обращений к странице в кэше, чтение записей, чтение ключей, чтение страниц указателей, и т.п.

  • Опыт показывает, что наиболее значительные проблемы с производительностью вызваны отсутствием нужных индексов. Проверьте, существуют ли индексы, которые может использовать данный запрос. Если нет - постройте их.

    При наличие нескольких индексов оптимизатор выберет имеющие лучшую селективность и отбросит индексы, имеющие худшую, поэтому необходимо ее периодически пересчитывать (вручную или по расписанию).

Проблема с Антивирусом

Признаки

  • Система медленно работает.

Антивирус перехватывает большинство системных вызовов, поэтому может вызвать замедление в совершенно неожиданных местах. Наблюдалось замедление ввода-вывода, замедление сети, замедления доступа к памяти.

Рекомендации

  • Отключите или удалите антивирус. Если производительность улучшилась, попробуйте выборочно отключить антивирус для временной папки СУБД.

Производительность файловой системы

Признаки

  • Показатель IOPS производительности системы хранения данных значительно медленнее, чем производительность самого устройства. Можно ожидать значения IOPS для каждого SSD по крайней мере 5000 (для пары, если они "зеркальные") и по крайней мере 130 IOPS для каждого жесткого диска (для пары, если они "зеркальные").

Рекомендации

  • Рекомендуется иметь размер кластера файловой системы, совпадающий с размером страницы базы данных.

  • Для многоуровневых конфигураций (например виртуализация) должны быть оценены накладные расходы на каждом уровне в плане задержек и пропускной способности операций ввода-вывода. Конфигурация должна быть настроена, чтобы обеспечить приемлемый уровень производительности.