---
title: Сайт на 1С-Битрикс начал тормозить, хотя вы ничего не меняли? В 90% случаев виноваты три вещи
description: Сайт на 1С-Битрикс тормозит, хотя вы ничего не меняли? Три частые причины — распухшая база, неработающий кэш и вставший cron с агентами — и как проверить себя за 10 минут во встроенном мониторе производительности Битрикса.
source: https://pingvera.ru/blog/bitrix-tormozit-3-prichiny.html
---
# Сайт на 1С-Битрикс начал тормозить, хотя вы ничего не меняли? В 90% случаев виноваты три вещи

Знакомая картина. Полгода назад сайт летал, а теперь каждая страница «думает» пару
 секунд, каталог подгружается рывками, админка реагирует с задержкой, будто нехотя. При этом
 вы ничего не трогали: не меняли дизайн, не ставили новых модулей, не переезжали на другой
 хостинг. Сайт просто взял и начал тормозить **сам по себе**.

Первая мысль обычно паническая: «нас взломали» или «надо срочно менять хостинг». Чаще всего и
 то, и другое — мимо. Сайт на Битриксе почти никогда не «ломается» внезапно. Он деградирует
 медленно, неделями, и в подавляющем большинстве случаев причина прячется в одном из трёх мест.
 Разберём их простым языком — и заодно покажу, как проверить своё состояние самому, не нанимая
 никого.

## Сначала плохая новость: вы теряли деньги ещё до того, как заметили

Прежде чем про причины — про то, почему это вообще стоит того, чтобы читать дальше.

Медленный сайт — это не «неприятно», это «дорого». Есть давно известное эмпирическое правило:
 каждая лишняя секунда загрузки заметно роняет конверсию, а задержка в две-три секунды способна
 срезать вероятность заказа почти на треть. Дальше арифметика безжалостная. Вы платите за
 рекламу, человек кликает, попадает на «задумавшийся» сайт, ждёт, не дожидается, уходит к
 конкуренту — и ваш рекламный бюджет утекает в никуда. Плюс поисковики не любят медленные сайты
 и понижают их в выдаче, так что вы теряете ещё и бесплатный трафик.

И вот что обиднее всего: к тому моменту, когда тормоза стали заметны вам, они уже несколько
 недель тихо съедали ваши заявки. Просто никто не смотрел.

Запомните этот тезис — он ключевой. Тормоза не возникают за одну ночь. Они накапливаются. А раз
 накапливаются — значит, их можно было увидеть заранее. Но об этом в конце.

## Причина №1. База данных распухла

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

Ровно это происходит с базой данных Битрикса. Со временем она обрастает балластом: сессии давно
 ушедших посетителей, брошенные корзины, статистика за все годы, журналы, временные данные.
 Таблицы пухнут, и запросы, которые раньше отрабатывали мгновенно, начинают ползти. Сайт делает
 ту же работу, что и всегда, — просто каждый раз перелопачивает гору лишнего.

**Как это выглядит со стороны:** тормозит и сама витрина, и админка. Особенно
 заметно на списках, фильтрах, каталоге — там, где система роется в базе.

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

## Причина №2. Кэш не работает так, как должен

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

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

**Как это выглядит:** каталог и карточки товаров «думают», а нагрузка на сервер
 скачет именно в моменты обмена с 1С.

**Что с этим делают:** включают и правильно настраивают типовое и композитное
 кэширование, а логику обмена с 1С перестраивают так, чтобы она не сбрасывала весь кэш по любому
 поводу.

## Причина №3. Встали агенты и cron — самая коварная

Это причина, которую владельцы понимают хуже всего, а она при этом — частый корень зла.

У Битрикса есть фоновые задачи, так называемые «агенты»: чистка устаревших данных, индексация,
 отправка писем, обмены, служебные операции. Они должны тихо выполняться по расписанию в фоне —
 для этого настраивается механизм cron на сервере. Когда всё в порядке, вы об этих задачах даже
 не знаете: они делают свою работу, пока вы спите.

А теперь представьте, что cron не настроен или однажды сломался — например, после обновления
 или переезда. Фоновые задачи перестают выполняться по расписанию и начинают одно из двух: либо
 копятся в очередь, которая растёт как снежный ком, либо запускаются «на лету» прямо в момент,
 когда на сайт зашёл живой покупатель, — и тормозят именно его страницу, заодно нагружая сервер.

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

**Что с этим делают:** настраивают и проверяют режим cron, следят, чтобы агенты
 выполнялись по расписанию, а не дёргали живых посетителей.

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

## Как проверить себя самому за десять минут

Хорошая новость: Битрикс умеет диагностировать себя сам, и для этого не нужен программист.

Зайдите в админке в раздел **Настройки → Производительность** (в разных редакциях
 он называется «Панель производительности» или «Управление производительностью»). Там есть
 монитор, который прогоняет вашу конфигурацию и выставляет ей балл. Грубый ориентир — около 30;
 чем выше число, тем лучше настроена система. Если у вас сильно меньше — это уже сигнал.

В рекомендациях по настройкам в идеале не должно быть «красных» пунктов: каждая красная строка
 — это узкое место. А во вкладке для разработки монитор показывает самые «тяжёлые» страницы —
 те, что создают наибольшую нагрузку. Часто там обнаруживается что-то неожиданное, что в обычной
 жизни себя не проявляет.

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

