5 самых распространенных проблем сайтов на 1С-Битрикс

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

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

Мы видели следующие ошибки:

• MySQL переставал отвечать.
• Процесс MySQL завершался из-за нехватки памяти.
• Утилизация доступных подключений превышала 95%.
• Репликация была отключена или работала некорректно.
• Требовалось восстанавливать поврежденную базу из резервной копии.
• Отсутствовал тюнинг параметров БД под реальную нагрузку.
• Медленные запросы создавали дополнительную нагрузку.
• Отдельные таблицы разрастались до десятков гигабайт.
• У крупных таблиц отсутствовали индексы.
• Архитектура кластера БД не обеспечивала автоматического переключения при отказе.

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

Сначала определяем, где именно находится ограничение: ресурсы сервера, настройки MySQL/MariaDB, запросы приложения, структура таблиц, индексы, репликация или архитектура самой БД.

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

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

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

Если какой-то ресурс регулярно подходит к пределу, это уже повод разбираться, даже если пользователи пока не жалуются.

Отдельно стоит включить лог медленных запросов и посмотреть, какие запросы туда попадают. Эта проверка почти ничего не стоит и часто дает первое направление для диагностики.

Это одна из самых банальных проблем в списке — и одна из самых частых. Проблемы с дисковым пространством встречались почти в каждом из Битрикс-проектов.

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

Мы встречали ситуации, когда:

• Свободного места оставалось меньше 5%.
• Быстро росли логи Nginx.
• Разрастался лог медленных запросов MariaDB.
• Рос объем базы данных.
• Требовалось дополнительное место для импорта данных.
• Резервные копии занимали значительную часть диска.
• Логирование было организовано хаотично.
• Ротация логов отсутствовала или была настроена неправильно.

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

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

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

Самое неприятное — проблема развивается постепенно, поэтому ее легко предотвратить. Между состояниями «места становится мало» и «сайт перестал работать» обычно есть время.

Если, конечно, кто-то смотрит на этот показатель.

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

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

После этого настраиваем мониторинг свободного пространства и пороги предупреждений.

Задача — сделать заполнение диска прогнозируемым событием, а не аварией.

Посмотрите, сколько свободного места осталось на продакшен-серверах.
Если занято больше 80−90%, определите крупнейшие каталоги и поймите, что именно растет.

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

Это одна из самых дешевых профилактических мер во всей инфраструктуре.

Отдельная категория проблем — слой, непосредственно обслуживающий запросы пользователей: Nginx, Apache, PHP и PHP-FPM. И здесь особенно легко ошибиться при диагностике. Пользователь видит, что «тормозит Битрикс», хотя сам Битрикс ни при чем.

Мы видели, что:

• Apache переставал работать.
• Требовались изменения конфигурации Nginx.
• Nginx неправильно обрабатывал часть запросов.
• Возникали таймауты при ожидании ответа от Apache.
• PHP упирался в лимиты памяти.
• PHP-FPM был установлен, но не использовался.
• Требовалась оптимизация PHP-FPM.
• Использовались устаревшие версии PHP.
• В конфигурации Nginx накопилось много ручных изменений.
• Логи веб-сервера содержали ошибки, указывающие на проблемы приложения или его конфигурации.

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

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

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

В результате проблему легко ошибочно решить покупкой более мощного сервера. Ресурсов становится больше, симптом на некоторое время исчезает, но причина остается.

Разбираем всю цепочку обработки запроса: Nginx, Apache, PHP/PHP-FPM и взаимодействие с приложением.

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

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

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

Начните с логов Nginx/Apache и PHP. Не нужно читать их целиком: посмотрите ошибки за последние несколько дней и найдите повторяющиеся сообщения.

Затем проверьте версии PHP, Nginx и Apache и выясните, поддерживаются ли они сейчас. Перед обновлением нужно проверить совместимость сайта, но даже если сайт в текущем виде не будет работать с актуальной версией ПО, требуется запланировать доработку, не дожидаясь, пока сайт взломают.

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

Резервное копирование было у каждого из наших Битрикс-клиентов. И ни у кого не работало идеально.

Мы видели:

• Ошибки выполнения резервного копирования.
• Отсутствие ожидаемой резервной копии.
• Отсутствие регулярных бэкапов MySQL.
• Необходимость увеличить место под резервные копии.
• Нереализованное отдельное резервное копирование файлов и базы.
• Неудачные схемы хранения резервных копий.
• Отсутствие контроля наличия свежих копий.
• Неудачные механизмы резервного копирования для больших баз.

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

Худший сценарий очевиден: потеря данных.

Но возможны и другие варианты. Копия есть, однако восстановление занимает слишком много времени. База восстановилась, а файлов сайта нужной версии нет. Копии хранятся на том же сервере, который вышел из строя. Бэкап перестал выполняться несколько недель назад, но никто этого не заметил.

Поэтому правильный вопрос звучит не "Делаем ли мы бэкапы?" а "До какого состояния и за какое время мы сможем восстановить сайт, если этот сервер исчезнет прямо сейчас?"

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

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

Конечная точка работы — проверяемая процедура восстановления.

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

Попросите ответственного сотрудника показать последнюю резервную копию базы и файлов сайта.

Затем задайте три вопроса: когда она создана, где физически хранится и кто знает процедуру восстановления.

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

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

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

После этого настраиваем сбор метрик и алерты для серверов, базы данных, веб-сервера и других необходимых сервисов.

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

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

Составьте список из пяти компонентов, без которых ваш сайт не сможет работать.
Напротив каждого ответьте на два вопроса:

1. Как мы узнаем, что этот компонент перестал работать?
2. Узнаем мы об этом раньше пользователя или после него?

Если ответ на второй вопрос — «после», мониторинг этой части инфраструктуры стоит настроить в первую очередь.

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

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

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

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

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