2.0 503 Service Unavailable

В предыдущих заметках были рассмотрены такие темы: развертывание IP телефонии на базе Asterisk, основные команды для работы с Asterisk, способы диагностики работы IP телефонии (когда не слышно абонента), способ обновления сервера телефонии и  способы остановки/перезагрузки службы. Сейчас остановимся на кодах ответов. Диагностический режим (отладка) запускается так:

sip set debug on — общая диагностика

sip set debug  peer 100 — для конкретного номера

sip set debug off — отключить режим отладки

rtp set debug on — аналогично

SIP/2.0 100 Trying — Запрос обрабатывается, например, сервер обращается к базам данных, но местоположение вызываемого пользователя в настоящий момент не определено.

SIP/2.0 180 Ringing — Местоположение вызываемого пользователя определено. Ему дается сигнал о входящем вызове.

SIP/2.0 181 Call Is Being Forwarded — Прокси-сервер переадресует вызов к другому пользователю.

SIP/2.0 182 Queued — Вызываемый пользователь временно не доступен, но входящий вызов поставлен в очередь. Когда вызываемый пользователь станет доступным, он передаст финальный ответ.

SIP/2.0 301 Moved Permanently — Пользователь изменил свое местоположение, его новый адрес указан в поле Contact.

SIP/2.0 302 Moved Temporarily — Пользователь временно изменил свое местоположение (промежуток времени может быть указан в поле Expires), его новый адрес указан в поле Contact.

SIP/2.0 305 Use Proxy — Вызываемая сторона может принять входящий вызов только в том случае, когда он проходит через прокси-сервер. Вызывающей стороне рекомендуется обратиться к прокси-серверу, адрес которого указан в поле Contact. Ответ передается только терминальным оборудованием (UAS).

SIP/2.0 380 Alternative Service — Вызов не достиг адресата, но существует альтернативный вариант обслуживания, который указан в теле ответа. Например, вызов может быть переадресован к речевому почтовому ящику.

SIP/2.0 400 Bad Bequest — Запрос не понят из-за наличия в нем синтаксических ошибок.

SIP/2.0 401 Unauthorised — Запрос требует проведения процедуры аутентификации пользователя. Существуют разные варианты аутентификации, и в ответе может быть указано, какой из них использовать в данном случае.

SIP/2.0 402 Payment Required — Требуется предварительная оплата услуг.

SIP/2.0 403 Forbidden — Запрос не будет обслуживаться сервером и не должен передаваться повторно.

SIP/2.0 404 Not Found — Сервер не обнаружил вызываемого пользователя в домене, указанном в поле Request-URI.

SIP/2.0 405 Method Not Allowed — Не разрешается передавать запрос этого типа на адрес, указанный в поле Request-URI. В поле Allow ответа указываются разрешенные типы запросов

SIP/2.0 406 Not Acceptable — Ответы, генерируемые вызываемой стороной, не будут поняты вызывающей стороной.

SIP/2.0 407 Proxy Authentication Required — Клиент должен подтвердить свое право доступа к прокси-серверу.

SIP/2.0 408 Request Timeout — Сервер не может передать ответ, например, указать местоположение вызываемого пользователя, в течение промежутка времени, специфицированного в поле Expires запроса. Вызывающий пользователь может повторно передать запрос через некоторое время.

SIP/2.0 409 Conflict — Обработка запроса REGISTER не может быть завершена из-за конфликта между действием, определенным в параметре action запроса, и текущим состоянием ресурсов.

SIP/2.0 410 Gone — Сервер больше не имеет доступа к запрашиваемому ресурсу и не знает, куда переадресовать запрос.

SIP/2.0 411 Length Required — Требуется указать длину тела сообщения в поле Content-Length.

SIP/2.0 413 Request Entity Too Large — Размер запроса слишком велик для обработки.

SIP/2.0 414 Request-URI Too Large — Адрес, указанный в поле Request-URI, оказался слишком большим, поэтому его интерпретация невозможна.

SIP/2.0 415 Unsupported Media Type — Запрос содержит не поддерживаемый формат тела сообщения.

SIP/2.0 420 Bad Extension — Сервер не понял расширение протокола, специфицированное в поле Require.

SIP/2.0 480 Temporarily not available — Вызываемый пользователь временно недоступен.

SIP/2.0 481 Call Beg/Transaction Does Not Exist — Посылается в ответ на получение запроса ВYЕ, не относящегося к текущим соединениям, или запроса CANCEL, не относящегося к текущим запросам.

SIP/2.0 482 Loop Detected — Сервер обнаружил, что принятый им запрос передается по замкнутому маршруту (в поле Via уже имеется адрес этого сервера).

SIP/2.0 483 Too Many Hops — Сервер обнаружил в поле Via, что принятый им запрос прошел через большее количество прокси-сервером, чем разрешено в поле Max-Forwards.

