> ## Documentation Index > Fetch the complete documentation index at: https://docs.axottle.com/llms.txt > Use this file to discover all available pages before exploring further. # Производительность > Медленная панель, медленные проверки здоровья, нагрузка на ноды и рост базы данных — где смотреть и что настроить. Проблемы производительности в Axottle обычно сводятся к четырём источникам: частому автообновлению в панели, слишком агрессивным интервалам проверок, нагрузке на самом ноде и неограниченному росту базы данных. Эта страница показывает, где смотреть и что в вашей власти настроить. Для кого: администратор панели, SRE. Требуемые права: администратор панели; для интервалов проверок — изменение политики здоровья; для управления базой — доступ к PostgreSQL панели. ## Медленный дашборд или панель Панель активно опрашивает бэкенд, чтобы показывать состояние в реальном времени. Это нормально, но при определённых условиях ощущается как «тормоза». * **Много открытых вкладок панели.** Дашборд и страница здоровья опрашивают сводку и инциденты каждые 15–60 секунд; несколько открытых вкладок означают несколько параллельных серий запросов. Держите открытой одну рабочую вкладку. * **Тяжёлый фильтр по аудит-логу.** Страница аудит-журнала фильтрует по подстроке. На большой таблице (аудит-лог не чистится автоматически — см. ниже) широкий запрос отрабатывает медленно. Сужайте фильтр (`?q=`), используйте постраничный вывод (`limit`/`offset`, максимум 500 записей на страницу). См. [Журнал и аудит](/ru/panel/journal-and-audit). * **Медленная зависимость.** Если тормозит конкретный экран (Remnawave, CDN), причина часто во внешней зависимости, а не в панели: живые запросы к Remnawave или провайдеру ждут ответа. Проверьте связность — [Проблемы связности](/ru/troubleshooting/connectivity). Общее состояние хоста панели (диск, память, CPU, база) быстрее всего снять через `axottle doctor` — он отдельно проверяет ресурсы и базу. См. [Обслуживание](/ru/operations/maintenance). ## Медленные проверки здоровья Плановые и ручные проверки ведут себя по-разному — это важно для интерпретации. * **Плановые проверки** идут по расписанию с интервалами по умолчанию: базовая достижимость — каждые 60 с, проверка служб — каждые 120 с, сквозная проверка схем — каждые 10 минут. Интервалы настраиваются в политике здоровья, но панель не даёт опустить их ниже безопасного минимума (15 с / 30 с / 60 с) — это защита от самоперегрузки. См. [Политики здоровья](/ru/health/policies). * **Ручные проверки** (кнопка «Запустить проверку», `POST .../check`) выполняются немедленно и делают ровно одну попытку без повторов. Если проверки «висят»: 1. Не пытайтесь ускорить систему, занижая интервалы — минимум всё равно применится, а нагрузка вырастет. Слишком частые проверки замедляют панель, а не ускоряют обнаружение. 2. Долгие сквозные проверки почти всегда упираются в медленную сеть до ноды или до цели маршрута, а не в панель. Разбирайте по [Runbook'ам здоровья](/ru/health/runbooks). ## Нагрузка на ноду Панель собирает с каждой ноды системные метрики: CPU, load average, память, swap, диск, сеть и дополнительные показатели (сокеты, conntrack, дескрипторы, давление CPU и т. д.). Где смотреть: * Вкладка **Сервисы** — что из служб ноды работает, а что `absent` (не установлено). Полный список показателей и как их читать — [Метрики и сервисы](/ru/nodes/metrics-and-services). Ряд метрик хранится ограниченно (по умолчанию около 7 дней), так что для ретроспективы за больший период снимайте показатели заранее. ## Рост базы данных Часть данных Axottle чистит сама, часть — сознательно нет. Знать разницу важно, чтобы диск панели не заполнился незаметно. | Что накапливается | Автоочистка | Кто отвечает | | ----------------------------------------- | ------------------------------------------------- | ---------------------------------------------------- | | Аудит-лог | **Нет** — записи хранятся бессрочно | Оператор: ретенцию нужно организовать на уровне базы | | Метрики нод | Да, старые ряды удаляются (по умолчанию \~7 дней) | Система | | История версий схемы подключения | Да, ограничена (последние версии на юнит) | Система | | Запуски бэкапов | Да, по `retention_count` профиля (по умолчанию 7) | Система + настройка профиля | | Предыдущие версии SelfSteal-сайта на ноде | Да, хранится ограниченное число | Система | Ключевой момент: **аудит-лог не имеет автоматической ретенции** — это сделано намеренно, чтобы не терять историю действий. На активной установке таблица со временем становится большой и замедляет фильтрацию по подстроке. Если вам нужна ретенция, это операторская задача: спланируйте периодическую архивацию/усечение аудит-лога на стороне PostgreSQL как обслуживаемую операцию. ## Рекомендации по хранению * Задайте профилям бэкапов разумный `retention_count` — старые запуски удаляются автоматически после каждого нового. См. [Резервные копии панели](/ru/operations/backups). * Держите бэкапы вне хоста панели (S3-совместимое хранилище), чтобы они не занимали локальный диск. * Следите за диском: `axottle doctor` предупреждает о заканчивающемся месте до того, как это станет аварией. * Если планируете ретенцию аудит-лога — сначала снимите проверенный бэкап базы, затем усекайте, и делайте это как плановую операцию обслуживания. См. [Обслуживание](/ru/operations/maintenance). ## Проверка Панель отзывчива, `axottle doctor` не показывает `Failed` по диску/памяти/CPU/базе, метрики нод собираются без пропусков, а объём аудит-лога находится под контролем выбранной вами ретенции. ## Откат Верните прежние интервалы во вкладке **Управление → Настройки → Health-политика**. Изменения профиля производительности ноды откатываются кнопкой **Rollback** во вкладке **Производительность**. ## Связанные страницы CPU, память, диск, сеть на ноде. Интервалы проверок и их минимумы. Аудит-лог и его ретенция. Doctor, бэкапы, регламент. Проверено для версии Axottle текущей ветки. Дата проверки: 2026-07-11.