## Почему разовый аудит — это лечение симптома, а не болезни

Допустим, вы всё это нашли (или наняли человека, который нашёл) и починили. Сайт снова летает.
 Победа?

На пару месяцев — да. А потом происходит вот что. База снова постепенно распухает — посетители
 ходят, корзины бросаются, статистика копится. Кто-то ставит новый модуль, который тянет лишнее.
 После очередного обновления снова отваливается cron. И в один прекрасный день — снова тот же
 звонок: «сайт тормозит, хотя мы ничего не меняли».

В этом и есть ловушка разовой оптимизации. Все три причины — накопительные по своей природе.
 Аудит за один-два дня делает снимок состояния на сегодня и приводит его в порядок. Но он не
 сторожит ваш сайт завтра. Это как сходить к стоматологу, вылечить зуб — и считать, что чистить
 зубы больше не нужно. Через полгода вы вернётесь с той же проблемой.

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

## Что реально помогает: видеть дым, а не тушить пожар

Решение не в том, чтобы чинить быстрее. Оно в том, чтобы узнавать о проблеме раньше — когда
 показатели только поползли, а клиент ещё ничего не заметил.

Технически это значит одно: за скоростью базы, кэшем, фоновыми задачами и временем отклика сайта
 нужно следить **непрерывно**, а не раз в полгода. Тогда вы видите не свершившийся
 факт «сайт лёг», а тенденцию: «база начала отвечать в три раза медленнее обычного», «кэш
 настроен не оптимально», «cron перестал отрабатывать», «время отклика поползло вверх». И
 реагируете заранее, в спокойном режиме, а не в авральном — и не в сезон.

Именно для этого мы и сделали Pingvera. Сервис ставит лёгкий коннектор внутрь вашего Битрикса и
 держит руку на пульсе ровно тех трёх вещей, о которых вся эта статья: снимает баллы встроенного
 монитора производительности (perfmon) — **включая реальную скорость базы данных**;
 проверяет **состояние кэша** — тип хранилища (файлы или быстрый Memcached/Redis),
 включён ли композитный сайт и управляемый кэш; следит за режимом запуска агентов и cron и ловит
 просроченные агенты (те самые «вставшие» фоновые задачи). Плюс прогоняет штатную «Проверку
 системы» Битрикса. Параллельно — **внешние пробы**: замеряют реальное время отклика
 сайта из нескольких регионов России и из-за рубежа (заодно ловят ситуацию, когда сайт лёг для
 части страны, а у вас открывается). Как только что-то уходит от нормы — perfmon просел, кэш
 настроен не оптимально, агенты встали, время отклика поползло вверх, — вы получаете уведомление
 в Telegram или на почту, до того как сайт начнёт тормозить при клиентах. Плюс сервис следит за
 сроком домена и SSL, чтобы сайт однажды не исчез из-за нелепо забытой оплаты.

Смысл простой: перестать узнавать о проблемах из звонка разъярённого клиента и начать узнавать
 о них из спокойного уведомления — заранее.

## Коротко, если лень читать всё

Если сайт на 1С-Битрикс начал тормозить «сам по себе», не паникуйте про взлом и не бегите
 менять хостинг. В девяти случаях из десяти виноваты три вещи:

- **Распухшая база данных** — лечится чисткой и оптимизацией таблиц.
- **Неработающий кэш** — настраивается типовое и композитное кэширование,
 особенно если у вас частый обмен с 1С.
- **Вставший cron и агенты** — настраивается расписание фоновых задач.

Проверить себя можно бесплатно за десять минут во встроенном мониторе производительности
 (Настройки → Производительность). А чтобы это не превратилось в бесконечный круг «починили —
 через полгода снова тормозит», за этими тремя точками имеет смысл следить постоянно, а не раз
 в аварию. Потому что тормоза — это всегда сигнал, что система уже работает на пределе. И лучше
 услышать этот сигнал раньше своего клиента.

## Частые вопросы

**Почему сайт на 1С-Битрикс тормозит, если я ничего не менял?**

Битрикс почти никогда не «ломается» внезапно — он деградирует медленно. В девяти случаях из
 десяти причина в одном из трёх мест: распухла база данных (накопились сессии, корзины,
 статистика), перестал работать кэш (часто из-за частого обмена с 1С) или встал cron и
 фоновые агенты после обновления либо переезда. Все три причины накопительные, поэтому
 тормоза появляются «сами по себе».

**Как проверить производительность Битрикса самому?**

Зайдите в админке в раздел Настройки → Производительность (Панель производительности).
 Встроенный монитор прогонит конфигурацию и выставит балл — грубый ориентир около 30, чем
 выше, тем лучше. В рекомендациях не должно быть «красных» пунктов, а во вкладке для
 разработки видны самые тяжёлые страницы. Менять тонкие настройки сервера БД самостоятельно
 не стоит — смотреть диагностику можно и нужно, а крутить значения лучше со специалистом.

**Сколько стоит мониторинг Битрикса в Pingvera?**

Начать можно бесплатно: бесплатный тариф покрывает до 5 сайтов с проверками от 1 минуты —
 этого хватает, чтобы следить за доступностью, сроком домена и SSL. Платные тарифы добавляют
 частые проверки и CMS-диагностику изнутри (perfmon, состояние кэша, агенты и cron Битрикса)
 через лёгкий коннектор.