SIP/2.0 484 Address Incomplete — Сервер принял запрос с неполным адресом в поле То или Request-URI. Требуется дополнительная адресная информация.

SIP/2.0 485 Ambiguous — Адрес вызываемого пользователя неоднозначен. В заголовке Contact ответа может содержаться список адресов, по которым этот запрос можно передать.

SIP/2.0 486 Busy Here — Вызываемый пользователь в настоящий момент не может принять входящий вызов по данному адресу. Ответ не исключает возможности связаться с пользователем по другому адресу или, к примеру, оставить сообщение в речевом почтовом ящике.

SIP/2.0 500 Internal Server Error — Cервер не имеет возможности обслужить запрос из-за внутренней ошибки. Клиент может попытаться повторно послать запрос через некоторое время.

SIP/2.0 501 Not Implemented — В сервере не реализованы функции, необходимые для обслуживания этого запроса. Ответ передается, например в том случае, когда сервер не может распознать тип запроса.

SIP/2.0 502 Bad Gateway — Сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос.

SIP/2.0 503 Service Unavailable — Сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания.

SIP/2.0 504 Gateway Timeout — Сервер, функционирующий в качестве шлюза или прокси-сервера, в течение установленного интервала времени не получил ответ от сервера (например, от сервера определения местоположения), к которому он обратился для завершения обработки запроса.

SIP/2.0 505 SIP Version not supported — Сервер не поддерживает данную версию протокола SIP.

SIP/2.0 600 Busy Everywhere — Вызываемый пользователь занят и не желает принимать вызов в данный момент. Ответ может указывать подходящее для вызова время

SIP/2.0 603 Decline — Вызываемый пользователь не может или не желает принимать входящие вызовы. В ответе может быть указано подходящее для вызова время.

SIP/2.0 604 Does not exist anywhere — Вызываемого пользователя не существует.

SIP/2.0 606 Not Acceptable — Вызываемый пользователь не может принять входящий вызов из-за того, что вид информации, указанный в описании сеанса связи в формате SDP, полоса пропускания и т.д. неприемлемы.

Коды ответов сервера (коды состояния запроса) в протоколе SIP, согласно RFC2543

Код ответа от сервера (код состояния запроса) состоит из трех цифр и показывает информацию об обработке запроса сервером или оконечным устройством. Рядом с любым кодом, передается поясняющая фраза, краткое текстовое описание, кода ответа. Код ответа необходим для серверов и оконечных устройств, при этом, они не смотрят поясняющие фразы. А поясняющие фразы необходимы лишь для конечных пользователей.

Первая цифра кода состояния запроса определяет класс ответа. Последние две цифры не имеют определенной роли в классификации. Протокол SIP/2.0 определяет 6 значение для первой цифры:

• 1xx: Информационные ответы (Informational) – запрос получен, запрос обрабатывается;
• 2xx: Успех выполнения запроса (Success) – запрос был получен, понят, принят в обработку;
• 3xx: Переадресация (Redirection) – для завершения запроса необходимо, выполнить следующие действия;
• 4xx: Ошибка Клиента (Client Error) – запрос имеет некорректный синтаксис(информацию) или запрос не может быть выполнен на данном сервере;
• 5xx: Ошибка Сервера (Server Error) – сервер не в состоянии выполнить корректный запрос;
• 6xx: Глобальная Ошибка (Global Failure) – запрос не может быть выполнен на любом сервере.

Далее рассмотрим часто встречающиеся коды состояния запросов и поясняющие фразы к ним, используемые в SIP/2.0. Поясняющие фразы- это рекомендация, пользователи могут изменить их, без воздействия на протокол SIP/2.0. Обратите внимание, что много кодов ответов взято из протокола HTTP/1.1. В SIP/2.0 добавлены коды в диапазоне с x80, так же, в отличие от HTTP/1.1, добавлен новый класс кодов 6xx.

Коды ответов SIP являются расширяемыми. SIP приложению не требуется понимать смысл всех зарегистрированных кодов ответа, хотя такое понимание желательно. Тем не менее, приложения ДОЛЖНЫ понимать класс любого кода ответа, как это указано в первой цифре, и обрабатывать любой нераспознанный ответ как эквивалент кода ответа x00 этого класса. Например, если клиент получает незарегистрированный код ответа 431, он может смело предположить, что было что-то не так в его запросе, и должен обработать ответ, как если бы был получен код 400 (Bad Request). В таких случаях агентам пользователя СЛЕДУЕТ представить пользователю тело сообщения, возвращаемого с ответом, так как в теле сообщения, вероятно, включена информация, которая поясняет нестандартный ответ.

• “100” ; Trying – запрос обрабатывается
• “180” ; Ringing – вызываемы пользователь определен. Идет сигнал о входящем вызове
• “181” ; Call Is Being Forwarded – вызов переадресовывается к другому пользователю
• “182” ; Queued – вызываемый абонент недоступен, вызов поставлен в очередь
• “183” ; Session Progress – данный ответ используется для передачи описания медианных SDP

