Диагностика ошибок BitrixVM: 502, 504 и высокий CPU на 1С-Битрикс
Находим и устраняем причины ошибок 502 и 504, перегрузки CPU и памяти на BitrixVM: анализируем логи nginx, php-fpm и MySQL, ловим утечки, медленные запросы и зависания agents и cron. Сначала аварийно стабилизируем сайт, затем убираем корневую причину, чтобы сбои не повторялись.
Где BitrixVM отдаёт 502, 504 и грузит процессор
Ошибки 502 и 504, перегрузка CPU и памяти почти всегда имеют конкретную причину в стеке nginx, php-fpm и MySQL. Ниже типовые симптомы и то, что за ними стоит на самом деле.
Путь запроса и где он ломается
Запрос идёт от пользователя через nginx к php-fpm и MySQL. Мы проходим эту цепочку по шагам и на каждом узле проверяем логи, таймауты и нагрузку, пока не найдём звено, которое отдаёт 502, 504 или жжёт процессор.
Что входит в диагностику BitrixVM
Разбираем сбой по всему стеку — от точки входа nginx до запросов MySQL и фоновых заданий Битрикса, чтобы найти корневую причину, а не залечить симптом.
Как мы находим и убираем причину сбоя
Действуем по порядку: сначала возвращаем сайт в строй, затем спокойно ищем корень проблемы и закрываем его так, чтобы он не вернулся.
Как обычно борются с 502, 504 и высоким CPU
| Критерий | Перезагрузка и апгрейд | Хостинг или фрилансер | Студия B2Bsite |
|---|---|---|---|
| Подход к проблеме | Симптом гасится на время | Реакция по остаточному принципу | Сначала стабилизация, потом причина |
| Глубина разбора | Причина остаётся | Чинят то, что видно сразу | Разбор nginx, php-fpm и MySQL целиком |
| Расходы на инфраструктуру | Растут расходы на железо | Без разбора всего стека | Запас по нагрузке без апгрейда |
| Повторяемость сбоя | Сбой возвращается под нагрузкой | Часто без отчёта и мониторинга | Профилактика и мониторинг сбоев |
| Прозрачность и гарантии | Нет понимания, что произошло | Ответственность размыта | Отчёт с причиной и SLA |
Сколько занимает диагностика и устранение
Сроки зависят от того, лежит ли сайт прямо сейчас и насколько глубоко спрятана причина. Ориентиры — ниже.
Сколько стоит диагностика BitrixVM
Стоимость зависит от срочности и глубины проблемы. Экспресс-аудит и первая гипотеза — бесплатно. Ниже ориентиры, точную смету присылаем после короткого осмотра сервера.
Быстрый разбор одного инцидента: 502, 504 или скачок CPU.
- Сбор и чтение логов
- Поиск причины сбоя
- Аварийная стабилизация
- Короткий отчёт с выводами
Глубокий разбор стека и устранение корневой причины.
- Разбор nginx, php-fpm и MySQL
- Профиль CPU и памяти, утечки
- Медленные запросы и индексы
- Проверка agents и cron
- Устранение причины и проверка
- Отчёт и план профилактики
Мониторинг, реакция на инциденты и поддержание стабильности.
- Мониторинг и оповещения 24/7
- Реакция на падения и 502/504
- Регулярный разбор нагрузки
- Корректировка лимитов и настроек
- Отчёты по инцидентам
Экспресс-диагностика от 9 000 ₽
Быстрый разбор одного инцидента: 502, 504 или скачок CPU.
- Сбор и чтение логов
- Поиск причины сбоя
- Аварийная стабилизация
- Короткий отчёт с выводами
Популярный Полная диагностика от 24 000 ₽
Глубокий разбор стека и устранение корневой причины.
- Разбор nginx, php-fpm и MySQL
- Профиль CPU и памяти, утечки
- Медленные запросы и индексы
- Проверка agents и cron
- Устранение причины и проверка
- Отчёт и план профилактики
Стабилизация и контроль от 18 000 ₽ в месяц
Мониторинг, реакция на инциденты и поддержание стабильности.
- Мониторинг и оповещения 24/7
- Реакция на падения и 502/504
- Регулярный разбор нагрузки
- Корректировка лимитов и настроек
- Отчёты по инцидентам
Дополнительные опции
| Срочный выезд в инцидент вне рабочих часов | от 6 000 ₽ |
| Настройка мониторинга и оповещений | от 12 000 ₽ |
| Оптимизация и ускорение BitrixVM | от 30 000 ₽ |
Во сколько обходятся простои из-за сбоев
Прикиньте, сколько выручки уносят падения и ошибки 502 и 504. Каждый час, когда сайт не отвечает, — это потерянные заказы и обращения.
Оценка по формуле: часы простоя × выручка в час × доля потерянных заказов. Это ориентир потерь, которые убирает устранение причины сбоев, а не гарантия.
Подберём формат диагностики под ваш случай
Ответьте на пару вопросов о симптомах и нагрузке — подскажем, нужна ли экспресс-диагностика, полный разбор стека или постоянный мониторинг, и пришлём ориентир по срокам и стоимости.
Кейсы по диагностике BitrixVM
Что говорят после устранения сбоев
Частые сбои BitrixVM — и что за ними стоит
Это не общие советы, а закономерности из разобранных инцидентов. Каждый ответ — позиция нашей команды по реальным причинам сбоев.
На что можно рассчитывать по договору
Диагностика ошибок BitrixVM: что это и как устроено
Диагностика ошибок BitrixVM — это системный поиск причины, по которой сайт на 1С-Битрикс отдаёт 502 Bad Gateway или 504 Gateway Timeout, грузит процессор на сто процентов, течёт по памяти или замирает на минуты. Мы не глушим симптом перезагрузкой и не предлагаем сразу докупать железо. Задача диагностики — пройти весь стек от точки входа nginx через php-fpm до MySQL, агентов и cron, найти конкретное звено, которое ломается, и убрать корневую причину, чтобы сбой перестал повторяться.
Важная особенность нашего подхода — порядок действий. Если сайт лежит прямо сейчас, первым делом мы аварийно стабилизируем его: возвращаем в рабочее состояние за счёт лимитов пулов, перезапуска служб, отсечки паразитного трафика и быстрых заплаток. И только когда сайт снова отвечает, спокойно ищем настоящий источник проблемы. Такой порядок снижает потери от простоя и при этом не подменяет лечение симптоматикой: после стабилизации мы обязательно доходим до корня.
Какие сбои мы разбираем
Чаще всего к нам приходят с повторяющимися ошибками 502 и 504, со скачками нагрузки на процессор, с утечками памяти и уходом сервера в swap, а также с зависаниями, когда сайт замирает и потом отвисает сам. За каждым из этих симптомов стоит ограниченный набор причин, и опытному инженеру они хорошо знакомы. Ошибка 502 почти всегда указывает на проблему в связке nginx и php-fpm, 504 — на слишком долгий запрос или внешний вызов, высокий CPU — на цикл в коде, тяжёлый агент или запрос без индекса, а замирания — на блокировки в базе данных.
Что именно мы проверяем при диагностике:
- логи nginx, php-fpm и MySQL: error.log, access.log, лог пула и slow query log;
- настройки пула php-fpm и соответствие числа воркеров реальному объёму памяти;
- профиль нагрузки на CPU и потребление памяти по процессам и пулам;
- медленные SQL-запросы, отсутствующие индексы и блокировки в базе;
- режим работы агентов Битрикса, расписание cron и зависшие задания;
- паразитный трафик ботов и парсеров, который раскачивает нагрузку.
Почему симптом лечить бесполезно
Самая частая ошибка при борьбе со сбоями — гасить симптом. Сайт упал с 502 — перезагрузили, заработало. Процессор в потолок — добавили ядер. Память кончается — докупили ОЗУ. Это даёт временное облегчение, но причина остаётся на месте и проявляется снова, обычно в самый неудобный момент под нагрузкой. Цикл в коде или запрос без индекса сожрут любой объём ресурсов, а завышенные таймауты лишь дольше держат висящие запросы. Диагностика отличается тем, что доводит разбор до конкретного источника и устраняет именно его.
Ещё одна причина не ограничиваться симптомами — деньги. Апгрейд железа повышает счёт за инфраструктуру каждый месяц, тогда как устранение корневой причины часто возвращает запас по нагрузке без всякого апгрейда. Нередко после оптимизации одного тяжёлого запроса или перевода агентов на cron сервер, который еле держался, начинает работать с тройным запасом на том же железе.
Как устроен сам процесс поиска
Диагностика идёт по цепочке, а не вразнобой. Сначала мы снимаем картину инцидента: когда и при каких условиях проявляется сбой, что менялось перед его появлением, какие свежие записи лежат в логах. Затем, если сайт лежит, аварийно стабилизируем его и сразу переходим к воспроизведению проблемы под нагрузкой — без воспроизведения легко спутать причину со следствием. На воспроизведённом сбое снимаем профиль процессора и памяти, ловим медленные запросы и зависшие задания, сводим разрозненные симптомы к единому источнику и только после этого вносим изменения. Каждый шаг опирается на данные из логов и метрик, а не на догадки, поэтому правки получаются точечными и обратимыми.
Отдельное внимание мы уделяем тому, чтобы не навредить боевому сайту. На этапе поиска причины мы ничего не меняем — только читаем. Любая правка, будь то корректировка лимитов пула, добавление индекса или вынос операции в фон, делается по согласованию и с резервной копией, чтобы откат был возможен в любой момент. Это особенно важно, когда сайт приносит деньги каждый час и любая необдуманная правка может превратить один сбой в каскад новых.
Что вы получаете в результате
Итог диагностики — это стабильно работающий сайт и понятный отчёт. В отчёте мы описываем, что было причиной сбоя, что именно сделали для её устранения и что стоит изменить, чтобы проблема не вернулась. Дополнительно настраиваем мониторинг и оповещения, чтобы о проблемах вы узнавали раньше, чем их заметят клиенты, и могли реагировать до того, как сайт ляжет. Такой подход превращает хаотичную борьбу с падениями в управляемый, предсказуемый процесс, где каждый сбой имеет объяснение и решение, а не остаётся пугающей загадкой, которая повторяется снова и снова.
Как мы разбираем 502, 504 и перегрузку BitrixVM
Когда сайт на BitrixVM начинает сыпать ошибками 502 и 504 или процессор уходит в потолок, у владельца обычно два пути. Первый — действовать наугад: перезагружать сервер, докупать ресурсы, перебирать настройки в надежде, что одна из них поможет. Второй — методичная диагностика, которая идёт от симптома к причине по понятной цепочке. Первый путь дешевле на старте и почти всегда дороже в итоге: сбой возвращается, простои копятся, а счёт за инфраструктуру растёт. Ниже разбираем, как устроена грамотная диагностика, какие причины стоят за типовыми сбоями и как мы строим работу так, чтобы проблема ушла насовсем.
Почему 502 и 504 — это не одно и то же
Эти два кода ошибки путают чаще всего, а разница между ними — ключ к диагностике. Ошибка 502 Bad Gateway означает, что nginx как точка входа обратился к php-fpm и получил некорректный ответ или не получил его вовсе. Бэкенд не отработал: пул воркеров исчерпан, процесс упал, оборвался сокет. Ошибка 504 Gateway Timeout означает другое — бэкенд жив, но не успел ответить за отведённое время. Запрос выполняется слишком долго, и nginx разрывает соединение по таймауту.
Различив эти два сценария, инженер сразу сужает круг поиска. При 502 мы идём в логи php-fpm и смотрим, почему воркеры не справляются: мало ли их, падают ли они, держит ли пул тяжёлый запрос. При 504 — ищем, что именно тормозит: медленный SQL-запрос, долгий внешний вызов, неоптимальную выгрузку. Подмена одного диагноза другим уводит работу в сторону, поэтому мы всегда начинаем с точной классификации симптома по логам, а не по догадкам.
Высокий CPU: где прячется виновник
Перегрузка процессора пугает тем, что выглядит беспричинной: нагрузка в потолке, а что её создаёт — неочевидно. На деле источник всегда конкретен. Это может быть цикл в коде, который крутится без выхода, агент Битрикса в бесконечном повторе, запрос без индекса, перебирающий миллионы строк, или наплыв ботов по тяжёлым страницам фильтрации. Мы снимаем профиль нагрузки и находим процесс-виновника поимённо, а не гасим симптом перезагрузкой, после которой всё повторяется через час.
Отдельно стоит история с памятью. Утечка — это когда процесс берёт память и не отдаёт, и потребление растёт, пока сервер не исчерпает ОЗУ и не уйдёт в swap. Работа через swap в десятки раз медленнее, поэтому сайт начинает жёстко тормозить, а иногда система перезагружается по OOM. Здесь мы ловим текущий процесс и пересчитываем лимиты пулов php-fpm и буферов MySQL под реальный объём памяти, чтобы система не выходила за её границы. Грамотный расчёт лимитов часто важнее, чем добавление гигабайтов.
MySQL как скрытая причина сбоев
Очень многие сбои, которые выглядят как проблема веб-сервера, на самом деле родом из базы данных. Замирания сайта на минуты — это почти всегда блокировки: долгая транзакция держит строки, а остальные запросы выстраиваются в очередь и ждут. Ошибки 504 на тяжёлых страницах — это медленные запросы, которые не укладываются в таймаут. Высокий CPU нередко создаёт запрос без индекса, читающий таблицу целиком при каждом обращении. Поэтому разбор медленного журнала запросов и анализ планов выполнения через EXPLAIN — обязательная часть диагностики, без которой картина будет неполной.
Если в ходе разбора выясняется, что узкое место именно в производительности базы и инфраструктуры, мы предлагаем системно заняться оптимизацией и ускорением BitrixVM: добавить недостающие индексы, настроить кэширование, пересчитать буферы. А когда сбои связаны не с разовой перегрузкой, а с тем, что один сервер физически не вытягивает поток, разумнее смотреть в сторону кластеризации и отказоустойчивости BitrixVM, чтобы нагрузка распределялась, а падение одного узла не роняло весь сайт.
Агенты и cron: тихий источник зависаний
Фоновые задачи Битрикса — частая и недооценённая причина перегрузок. По умолчанию агенты запускаются на хитах, то есть привязаны к посещениям сайта. Это значит, что тяжёлая фоновая задача может выполниться прямо во время запроса пользователя и затормозить страницу, а в пик такие задачи накладываются на живой трафик и плодят зависания. Перевод агентов на cron делает их выполнение предсказуемым: задачи идут по расписанию, независимо от посетителей, и не вешаются на обычные запросы.
Но просто переключить режим мало. Мы проверяем, не зависло ли какое-то задание, не копится ли очередь, не упираются ли тяжёлые задачи друг в друга по времени. Зависший агент способен держать процессор в потолке часами, и со стороны это выглядит как загадочная перегрузка без видимой причины. Разбор расписания, чистка очереди и разнос задач по времени снимают этот класс проблем целиком.
Аварийная стабилизация: первый час важнее всего
Когда сайт лежит и теряет заказы, у диагностики появляется жёсткий приоритет — сначала поднять сайт, потом разбираться. В первый час мы возвращаем сайт в рабочее состояние доступными средствами: корректируем лимиты пулов, перезапускаем зависшие службы, отсекаем паразитный трафик ботов, ставим быстрые заплатки на самые тяжёлые операции. Это не лечение, а остановка кровотечения — но именно она снижает потери от простоя, пока мы ищем корень. Калькулятор на этой странице помогает прикинуть, во сколько обходится каждый час простоя, и понять, насколько важна скорость реакции.
После стабилизации работа не заканчивается, а только начинается по-настоящему. Мы воспроизводим сбой под нагрузкой, снимаем профиль, доходим до корневой причины и устраняем именно её. Разница между нами и теми, кто просто перезагружает сервер, в том, что мы не считаем сайт починенным, пока не нашли и не убрали источник. Иначе сбой вернётся, и часто в худший момент.
Когда диагностика перерастает в постоянную поддержку
Разовая диагностика отлично решает конкретный инцидент, но если сбои повторяются, а выделенной команды по серверу у вас нет, разумнее перейти к постоянному наблюдению. Мы ставим мониторинг ключевых метрик и оповещения, реагируем на падения и ошибки 502 и 504 круглосуточно, регулярно разбираем нагрузку и заранее корректируем настройки, пока проблема не выросла. Такой формат удобно совмещается с комплексным управлением и оптимизацией BitrixVM, когда сервер ведут системно, а не от инцидента к инциденту.
Постоянный контроль меняет саму логику работы с сайтом. Вместо того чтобы реагировать на жалобы клиентов, что сайт не открывается, вы видите проблему в зародыше: метрика поползла вверх, пришло оповещение, инженер разобрался до того, как сбой стал заметен. Это превращает непредсказуемые падения в управляемый процесс и снимает с команды постоянный фоновый стресс ожидания, что вот-вот всё ляжет.
Возражения, которые мы слышим чаще всего
«Может, просто докупить ресурсов и не возиться с диагностикой». Иногда железа действительно мало, но чаще апгрейд лишь отодвигает проблему и повышает ежемесячный счёт. Цикл в коде или запрос без индекса сожрут любой объём ресурсов, поэтому сначала имеет смысл найти причину. Нередко после её устранения сервер работает с тройным запасом на прежнем железе, и апгрейд оказывается не нужен вовсе.
«У нас уже смотрел хостинг, сказали, что всё в порядке». Хостинг отвечает за работу инфраструктуры и обычно не разбирает код, запросы и логику Битрикса. Он видит, что сервер жив, и на этом останавливается, тогда как причина сбоя лежит выше — в приложении, запросах или фоновых задачах. Диагностика как раз и закрывает этот разрыв между железом и приложением.
«А вдруг вы что-то сломаете на нашем боевом сайте». На этапе поиска мы только читаем логи и метрики, ничего не меняя. Любые правки вносим осознанно и по согласованию, с резервной копией перед изменением, чтобы откат был возможен в любой момент. Боевой сайт для нас — повод действовать аккуратнее, а не риск, которым можно пренебречь.
Типичные сценарии, с которыми к нам приходят
Сценарий первый — интернет-магазин, который стабильно отдаёт 502 в часы вечернего пика. Днём всё работает, а с ростом трафика воркеры php-fpm заканчиваются, потому что пул рассчитан без запаса, а каждую страницу каталога тянет тяжёлый запрос без индекса. Лечение тут двойное: пересчитать число воркеров под объём памяти и убрать сам тяжёлый запрос, чтобы он не держал пул. После этого пик перестаёт быть проблемой, и магазин выдерживает в разы больший поток на том же сервере.
Сценарий второй — портал, у которого процессор стоит в потолке практически круглосуточно, а явной нагрузки от посетителей нет. Профиль почти всегда показывает фоновую задачу: агент, запущенный на хитах, попал в бесконечный повтор и жжёт ядро часами. Перевод агентов на cron, чистка очереди и разнос задач по времени снимают нагрузку, и сервер возвращается к нормальному потреблению. Со стороны это выглядит как чудо, хотя на деле — обычная работа с фоновыми заданиями Битрикса.
Сценарий третий — компания, у которой тяжёлые выгрузки и отчёты обрываются по 504, а по ночам сервер уходит в swap и перезагружается. Здесь сходятся сразу две причины: долгая операция не укладывается в таймаут, и параллельно течёт память. Мы выносим выгрузку в фоновое задание, чтобы она не висела в запросе, ловим утечку и пересчитываем лимиты под реальное ОЗУ. Результат — выгрузки отрабатывают спокойно, а ночные перезагрузки по нехватке памяти прекращаются.
Почему важна именно полнота разбора
Главная ловушка при борьбе со сбоями — остановиться на первом найденном объяснении. Нашли медленный запрос, поправили — и кажется, что дело сделано. Но сбой нередко держится на нескольких причинах сразу: тяжёлый запрос, неудачные лимиты пула и зависший агент могут накладываться друг на друга, и устранение одной из них даёт лишь частичное улучшение. Поэтому мы не закрываем инцидент, пока не убедились, что разобрали весь стек и сайт держит нагрузку с запасом, а не балансирует на грани.
Полнота разбора экономит и время, и деньги в перспективе. Поверхностная починка возвращает проблему через неделю, и каждый новый виток снова стоит простоев, нервов и денег. Глубокая диагностика дороже одного поверхностного вмешательства, но дешевле череды повторяющихся аварий. Именно поэтому мы методично доходим до корня, фиксируем причину в отчёте и закладываем профилактику, а не отделываемся быстрым гашением симптома, после которого всё повторяется.
Ещё один важный нюанс — взаимосвязь узлов стека. Перегрузка базы данных рано или поздно отзовётся ошибками 502 на веб-сервере, а нехватка памяти ударит и по php-fpm, и по MySQL одновременно. Поэтому смотреть на один узел в отрыве от остальных почти бесполезно: картина складывается только когда видны логи и метрики всей цепочки сразу. Мы держим в голове эту связность и проверяем, как изменение в одном месте отражается на соседних, чтобы устранение одной причины не породило новую в другом узле.
С чего начать
Начать проще всего с бесплатного экспресс-аудита. Дайте нам доступ к серверу, опишите, как и когда проявляется сбой, — и мы соберём логи, снимем первичные метрики и сформулируем гипотезу о причине. По итогам вы получите понятную картину: что происходит с сайтом, насколько это серьёзно и что нужно сделать, чтобы 502, 504 и перегрузка ушли. Если сайт лежит прямо сейчас, подключаемся срочно и в любое время суток. Обсудим ваш инцидент — и вернём сайту стабильность, а вам — спокойствие.
Частые вопросы о диагностике ошибок BitrixVM
Что вообще означает ошибка 502 Bad Gateway? +
Это ответ nginx о том, что он обратился к php-fpm как к бэкенду, но не получил корректного ответа. Проще говоря, точка входа работает, а исполнитель PHP — нет: пул исчерпан, воркер упал или оборвался сокет. Мы читаем логи nginx и php-fpm, находим, почему бэкенд не отвечает, и устраняем причину.
Чем 504 Gateway Timeout отличается от 502? +
При 502 бэкенд ответил некорректно или вовсе не ответил, а при 504 он просто не успел ответить за отведённое время. 504 — это про таймаут: запрос выполняется слишком долго и nginx разрывает соединение. Лечится не задиранием таймаутов, а ускорением запроса или выносом долгой операции в фон.
Почему 502 появляется только в часы пик? +
В пик растёт число одновременных запросов, и если пул php-fpm рассчитан неверно, воркеры заканчиваются. Новым запросам не достаётся исполнителя, nginx отдаёт 502. Мы пересчитываем число воркеров под объём памяти и убираем тяжёлые запросы, которые надолго занимают пул.
Можно ли просто увеличить таймауты и убрать 504? +
Это маскировка, а не лечение. Задрав таймаут, вы лишь дольше держите висящий запрос, занимая воркеры и провоцируя новые сбои. Правильно — найти, почему операция тормозит, и ускорить её или вынести в фоновое задание. Таймауты при этом остаются разумными.
Сайт лежит прямо сейчас с 502 — как быстро поднимете? +
Обычно первая гипотеза появляется за 30–60 минут после получения доступов, а вернуть сайт в рабочее состояние удаётся в течение 1–3 часов. Сначала аварийно стабилизируем, чтобы сайт отвечал, и только затем спокойно ищем и убираем корневую причину.
Почему CPU держится на 100 процентах? +
У высокой нагрузки всегда есть конкретный источник: цикл в коде, тяжёлый агент, запрос без индекса, наплыв ботов или парсеров. Мы снимаем профиль нагрузки и находим процесс-виновник, а не глушим симптом перезагрузкой, после которой всё повторяется.
Что такое утечка памяти простыми словами? +
Это когда процесс берёт память и не отдаёт её обратно, и со временем потребление только растёт. В итоге сервер исчерпывает ОЗУ, уходит в swap и тормозит, а иногда перезагружается по OOM. Мы находим, какой процесс течёт, и убираем причину или ограничиваем его аккуратными лимитами.
Что значит уход в swap и чем он опасен? +
Swap — это часть диска, которую система использует как медленную замену оперативной памяти, когда ОЗУ кончается. Работать через диск в десятки раз медленнее, поэтому при уходе в swap сайт начинает жёстко тормозить. Мы пересчитываем лимиты под реальный объём памяти, чтобы система в swap не уходила.
Поможет ли просто докупить процессор и память? +
Иногда железо действительно мало, но чаще апгрейд лишь отодвигает проблему: цикл в коде или запрос без индекса сожрут любой ресурс. Сначала находим причину перегрузки и убираем её — нередко после этого апгрейд вообще не нужен, и вы экономите на инфраструктуре.
Как понять, что нагрузку создают боты? +
По логам access.log видно всплески запросов с одних адресов или агентов, часто по тяжёлым страницам фильтрации и поиска. Мы выделяем такой трафик, отделяем полезных поисковых роботов от паразитных и настраиваем ограничения, чтобы боты не валили сервер.
Что такое медленный запрос и slow query log? +
Медленный запрос — это SQL, который выполняется дольше заданного порога и тормозит страницу. Slow query log — журнал MySQL, куда такие запросы попадают вместе со временем выполнения. Мы включаем его, собираем худшие запросы и оптимизируем их в первую очередь.
Зачем нужны индексы и при чём тут перегрузка? +
Индекс позволяет базе находить нужные строки быстро, без перебора всей таблицы. Запрос без индекса на большой таблице читает её целиком, жжёт CPU и диск и тормозит весь сайт. Мы находим такие запросы через EXPLAIN и добавляем недостающие индексы.
Что такое блокировки в базе и почему сайт замирает? +
Когда одна долгая транзакция держит строки или таблицу, другие запросы вынуждены ждать её завершения. Снаружи это выглядит как замирание сайта на минуты с последующим отвисанием. Мы находим блокирующий запрос, ускоряем его и разводим конкуренцию за одни данные.
Не сломает ли добавление индекса работу сайта? +
Нет, если делать это аккуратно. Индексы добавляем по результатам анализа реальных запросов, на копии или в окно низкой нагрузки, и проверяем, что они дают эффект, а не лишнюю нагрузку на запись. Лишние и дублирующие индексы при этом убираем.
Чем агенты Битрикса отличаются от cron? +
Агенты — это фоновые задачи Битрикса, которые по умолчанию запускаются на хитах, то есть зависят от посещений сайта. Cron — системный планировщик, который запускает задачи по расписанию независимо от трафика. Перевод агентов на cron делает фоновые задачи предсказуемыми и снимает нагрузку с обычных запросов.
Почему агенты на хитах могут перегружать сайт? +
Когда агенты привязаны к хитам, тяжёлая фоновая задача выполняется прямо во время запроса пользователя и тормозит страницу. В пик это особенно заметно. Мы переводим агенты на cron, чтобы фоновые задачи не вешались на живой трафик и не плодили зависания.
Что делать, если задания в очереди копятся? +
Накопление очереди обычно означает, что задачи отрабатывают медленнее, чем приходят, или какое-то задание зависло и держит остальные. Мы находим зависшую задачу, чистим очередь и разносим тяжёлые задания по времени, чтобы они не упирались друг в друга.
Как понять, что cron вообще работает? +
Проверяем расписание cron, права и логи выполнения, а также метки последнего запуска агентов в Битриксе. Если задачи не отрабатывают вовремя, видно сразу. Мы чиним расписание и при необходимости настраиваем оповещения о том, что фоновые задания перестали выполняться.
Какие доступы нужны для диагностики? +
Обычно нужен доступ к серверу по SSH и к панели BitrixVM, иногда к административной части сайта и базе данных для разбора запросов. Чем полнее доступ, тем быстрее находим причину. Все доступы используем аккуратно и по завершении просим их сменить.
Вы меняете код сайта во время диагностики? +
На этапе поиска причины — нет, мы только читаем логи и метрики. Изменения вносим осознанно и по согласованию: правка настроек пула, добавление индекса, вынос операции в фон. Перед правкой делаем резервную копию, чтобы откат был возможен в любой момент.
Что я получу по итогу работ? +
Работающий стабильный сайт и отчёт, в котором понятно описана причина сбоя, что именно сделано и что стоит изменить, чтобы проблема не вернулась. При необходимости настраиваем мониторинг и оповещения, чтобы вы узнавали о проблемах раньше клиентов.
А если причина не найдётся? +
Так практически не бывает: у 502, 504 и перегрузки всегда есть конкретный источник в стеке. Мы идём по цепочке nginx, php-fpm и MySQL, пока не сведём симптомы к одной причине. Если проблема плавающая, ставим расширенный мониторинг и ловим её в момент проявления.
Можно ли передать вам поддержку после диагностики? +
Да. После устранения причины часто берём сервер на мониторинг и сопровождение: реагируем на инциденты, следим за нагрузкой и заранее корректируем настройки. Это удобно, если своей выделенной команды по серверу у вас нет.
Что такое мониторинг сервера простыми словами? +
Это автоматическое наблюдение за ключевыми метриками: нагрузкой на процессор, памятью, числом ошибок, временем ответа сайта. Система постоянно снимает показания и, когда они выходят за норму, шлёт оповещение. Так проблему видно в зародыше, а не по жалобам клиентов, что сайт не открывается.
Какие оповещения вы настраиваете? +
Настраиваем оповещения о всплесках ошибок 502 и 504, о выходе нагрузки CPU и памяти за порог, об уходе в swap, о падении служб nginx и php-fpm, о том, что фоновые задания перестали отрабатывать. Каналы любые: почта, мессенджер, дежурная система. Пороги подбираем под ваш профиль нагрузки.
Как часто стоит проверять сервер, если сбоев нет? +
Когда стоит мониторинг, отдельные проверки не нужны — система следит непрерывно. Но раз в месяц полезно разбирать накопленную статистику нагрузки и медленных запросов: так видно тенденции и можно поправить настройки до того, как они приведут к сбою. Этот регулярный разбор входит в формат сопровождения.
Чем профилактика выгоднее разовой починки? +
Разовая починка убирает конкретный инцидент, но не страхует от следующего. Профилактика и мониторинг ловят проблему до того, как сайт ляжет, и экономят на простоях и авральных выездах. По нашему опыту, регулярный разбор нагрузки обходится заметно дешевле, чем потери от внезапных падений в пик продаж.
Результат в измеримых цифрах
Ориентиры по нашим инцидентам на BitrixVM. Точную картину по вашему серверу покажем на бесплатном экспресс-аудите.
Сайт сыпет 502, 504 или грузит сервер?
Опишите симптомы и дайте доступ к серверу — соберём логи, найдём причину и вернём сайту стабильность. Если сайт лежит прямо сейчас, подключаемся срочно.
- Ответим в течение рабочего дня
- Бесплатный аудит процессов и расчёт
- NDA и фиксированная смета