Как мы искали причину тормозов сайта: история одной диагностики

Задача: сайт на «1С-Битрикс» периодически тормозит. Время ответа сервера прыгает до 11 секунд. При этом средняя нагрузка на сервер — низкая. Непонятно, в чём дело.

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

---

1. Первые симптомы

Сайт работал более-менее стабильно, но иногда случались «просадки»:

• время ответа сервера по Zabbix подскакивало до 1–11 секунд;
• страницы открывались с большой задержкой;
• админка Битрикса подвисала.

При этом нагрузка на CPU и память была в пределах нормы. Трафик — невысокий (всего ~2 МБ/с в среднем).

Ошибочная версия: сначала грешили на базу данных, на сложные запросы, на Битрикс.

Правда: проблема оказалась совсем в другом.

---

2. Что сделали (диагностика)

2.1. Zabbix + сбор статистики

Настроили сбор метрик по веб-серверу, PHP, MySQL и файловой системе. Смотрели в динамике в течение 3 дней.

Выявили чёткую корреляцию:

• в моменты тормозов — резко возрастает время ожидания ответа от файловой системы;
• MySQL работал ровно;
• процессов PHP — не больше 4 одновременно (лимит хостинга).

Вывод: дело не в базе, не в коде, а в операциях с файлами.

2.2. Анализ ограничений хостинга

Полезли в технические условия хостинга. Оказалось:

• лимит количества файлов — 150 000 (на весь аккаунт);
• лимит PHP-процессов — 4;
• при превышении лимита файлов — хостинг начинает искусственно замедлять операции чтения/записи (throttling).

Это идеально объясняло «плавающие» тормоза: сайт работал, но как только доходило до массового создания/удаления кэша или сессий — всё вставало.

2.3. Подсчёт файлов

Выполнили в консоли:

cd /путь/до/сайта
find . -type f | wc -l

Увидели страшную цифру: больше 170 000 файлов, при лимите 150 000.

Самые тяжёлые папки:

/bitrix/modules       → 38 665 файлов
/bitrix/js            → 13 291
/bitrix/components    → 11 430
/bitrix/wizards       → 3 606
/bitrix/blocks        → 2 763

Только один модуль landing весил ~9 000 файлов, из которых 8 368 лежали в папке install/ — установочном мусоре.

---

3. Что было сделано (чистка)

3.1. Удаление установочных папок модулей

У любого модуля Битрикса папка /install/ не нужна после установки.

Удалили:

/bitrix/modules/landing/install/
/bitrix/modules/каждый_тяжёлый_модуль/install/

Результат: минус 8–10 тысяч файлов моментально.

3.2. Очистка кэша

Через админку Битрикса:

• Настройки → Автокеширование → Очистить всё
• Дополнительно удалили вручную папку /bitrix/cache/ и /bitrix/managed_cache/ (там временные файлы).

Результат: ещё минус тысячи мелких файлов-однодневок.

3.3. Логи и сессии

Очистили:

/bitrix/php_interface/logs/
/bitrix/sessions/

Сессии пересоздадутся сами, старые логи не нужны.

3.4. Неиспользуемые модули

В админке (Настройки → Модули) отключили и удалили всё, что не используется:

• форумы, блоги, опросы
• веб-мессенджер
• облачные сервисы (если не нужны)
• социальные сети

Результат: минус ещё несколько тысяч файлов.

3.5. Демо-шаблоны модулей

В /bitrix/modules/landing/data/demo/ и аналогичных папках других модулей удалили предустановленные демо-макеты, которые не используются на проекте.

---

4. Итоговый эффект

После чистки:

• общее количество файлов снизилось с 170 000+ до ~140 000 (вплотную к лимиту);
• просадки времени ответа почти исчезли;
• сайт стал заметно отзывчивее.

Важно: тариф не меняли (VPS дорого). Просто «подмели» то, что годами копилось в файловой системе.

---

5. Что поняли (и пригодится вам)

1. Не только база тормозит. Файловая система — частый виновник, особенно на shared-хостинге.
2. Лимиты хостинга надо знать наизусть. 150 000 файлов — это не так много для Битрикса после пары лет работы.
3. Модули landing и интернет-магазин — абсолютные рекордсмены по количеству файлов.
4. Папка /install/ в любом модуле — безопасный мусор. Удаляйте смело.
5. Zabbix + ручной подсчёт файлов дали ответ быстрее, чем неделя переписок с техподдержкой.

---

P.S. Что делать, если вы всё ещё выходите за лимит

Если после чистки вы всё равно на грани лимита (140–150 тыс. файлов), варианта два:

• менять тариф на более дорогой (с бóльшим лимитом);
• переходить на VPS (там этих лимитов нет).

Но в нашем случае удалось отсрочить переезд на полгода-год за счёт простой, но кропотливой уборки.

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

← Назад к списку