Успех выполнения запроса:

• “200” ; OK – успешное выполнение запроса
• “202” ; Accepted – запрос принят в обработку

• “300” ; Multiple Choices – в ответе указаны несколько SIP адресов, где можно найти вызываемого пользователя
• “301” ; Moved Permanently – вызываемый абонент больше не находится по адресу, указанному в запросе
• “302” ; Moved Temporarily – вызываемый абонент временно не находится по адресу, указанному в запросе
• “305” ; Use Proxy – входящий вызов должен пройти через прокси-сервер
• “380” ; Alternative Service – запрошенная услуга недоступна, но есть альтернативные варианты

• “500” ; Internal Server Error – внутренняя ошибка сервера
• “501” ; Not Implemented – сервер не поддерживает функциональные возможности, необходимые для выполнения запроса.
• “502” ; Bad Gateway – сервер, действуя в качестве шлюза или прокси-сервера, получил недопустимый ответ от подчиненного сервера, к которому он обратился для выполнения запроса.
• “503” ; Service Unavailable – сервер в настоящее время не в состоянии обработать запрос из-за временной перегрузки или технического обслуживания сервера.
• “504” ; Gateway Time-out – сервер, действуя в качестве шлюза, не получил своевременного ответа от сервера (например, сервер определения местоположения) к которому он обратился для выполнения запроса.
• “505” ; SIP Version not supported – сервер не поддерживает или отказывается поддерживать, версию протокола SIP, который был использован в сообщении запроса

• “600” ; Busy Everywhere – вызов дошел до вызываемого абонента, но вызываемый абонент занят и не желает принять вызов в настоящее время.
• “603” ; Decline – вызов дошел до вызываемого абонента, но вызываемый абонент занят и не желает принять вызов, не указывая причину отказа.
• “604” ; Does not exist anywhere – сервер имеет точную информацию о том, что пользователя, указанного в поле To не существует нигде. Поиск пользователя в другом месте не даст никаких результатов.
• “606” ; Not Acceptable – сервер установил соединение с абонентом, но отдельные параметры, такие как тип запрашиваемой информации, полоса пропускания, вид адресации не доступны

SIP/2.0 20 – Абонент отсутствует (Subscriber absent)
SIP/2.0 21 – Вызов отклонен (Call rejected)
SIP/2.0 28 – Некорректный формат номера (неполный адрес) (Invalid number format (address incomplete))
SIP/2.0 31 – Нормальное разъединение, не специфицировано (Normal, unspecified)
SIP/2.0 41 – Кратковременный сбой (Temporary failure)

1xx = информационные ответы
SIP/2.0 100 Trying — запрос обрабатывается

SIP/2.0 102 – Восстановление по выдержке времени (Recovery on timer expiry)
SIP/2.0 111 – Ошибка протокола, не специфицировано (Protocol error, unspecified)
SIP/2.0 127 – Взаимодействие, не специфицировано (Interworking, unspecified)

SIP/2.0 180 Ringing — местоположение вызываемого пользователя определено. Выдан сигнал о входящем вызове
SIP/2.0 181 Call is Being Forwarded — прокси,сервер переадресует вызов к другому пользователю
SIP/2.0 182 Call is Queued — вызываемый абонент временно не доступен, вызов поставлен в очередь
SIP/2.0 183 Session Progress — используется для того, чтобы заранее получить описание сеанса информационного обмена от шлюзов на пути к вызываемому пользователю

2xx = ответы о завершении запроса
SIP/2.0 200 OK — успешное завершение
SIP/2.0 202 Accepted — запрос принят для обработки Используется для справки о состоянии обработки

5xx = ошибки сервера
SIP/2.0 500 Internal Server Error — внутренняя ошибка сервера
SIP/2.0 500 DB Timeout — нет ответа от базы данных
SIP/2.0 500 Database Error — то же самое, но в другой момент
SIP/2.0 500 Wrong DB Response — неправильный ответ базы данных, редкая ошибка
SIP/2.0 500 Undefined Reason — неопределенная причина
SIP/2.0 500 account has been moved to a remote system — аккаунт перенесен в удаленную систему (дословно)
SIP/2.0 501 Method Not Supported Here — в сервере не реализованы какие-либо функции, необходимые для обслуживания запроса: Метод запроса SIP не поддерживается
SIP/2.0 502 Bad Gateway — сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос
SIP/2.0 503 Service Unavailable — сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания
SIP/2.0 504 Server time-out — сервер не получил ответа в течение установленного промежутка времени от сервера, к которому он обратился для завершения вызова
SIP/2.0 505 SIP Version not supported — версия не поддерживается: Сервер не поддерживает эту версию протокола SIP
SIP/2.0 513 Message too big — сервер не в состоянии обработать запрос из-за большой длины сообщения

