Сайт тормозит: как проверить базу данных и выбрать решение

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

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

Что означает перегрузка базы данных

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

Важно отличать перегрузку базы данных от общей медленной работы сайта. Запрос может долго ждать ответа из-за приложения, внешнего API, сетевой задержки или очереди на веб-сервере. Поэтому единичный медленный ответ не является доказательством проблем с СУБД.

Надёжная диагностика обычно опирается на несколько признаков одновременно:

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

Наблюдаемые признаки перегрузки

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

Полезно сопоставить симптом с возможной причиной:

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

Первичная проверка на стороне хостинга

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

Проверку лучше проводить по временной шкале:

1. Запишите точное время начала и окончания замедления.
2. Сопоставьте этот интервал с графиками CPU, памяти и диска.
3. Проверьте, не достигнуты ли лимиты по соединениям, процессам, размеру базы или дисковому пространству.

Проверить подходящий вариант можно на странице Beget.

1. Посмотрите журналы веб-сервера, приложения и базы данных за тот же период.
2. Сравните показатели с обычной нагрузкой в аналогичное время.
3. Отдельно отметьте автоматические задания: резервное копирование, импорт, обновление индексов, рассылки и пакетную обработку данных.

На общем хостинге пользователь часто не имеет доступа к системным показателям и журналам СУБД. В таком случае нужно запросить у провайдера фактическое потребление ресурсов, действующие ограничения и время возникновения пиков. Формулировка «сайт работает медленно» недостаточна; гораздо полезнее указать адрес операции, временной интервал, частоту ошибки и идентификатор аккаунта или базы.

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

Диагностика внутри СУБД

Если хостинг предоставляет доступ к консоли или инструментам мониторинга, сначала нужно посмотреть активные операции. Для PostgreSQL пример запроса выглядит так:

SELECT
    pid,
    now() - query_start AS duration,
    state,
    wait_event_type,
    wait_event,
    left(query, 200) AS query_text
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;

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

Для поиска блокировок в PostgreSQL можно дополнительно проверить отношения между ожидающими и блокирующими процессами:

SELECT
    waiting.pid AS waiting_pid,
    blocking.pid AS blocking_pid,
    waiting.query AS waiting_query,
    blocking.query AS blocking_query
FROM pg_stat_activity AS waiting
JOIN pg_stat_activity AS blocking
  ON blocking.pid = ANY(pg_blocking_pids(waiting.pid));

В MySQL или совместимых системах начальную проверку можно выполнить через:

Перед настройкой откройте Beget и сверьте актуальные условия.

SHOW FULL PROCESSLIST;

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

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

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

Как отделить проблему базы данных от других причин

Диагностика становится точнее, если один и тот же запрос рассматривается сразу в трёх местах: в журнале приложения, в журнале СУБД и на графике ресурсов хостинга. Если приложение ждёт базу, но в СУБД нет длительных операций и ресурсы свободны, причиной может быть неверно настроенный пул соединений или сетевой путь. Если в СУБД видны долгие запросы, а CPU и диск загружены, нужно анализировать SQL и план выполнения. Если запросы ждут блокировку, увеличение вычислительных ресурсов само по себе может не дать результата.

Полезно проверить несколько типичных сценариев:

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

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

Безопасный порядок действий

Практический план диагностики можно оформить как короткий журнал инцидента:

1. Зафиксировать URL или операцию, которая замедлилась, и точное время.
2. Сохранить несколько примеров запросов и ответов приложения с длительностью и кодом результата.

Когда требования понятны, перейдите в Beget и проверьте выбранный вариант.

1. Снять показатели хостинга за период до, во время и после проблемы.
2. Проверить активные запросы, блокировки и число соединений.
3. Найти повторяющиеся медленные запросы в журнале.
4. Проверить план выполнения на тестовой или безопасной копии данных.
5. Сформулировать одну проверяемую гипотезу и изменить только один параметр.
6. Повторить измерение после изменения и сравнить результаты с исходным периодом.

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

Что запросить у провайдера

Если необходимых метрик нет в панели, провайдеру можно направить конкретный список вопросов:

• Каковы фактические ограничения тарифа по CPU, памяти, дисковым операциям и числу соединений?
• Были ли достигнуты эти ограничения в указанный период?
• Какое максимальное число одновременных подключений разрешено для данной базы?
• Есть ли отдельные лимиты на размер базы, временное пространство, процессы и длительность запроса?
• Наблюдались ли технические работы, резервное копирование или миграция узла в момент инцидента?
• Можно ли получить обезличенную статистику медленных запросов и ожиданий?
• Какие изменения произойдут после перехода на другой тариф?
• Сохранится ли прежний адрес базы, версия СУБД и набор доступных расширений?

Ответ провайдера нужно сохранить вместе с графиками и журналами. Сведения о тарифах и заявленных возможностях описывают условия услуги, однако не заменяют фактические показатели конкретного инцидента. Если провайдер не предоставляет данные о нагрузке, в итоговом отчёте следует прямо указать, какие параметры проверить невозможно.

Как сформулировать вывод

Итог диагностики должен разделять факт, гипотезу и подтверждённое действие. Например:

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

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

Что почитать дальше

• Beget.API: автоматизация хостинга для малых проектов
• Какие ресурсы нужны боту и почему их пока нельзя оценить
• Несколько сервисов на одном компьютере: что может Beget.API
• Нужна ли база данных лендингу: проверка на примере Beget
• Beget: как быстро разместить сайт, бота или AI-проект в 2026

Обложка вдохновлена картиной Василия Кандинского «Композиция VIII» (1923). Посмотреть оригинал в коллекции Музея Соломона Гуггенхайма.