Просмотр кода страницы Улучшение производительности базы данных

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

Вы можете оптимизировать свои базы данных с помощью:

* Данных сервера, поддерживающие мониторинг работоспособности хоста.
* Метрики гипервизора и виртуальной машины, которые поддерживают мониторинг вашего уровня виртуализации.
* Данных приложения, которые оптимизируют доступ к базе данных
* Сетевых данных, которые дают представление о сетевом влиянии связи с базой данных.

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

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

=== Процессор ===

* Оснастите каждый хост минимум двумя ядрами ЦП. Сопоставление количества процессоров вашего хоста помогает:
** Обеспечить оперативность хоста, поскольку серверы баз данных создают постоянную базовую нагрузку на машины.
** Предотвратить перерасход средств или аппаратных ограничений, поскольку на лицензирование сервера базы данных влияет количество процессоров.
* При мониторинге виртуальных машин также следите за хостом, на котором работают виртуальные машины. Это дает более полную картину, чем показатели ЦП отдельных виртуальных машин, которые позволяют получить информацию только о доступности соответствующего процессорного времени.

[[Файл:Виртуальные машины.png|граница]]

=== Память ===

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

[[Файл:Память.png|граница]]

=== Дисковое пространство ===

* Убедитесь, что доступность хранилища для вашего сервера базы данных превышает дисковое пространство, необходимое для данных.  Из-за индексов и других улучшений производительности базы данных могут использовать больше дискового пространства, чем требуется для самих данных. Например, базы данных NoSQL (такие как Cassandra и MongoDB) занимают гораздо больше дискового пространства, чем ожидалось. По сравнению с обычными базами данных SQL, базы данных MongoDB могут потреблять меньше оперативной памяти, но больше дискового пространства.
* Убедитесь, что ваша база данных работает на выделенных жестких дисках, чтобы уменьшить фрагментацию диска, вызванную другими процессами.
* Проверьте '''Дисковая задержка'''.  В зависимости от нагрузки на жесткий диск задержка диска может увеличиться, что приведет к снижению производительности базы данных. Вы можете предотвратить высокую задержку диска, максимально используя механизмы кэширования вашего приложения и базы данных.

[[Файл:Диск.png|граница]]

* Если результаты вышеуказанных мер неудовлетворительны, рассмотрите следующее.
*# Добавьте дополнительные жесткие диски.  Производительность чтения можно увеличить, за счет дублирования жестких дисков. Повышение производительности записи достигается за счет использования RAID 1 или RAID 10 вместо RAID 6.
*# Попробуйте твердотельные накопители (SSD).  Убедитесь, что вы выбрали модель, предназначенную для использования базы данных, поскольку базы данных требуют большего количества циклов чтения/записи в хранилище, чем большинство распространенных приложений. Твердотельные накопители дороже традиционных жестких дисков, но обеспечивают существенный прирост производительности.

== Узнайте, как осуществляется доступ к вашей базе данных ==
Как только ваша база данных будет размещена на работоспособном оборудовании, обратите внимание на приложения, которые имеют к ней доступ. Если вы знаете приложение или службу, у которой низкая производительность базы данных, это не означает, что это приложение влияет на производительность вашей базы данных — это может быть совершенно другое приложение или служба.

[[Файл:Доступ к базе данных.png|граница]]

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

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

== Узнайте нагрузки и индивидуальное время отклика каждого экземпляра службы. ==
Если у службы низкая производительность базы данных, вы можете проанализировать ее взаимодействие с базой данных с помощью '''операторов базы данных''' . Вы можете получить информацию о количестве выполненных запросов, частоте выполнения запросов на каждый запрос, количестве строк, возвращаемых каждым запросом, и т. д.

[[Файл:Подробности базы данных.png|граница]]

* Если запущено несколько экземпляров службы, проверьте, не затронуты ли все экземпляры, а не один.

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

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

При настройке пула соединений учитывайте следующее:

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

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

=== Как определить максимальное количество подключений ===
Максимальное количество подключений к базе данных зависит от ресурсов в базе данных. Чтобы найти максимальное количество подключений, постепенно увеличивайте нагрузку и количество разрешенных подключений к вашей базе данных.

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

Дополнительные сведения о размере пула соединений с базой данных см. в разделе '''''Определение размера пула'''''.

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

Увеличение нагрузки приводит к увеличению времени отклика на транзакцию, даже если ваш сервер базы данных исправен. Измерьте время отклика транзакции от начала до конца, чтобы увидеть, увеличивается ли время установления соединения при большой нагрузке. В этом случае ваш пул соединений может быть исчерпан. Если нет, просмотрите показатели сервера базы данных, чтобы определить максимальное количество соединений, которые может обработать ваша база данных.

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

== Проверьте свою сеть ==
Физические ограничения вашей виртуализированной инфраструктуры могут повлиять на производительность базы данных; кабели могут выйти из строя, а маршрутизаторы могут сломаться. Сетевые метрики позволяют получить представление о не виртуальных проблемах. Например, если проблемы возникают после месяцев или даже лет безупречной работы, возможно, в вашей инфраструктуре возникли физические проблемы. Проверьте свои маршрутизаторы, кабели и сетевые интерфейсы.

[[Файл:Физ проблемы баз данных.png|граница]]

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