6xx = глобальная ошибка
SIP/2.0 600 Busy everywhere — вызываемый пользователь занят и не желает принимать вызов в данный момент
SIP/2.0 603 Decline — вызываемый пользователь не желает принимать входящие вызовы, не указывая причину отказа
SIP/2.0 604 Does Not Exist Anywhere — вызываемого пользователя не существует
SIP/2.0 606 Not Acceptable — соединение с сервером было установлено, но отдельные параметры, такие как тип запрашиваемой информации, полоса пропускания, вид адресации не доступны

Сообщение на странице сайта 503 Service Temporary Unavailable – «сервис временно недоступен» может появляться из-за технических сбоев как на сервере, так и на компьютере пользователя. Последнее случается реже.

Наиболее распространенная причина проблемы – перегруженность сервера запросами. Он не успевает их обрабатывать, и всем клиентам в очереди выдает ошибку с кодом 503. Такая картина может наблюдаться, например, во время DDoS-атаки.

Обнаружив ошибку 503, лучше всего ничего не делать. Подождите 3-5 минут. Очередь запросов в большинстве случаев – временное явление, и вскоре сайт станет доступен. Чего точно не нужно делать,– это постоянно перезагружать страницу с ошибкой. Так вы только увеличиваете число запросов в очереди.

Как устранить ошибку 503 на стороне пользователя?

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

• Проверьте доступность сайта с помощью специальных сервисов. Например, https://2ip.ru/site-availability/. Если проверка показала, что из вашей страны сайт доступен – исправить ошибку 503 нужно на вашей стороне.
• Перезагрузите страницу с помощью клавиш Ctrl F5 (в браузерах macOS используйте сочетание Cmd + R или Cmd + Alt + E в Safari.
• Попробуйте открыть страницу в другом браузере, на другом компьютере. Так вы определите уровень возникновения проблемы – у вас в браузере или у вас на компьютере – и будете действовать исходя из этого. Если страница везде выдает Error 503 – то причина все же на самом сайте.
• Закройте браузер и откройте заново. Иногда это помогает сбросить неправильные настройки сессий.
• ​Почистите кэш и cookies браузера. Большое количество сохраненной старой информации может мешать браузеру обрабатывать соединение правильно.
• Откройте страницу в режиме инкогнито или просто отключите все работающие в браузере дополнения и расширения – возможно, какое-то некорректно работает и приводит к появлению ошибки 503.
• Это самый простой и быстрый способ исправить сбой в работе ПО.
• Если не помогла перезагрузка компьютера – перезагрузите также роутер.

Что делать, если ошибка 503 – на стороне веб-ресурса?

Прежде всего, администратору сайта для ошибки сервера с кодом 503 желательно прописать параметр Retry After. Он будет показывать клиенту, через какое время тот может попробовать повторно соединится с сервером. Это уменьшит число бесконечных перезагрузок страниц и поможет снизить и без того чрезмерную в данный момент нагрузку на сервер.

Распространенные причины возникновения ошибки 503 и их исправление

В основном, ошибка 503 Service Unavailable вызывается следующими категориями причин:

• Слишком много запросов к веб-серверу.
• Много медленных запросов к MySQL.
• На сайте много устаревших, нерабочих, конфликтующих плагинов и модулей CMS.
• Неоптимизированная работа скриптов.

Также ошибка 503 может быть вызвана тем, что ваш сайт «перерос» возможности вашего хостингового тарифного плана. В этом случае стоит подумать над тем, чтобы выбрать более производительный тариф виртуального хостинга или же VPS/VDS, выделенный сервер.

Как исправить причины ошибки

Уменьшаем число запросов к веб-серверу

Устранение ошибки 503 прежде всего подразумевает снижение нагрузки на веб-сервер. Для этого:

• установите антилич-систему. Она не позволит скачивать ваши файлы и картинки по ссылке на сторонних ресурсах – ведь так увеличивается нагрузка на ваш сервер и может возникать ошибка 503;
• ограничьте деятельность различных ботов и роботов. При сканировании они создают множество запросов;
• проверьте, чтобы на сайте было как можно меньше ссылок на внешние ресурсы. Оставьте только необходимые и важные. Например, иногда можно встретить большое количество информеров на странице. Каждый информер — ссылка на другой сайт, соединение с чужим сервером. Это создает дополнительную нагрузку на сервер;
• по возможности объедините обращения к большому числу мелких файлов (скриптов, картинок, таблиц стилей), чтобы они обрабатывались одним запросом, а не множеством.

Оптимизируем работу с MySQL

• Включите кеширование – так время обработки запроса существенно уменьшится.
• Объединяйте запросы к БД (базе данных), чтобы один запрос обрабатывал сразу множество строк или столбцов, а не по одному.
• Используйте индексирование по столбцам, которые часто используются в выборках.
• Старайтесь не вкладывать один запрос в другой, так как в этом случае MySQL часто не может использовать индексы и будет долго возвращать результат.

Исправляем проблемы с CMS

Ошибка 503 Service Unavailable может быть вызвана некорректно работающими или «тяжелыми» компонентами движка вашего сайта. Чтобы выявить это, отключайте последовательно плагины или модули. Так вы найдете компонент, после выключения которого все начнет нормально работать. Оптимизируйте его или замените на более современный и быстрый.

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

Оптимизируем работу скриптов

• В скриптах поставьте локальные ссылки вместо глобальных. В глобальных указывается полный URL вместе с http, https. Они обрабатываются как отдельные запросы к внешнему ресурсу, и это гораздо большая нагрузка, чем при использовании ссылок локального вида.
• Не передавайте файлы большого размера с помощью скриптов. Во-первых, такая передача задействует рабочие процессы сервера, нагружает его. Во-вторых, она может давать сбои, так как работа скрипта ограничена по времени,и процесс зависает.
• Выполнение «тяжелых», масштабных скриптов и операций (почтовой рассылки, например) запланируйте на то время, когда на сайте меньше всего посетителей.

Что можно сделать для предотвращения проблемы?

В заключение дадим несколько советов – как предотвратить возникновение ошибки 503 Service Unavailable:

• При выборе тарифа хостинга не ориентируйтесь на среднюю нагрузки вашего сайта. Закладывайте небольшой запас мощностей, чтобы в часы пик ресурсов сервера хватало на обработку запросов.
• Установите защиту от DDoS-атак.
• Обновляйте плагины, темы и модули CMS, отключайте то, что не используете.
• Регулярно анализируйте работу компонентов сайта: сервера, базы MySQL, скриптов – и вовремя оптимизируйте их, не доводя ситуацию до критической.
• Ограничьте сканирование сайта ботами и User-агентами. Оставьте только то, что необходимо, например, боты поисковых систем, остальные заблокируйте. Обычно хостер сам блокирует большинство ненужных User-агентов, но вы можете добавить и свои кастомные настройки.

Начало

Хостинг предоставляет пользователям типичный стек Linux + Apache + Mysql + PHP и оболочку для управления. В нашем случае это ISP Manager 5 business на базе Centos 7 с конвертацией в CloudLinux. Со стороны административной части, CloudLinux предоставляет инструменты для управления лимитами, а так же PHP-селектор с различными режимами работы (CGI, FastCGI, LSAPI).

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

Коды ответа, начинающиеся с 50х, относятся к проблемам на стороне сервера. Это могут быть проблемы как самого сайта, так и веб-сервера, который их обслуживает.

Типичные ситуации, при которых мы получаем следующие ошибки:

• 500 Internal Server Error — довольно часто связана либо с синтаксическими ошибками в коде сайта, либо с отсутствующими библиотеками / не поддерживаемой версией PHP. Так же могут быть проблемы с подключением к базе данных сайта или неверными правами на файлы / каталоги
• 502 Bad Gateway — например, если Nginx ссылается на неправильный порт веб-сервера Apache или процесс Apache по какой-то причине перестал работать
• 504 Gateway Timeout — ответ от Apache не был получен в течение заданного в конфигурации веб-сервера времени
• 508 Resource limit is reached — превышен лимит, выделяемых пользователю ресурсов

В данном списке приведены лишь некоторые, наиболее распространённые случаи. Также стоит отметить, что при превышении лимитов пользователь может получить как 500, так и 503 ошибку.

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

Касаемо 503 ошибки в нашем случае, в логах мы видели запись:

[lsapi:error] [pid 49817] [client x.x.x.x:6801] [host XXX.XX] Error on sending request(GET /index.php HTTP/1.0); uri(/index.php) content-length(0): ReceiveAckHdr: nothing to read from backend (LVE ID 8514), check docs.cloudlinux.com/mod_lsapi_troubleshooting.html

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

Первичная диагностика

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

Так же мы изучили рекомендации CloudLinux, по приведённой в журналах ошибок ссылке.
Изменение каких-либо параметров результата не принесло.

Сайт использовал базу данных на сервере Mysql 5.7, который работает на этом же сервере в контейнере Docker. В логах контейнера присутствовали сообщения:

[Note] Aborted connection 555 to db: 'dbname' user: 'username' host: 'x.x.x.x' (Got an error reading communication packets)

Как раз, среди этих сообщений были сообщения о прерванном подключении исследуемого сайта. Это дало предположение, о том, что подключение к СУБД выполняется некорректно. Для проверки мы развернули копию сайта на тестовом домене, сконвертировали базу данных сайта под нативную в Centos 7 версию СУБД 5.5.65-MariaDB. На тестовом сайте выполнили несколько сотен запросов с помощью утилиты curl. Ошибку воспроизвести не удалось. Но этот результат был предварительным и после конвертации БД на рабочем сайте проблема так и осталась.

Таким образом, проблема некорректного подключения к СУБД была исключена.

Следующим предположением было проверить — нет ли проблем с самим сайтом. Для этого подняли отдельный виртуальный сервер, на нём подняли максимально схожее окружение. Единственное существенное отличие — отсутствие CloudLinux. На тестовом сервере проблему воспроизвести не удалось. Итак, мы определили, что в коде сайта всё в порядке. Тем не менее, пробовали так же отключать плагины WordPress, но проблема так же сохранялась.

В результате, пришли к тому, что проблема на нашем хостинге.

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

/var/www/httpd-logs# grep -Rl "ReceiveAckHdr: nothing to read from backend" ./ | wc -l
99

В ходе тестирования обнаружили, что только что установленная чистая CMS WordPress также периодически выдаёт ошибку 503.

Примерно за 2 месяца до этого мы проводили работы по модернизации сервера, в частности изменили режим работы Apache с Worker на Prefork, с целью получить возможность использовать PHP в режиме LSAPI, вместо медленного CGI. Было предположение, о том, что это могло повлиять, либо требуются какие-то дополнительные настройки Apache, но вернуть обратно режим Worker мы уже не могли. В ходе изменения режима работы Apache выполняется изменение всех конфигов сайтов, процесс не быстрый и не всё могло пройти гладко.

Корректировка настроек Apache так же не дала желаемого результата.

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

На данном этапе мы собрали имеющуюся информацию и результаты проведённых работ. С ними обратились в поддержку CloudLinux.

Детальная диагностика

В течение нескольких дней сотрудники поддержки CloudLinux вникали в проблему. В основном рекомендации были относительно установленных лимитов пользователей. Этот вопрос мы так же проверяли. При отключенных лимитах (Опция CageFS для пользователя) и с включенными лимитами в режиме PHP как модуль Apache проблема не наблюдалась. Исходя из этого, было сделано предположение, что каким-то образом оказывает влияние CloudLinux. В итоге, к концу недели запрос был эскалирован на 3-ий уровень поддержки, но решения пока не было.

Попутно изучали документацию Apache по режимам работы CGI и LSAPI, подняли второй экземпляр Apache на сервере хостинга на другом порту с тестовым сайтом, исключили влияние Nginx, отправляя запросы напрямую к Apache и получая те же коды ошибок.

Сдвинуться с мёртвой точки помогла документация LSAPI, как раз по диагностике 503 ошибки:
www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:php:503-errors
В секции Advanced Troubleshooting предлагается выполнять трассировку найденных в системе процессов:

while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep $SCRIPTNAME | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid; fi ; done

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

При просмотре файлов трассировок, мы видим в некоторых одинаковые строки:

cat trace.* | tail
...
47307 21:33:04.137893 --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=42053, si_uid=0} ---
47307 21:33:04.140728 +++ killed by SIGHUP +++
...

Если взглянуть на описание структуры сигналов, отправляемых процессами, то увидим, что

pid_t    si_pid;       /* Sending process ID */

Указывает на идентификатор процесса, отправившего сигнал.

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

tail -f /var/www/httpd-logs/sitename.error.log

while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep "sitename" | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid -o /tmp/strace/trace.$mypid; fi ; done

while true; do if mypid=`cat /tmp/strace/trace.* | grep si_pid | cut -d '{' -f 2 | cut -d'=' -f 4 | cut -d',' -f 1`; then ps -aux | grep $mypid; fi; done;

seq 1 10000 | xargs -i sh -c "curl -I http://sitename/"

Ждём пока в консоли 1 появятся сообщения, при этом в консоли 4 видим статус запроса с кодом ответа 503, прерываем выполнение в консоли 4.

В итоге, получили название процесса /opt/alt/python37/bin/python3.7 -sbb /usr/sbin/cagefsctl --rebuild-alt-php-ini

Данный процесс выполнялся в системе с периодичностью раз в минуту.

Делаем трассировку нескольких процессов cagefsctl, чтобы отследить хотя бы один от начала до конца:

for i in `seq 1 100`; do strace -p $(ps ax | grep cagefsctl | grep rebuild-alt-php-ini | grep -v grep | awk '{print $1}') -o /tmp/strace/cagefsctl.trace.$(date +%s); done;

Далее изучаем что он делал, например:

cat /tmp/strace/cagefsctl.trace.1593197892 | grep SIGHUP

Так же были получены идентификаторы процессов, которые были завершены сигналом SIGHUP. Завершённые процессы были процессами PHP, выполняющимися в данный момент.

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

Позже получили ответ, что работа команды /usr/sbin/cagefsctl --rebuild-alt-php-ini выполняется корректно, единственный нюанс в том, что команда выполняется слишком часто. Обычно вызывается при системном обновлении или изменении параметров PHP.

Единственная зацепка в данном случае осталась — проверить, кто является родительским процессом cagefsctl.

Результат не заставил себя долго ждать и какого же было наше удивление — родительским процессом для cagefsctl являлся процесс ispmgrnode. Это было немного странно, потому что уровень журналирования для ISP Manager был задан максимальным и в ispmgr.log не увидели вызов cagefsctl.

Теперь данных было достаточно, чтобы обратиться и в поддержку ISP System.

Итоги

Проблема была спровоцирована после выполнения обновления ISP Manager. В целом, обновление ISP Manager — штатная ситуация, но она привела к запуску процесса синхронизации, который завершался с ошибкой и перезапускался ежеминутно. Процесс синхронизации вызывал за собой процесс cagefsctl, который в свою очередь завершал процессы PHP.

Причиной зависания процесса синхронизации стали проведённые на хостинге работы по модернизации оборудования. За несколько месяцев до возникновения проблемы, в сервер был установлен PCI-e NVMe-накопитель, создан раздел XFS и смонтирован в каталог /var. На него были перенесены в том числе и файлы пользователей, но не обновились дисковые квоты. Опций монтирования было не достаточно, требовалось так же изменить тип файловой системы в параметрах ISP Manager, т.к. она вызывает команды обновления дисковых квот. Для Ext4 и XFS эти команды отличаются.

Таким образом, проблема дала о себе знать спустя несколько месяцев после проведения работ.

Выводы

Мы сами создали проблему, но это было не ясно до последнего момента. На будущее, будем стараться учесть как можно больше нюансов. Благодаря помощи более подготовленных коллег из поддержки CloudLinux и ISP System, проблема была решена. Теперь наш хостинг работает стабильно. А нами был получен опыт, который пригодится нам в будущей работе.

P.S.: Надеюсь, Вам было интересно ознакомиться с материалом статьи, а кому-нибудь она поможет быстрее решить подобную проблему.

Когда сервер временно не может обработать запрос пользователя, он передает в браузер ответ об ошибке 503. Отсутствие доступа к сайту имеет негативные последствия как для посетителя, который не может просматривать нужный контент, так и для владельца веб-ресурса, рискующего потерять трафик и конверсию. Чаще всего причиной ошибки являются неправильные настройки сервера или движка, с помощью которого создан сайт (CMS). Их исправлением занимается администратор веб-ресурса. Однако иногда уведомление с кодом 503 возникает из-за сбоев на стороне пользователя. Такие неполадки легче и быстрее исправить, и сделать это может посетитель веб-ресурса самостоятельно. В данной статье мы разберем несколько способов устранения ошибки 503, которые могут предпринять администратор и пользователь сайта.

Что значит ошибка 503 Service Unavailable

Ошибка 503 Service Unavailable — это уведомление, которое отправляет сервер, чтобы сообщить о появлении технических неполадок и временной невозможности обработать запрос пользователя. Сообщение появляется на веб-странице, которую пытался открыть посетитель, если на сайте есть проблемный скрипт, на сервер поступает больше запросов, чем он может обработать, или на устройстве и сетевом оборудовании пользователя возникли проблемы с настройками.

Ошибка 503 на сайте означает, что сервер в порядке, но в данный момент недоступен. Чтобы хостинг-компьютер снова начал корректно отвечать браузеру, необходимо найти причину поломки. Это поможет выбрать правильное решение проблемы. Перечислим возможные источники «Error 503»:

• DDoS-атаки и вирусы, приводящие к перегрузке сервера;
• несогласованная работа компонентов веб-страницы (медиаконтента, стилей и скриптов) — элементы каждого уровня запрашиваются и отправляются отдельно;
• последствия хотлинка — сервер тратит трафик и другие вычислительные ресурсы на ответ посетителям других сайтов (если в чужие веб-страницы встроены файлы, хранящиеся на вашем сервере);
• непрерывное обращение к веб-серверу одного из элементов сайта — плагина, виджета, темы;
• сканирование сайта поисковыми роботами и парсерами;
• конфликты плагинов CMS;
• отключение сервера для обслуживания;
• направление большого количества тяжелых запросов к базе данных;
• наличие недостаточно оптимизированных скриптов;
• отправка объемных статичных файлов при помощи скриптов;
• работа почтового сервера — регулярная рассылка большого количества сообщений;
• подключение к удаленному серверу — может привести к лишним HTTP-запросам, тайм-аутам, обрывам связи и т. д.

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

Как исправить ошибку 503 владельцу сайта

К ошибке HTTP 503 чаще всего приводят сбои, происходящие на сервере. Их исправление — ответственность владельца веб-сайта. Решение некоторых проблем не требует особых навыков, для других придется обратиться к вебмастеру или техническому специалисту с опытом в администрировании серверов.

Перезагрузка сервера

1. Выберете нужный заказ и откройте вкладку «Администрирование».

2. Перейдите в пункт «Управление операционной системой» и нажмите кнопку «Перезагрузить».

На перезапуск системы уйдет всего несколько минут.

Автоматическое обслуживание

Даже хорошо оптимизированный веб-ресурс не может работать 100% времени. Сервер и расположенный на нем сайт могут стать временно недоступными при выполнении некоторых видов технических работ:

• установке обновлений операционной системы и приложений;
• проверке безопасности системы и поиске вредоносных программ;
• автоматическом обновлении CMS и ее компонентов (тем, плагинов) и так далее.

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

Проверка настроек конфигурации брандмауэра

Обратитесь в службу технической поддержки

Если сайт недоступен и установить причину своими силами не удалось, обратитесь в службу технической поддержки хостинга. Специалист саппорта сообщит о технических работах и времени их окончания или поможет установить другой источник ошибки 503. В Интернет Хостинг Центре обратиться за помощью можно через раздел «Задать вопрос» в панели управления хостингом или через чат. При создании тикета необходимо подробно описать проблему и приложить скриншот.

Снижение нагрузки на сервер

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

1. Установка защитного экрана, например, CloudFlare, для защиты от хакерских атак и других угроз безопасности.
2. Оптимизация и удаление лишних скриптов для быстрой обработки запросов.
3. Выбор антилич-плагина, поддерживаемого вашей CMS, для защиты от хотлинка.
4. Удаление компонентов, постоянно обращающихся к серверу.
5. Запись в robots.txt пользовательских приложений (user agent), создающих нагрузку на сайт.
6. Проверка совместимости плагинов и тем друг с другом путем их попеременного отключения и тестирования работы сайта без них.
7. Обмен объемными файлами большого размера по протоколу FTP.
8. Организация рассылки в период сниженной нагрузки на сервер, например, ранним утром.
9. Контроль над количеством email-сообщений, отправляемых одновременно.

Как решить проблему, если вы — пользователь

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

1. Отключите от питания сетевое оборудование на три минуты. Если ошибка происходила из-за проблем с IP пользователя, после включения роутера адрес поменяется и сайт снова станет доступным.
2. Перезагрузите модем. Если причина в ПО внешних устройств, передающих вам трафик, может помочь перезагрузка сетевого оборудования.
3. Очистите кэш и другие временные файлы в браузере. Для этого воспользуйтесь сочетанием клавиш Ctrl+F5.
4. Смените браузер или перезапустите его. Это поможет избавиться от ошибок в текущей сессии и понять, является ли браузер источником ошибки.
5. Перезагрузите операционную систему. Сбой в ОС и программном обеспечении будет исправлен автоматически при новом запуске компьютера.

Заключение

Способов устранения ошибки 503 так же много, как и причин ее появления. Пока администратор сайта решает сложные технические вопросы, пользователь может проверить на причастность к сбоям собственную технику и установленное на ней ПО.

Каждому аккаунту на сервере выделено определенное количество процессов-рабочих, обрабытывающих запросы пользователей. Запросы поступают на сервер и становятся в очередь. Легкие запросы обрабатываются быстро, а тяжёлые проблемные — медленно, тормозя продвижение очереди. Когда длина очереди достигает определенной величины, сервер перестает принимать новые запросы, возвращая ошибку 503 (Service Temporarily Unavailable, сервис временно недоступен).

Ниже описаны частые причины возникновения длинной очереди, а так же пути решения этой проблемы:

Передача больших статичных файлов через PHP

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

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

Функциональность многих скриптов хранения файлов можно реализовать через правила mod_rewrite в файле .htaccess (например, антилич-систему).

Соединение с удаленным сервером

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

Большое число «тяжёлых» или испорченных компонентов CMS

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

Долговыполняющееся задание mambot (для Joomla)

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

Запуск скрипта почтовой рассылки лучше всего расположить в системном cron’е, управление которым находится в контрольной панели. А запуск его назначить на время наименьшей нагрузки на сервер (ночь по московскому времени). При этом следует учитывать ограничения, накладываемые условиями договора-оферты относительно количества писем в час/день и временем работы PHP-скрипта.

Большое количество медленных запросов к MySQL

Установите в движок кеширующие компоненты, которые могли бы сократить число SQL-запросов.

Проиндексируйте таблицы БД по столбцам, которые используются в выборке

Если ничего не помогает, возможно, стоит сменить движок на более оптимальный.

Версия PHP 5.4 и выше

После перехода с версий 5.2 5.3 на 5.4 и выше , вы можете получать ошибку 503, это может быть связано с тем, что не отключены параметры ( для отключения нужно указать = Off )

register_globals 

register_long_arrays
magic_quotes_gpc 
В новых версиях PHP данные параметры удалены и не поддерживаются.