Resource limit is reached как исправить

Coming across “Error 508. Resource Limit Is Reached” can put you off balance. It’s not a common HTTP error, but it can make both your site and webserver inaccessible.

But fret not. This article will explain what the HTTP Error 508 is, how you can troubleshoot it, and the preventative measures you can take to make sure that it doesn’t occur again.

Let’s get started!

Check out the video version

What Causes the “508 Resource Limit Is Reached” Error?

Most web host accounts have set limits on resources. If this limit is breached, a “508 Resource Limit Is Reached” error is triggered, and your site will be temporarily inaccessible.

This error is triggered at the server level and can be caused due to various factors, including excessive strain on server CPU and RAM resources. It’s also commonly associated with a high demand for concurrent processes, often seen if your site experiences an unusually high traffic volume.

A spike in website traffic could also be the result of an attempted DDoS attack. In this instance, your site will trigger a “508 Resource Limit Is Reached” error once the available resources have been exhausted during the attack. However, you might not have to do anything to fix the issue!

If you consider this surge in web traffic to be a one-off event, then you might choose to wait it out and see if the traffic subsides.

If you’re on a shared server, or you’ve subscribed to an entry-level hosting package, it’s more likely you’ll run into this type of error. If that’s the case, you’ll need to raise the resource limits in the short term to get your site back up and running again.

It might not be common, but when HTTP Error 508 does pop up, it can cause major problems for your site and your webserver. 👀 Learn how to fix it right here ⬇️Click to Tweet

How to Fix the “508 Resource Limit Is Reached” Error

When seeing higher traffic volumes than expected, your site can quickly exceed allocated resources, resulting in your server grinding to a halt.

Check Your Resource Usage

The first thing you can do to fix a resource limit error is to check your resource usage. Be sure to view server activity logs too. That’ll help in identifying the root cause of the problem.

If you’re a Kinsta customer, then you can view resource usage and activity logs quite easily.

Log into your MyKinsta dashboard and select the site you wish to view. You can view the resource usage via the Analytics menu and activity logs via the Activity Log menu.

There are additional tools and methods you can use to supplement this as well.

Bear in mind that the limits you see imposed on your site will be slightly less than the limits required to keep it running.

Why is this?

Let’s say your website is on a shared server, along with many other customers and their sites (bear in mind this wouldn’t be the case with Kinsta). As your site starts to attract more traffic, the server that hosts all these many websites, including yours, is processing more and more requests to accommodate your growing traffic.

If your popularity trend continues, the server will eventually hit its resource limits for every site it’s hosting, including yours. You can spot this trend early to prevent downtime. A good hosting provider keeps a watchful eye on the volume. Your web host should contact you to warn you that your site will go down if it continues to consume resources at a higher rate than your plan permits.

Check Internal Processes Running on Your Site and Third-Party Code

The cause of a “508 Resource Limit Is Reached” error may not always be external. Resources can be excessively consumed by one or more rogue processes running internally on your site, such as:

• Site backups
• Cron jobs
• Long or complex database queries
• A hacked site running a harmful script
• Third-party code

In the case of third-party code, this can often be down to a particular Content Management Solution (CMS) extension. If, for instance, you’re running WordPress and have one or more plugins installed that are regularly consuming more resources than are allocated, then you’ll run into 508 errors sooner or later.

To avoid such a situation, it’s advisable to keep your CMS extensions up to date. With WordPress, this means keeping your themes and plugins updated to the latest versions.

If no update has been available for a particular theme or plugin for a while, then consider discontinuing using it in favor of a similar, more recently updated product or contacting the author to check if a new version is imminent.

Deactivate All Your Site’s Extensions and Enable Them One by One

It could be that one of your CMS extensions is consuming more server resources than it should—in which case you should try disabling them all. If the error vanishes, then your suspicion is confirmed—­­an extension is a culprit.

Begin by deactivating the site’s extensions.

Once all extensions are deactivated, reactivate them one at a time, retesting your site each time to identify the culprit. Your next course of action should be to contact the extension author to report the issue. If the extension is well maintained, its author should get back to you with a workable solution.

Deactivate Your Child Theme

Finally, if you’re using a WordPress child theme, you should check the changes that have been made to it to see if they could be causing any issues. You can quickly test this by temporarily swapping to the parent theme.

Contact Support

If none of those above ways helped you pinpoint the cause of the increased resource usage, you should contact your web host’s support team and ask them for more detailed information. Kinsta’s support team is available 24/7.

Preventative Measures

It’s a good idea to keep one eye on server resource usage as a preventative measure. It will give you a chance to get ahead of any potential issues that could bring your site down.

Self-maintenance is a sensible approach to helping keep hosting costs under control as your site grows and matures while simultaneously making sure your site’s downtime is minimized. Ideally, you’ll want to stay well below the allocated resource limit to reduce the risk.

Many add-on applications can help you keep track of your site’s usage. An application performance monitoring tool (like Kinsta APM) should be a top consideration when deciding how to keep watch over your site.

If you’re running any promotions or marketing drives, then expect and prepare for increases in site traffic. It can help to understand how your hosting provider counts visits to your site. In most cases, you won’t necessarily see a massive spike in traffic, but it’s still sensible to try and predict whether you’re likely to run close to your limits.

Additionally, make sure that your contact details (phone and email) are always up to date. That way, you won’t miss any resource usage alerts.

For peace of mind, we recommend investing in a dedicated webserver, or—barring that—a higher allocation of initial resources, such as with Kinsta’s disk space add-on. Having this flexibility will cost more, but the chances of your website going down will drop to nearly nothing.

Don’t let an HTTP Error 508 message ruin your day. 😥 With these quick tips you can troubleshoot it and take preventative measures to stop it from happening again👇Click to Tweet

Summary

When your site hits a “508 Resource Limit Is Reached” error, it can be challenging. You’ll want to get things back up and running as soon as possible. To prevent this error from happening again in the future, you should:

• Fix the current issue by checking what’s causing the high resource usage and
• Raise your site’s resources limits to take into account future growth and traffic as well

For more, check out how Kinsta does things differently with Google Cloud infrastructure and isolated software containers for each site.

Coming across “Error 508. Resource Limit Is Reached” can put you off balance. It’s not a common HTTP error, but it can make both your site and webserver inaccessible.

But fret not. This article will explain what the HTTP Error 508 is, how you can troubleshoot it, and the preventative measures you can take to make sure that it doesn’t occur again.

Let’s get started!

Check out the video version

What Causes the “508 Resource Limit Is Reached” Error?

Most web host accounts have set limits on resources. If this limit is breached, a “508 Resource Limit Is Reached” error is triggered, and your site will be temporarily inaccessible.

This error is triggered at the server level and can be caused due to various factors, including excessive strain on server CPU and RAM resources. It’s also commonly associated with a high demand for concurrent processes, often seen if your site experiences an unusually high traffic volume.

A spike in website traffic could also be the result of an attempted DDoS attack. In this instance, your site will trigger a “508 Resource Limit Is Reached” error once the available resources have been exhausted during the attack. However, you might not have to do anything to fix the issue!

If you consider this surge in web traffic to be a one-off event, then you might choose to wait it out and see if the traffic subsides.

If you’re on a shared server, or you’ve subscribed to an entry-level hosting package, it’s more likely you’ll run into this type of error. If that’s the case, you’ll need to raise the resource limits in the short term to get your site back up and running again.

It might not be common, but when HTTP Error 508 does pop up, it can cause major problems for your site and your webserver. 👀 Learn how to fix it right here ⬇️Click to Tweet

How to Fix the “508 Resource Limit Is Reached” Error

When seeing higher traffic volumes than expected, your site can quickly exceed allocated resources, resulting in your server grinding to a halt.

Check Your Resource Usage

The first thing you can do to fix a resource limit error is to check your resource usage. Be sure to view server activity logs too. That’ll help in identifying the root cause of the problem.

If you’re a Kinsta customer, then you can view resource usage and activity logs quite easily.

Log into your MyKinsta dashboard and select the site you wish to view. You can view the resource usage via the Analytics menu and activity logs via the Activity Log menu.

There are additional tools and methods you can use to supplement this as well.

Bear in mind that the limits you see imposed on your site will be slightly less than the limits required to keep it running.

Why is this?

Let’s say your website is on a shared server, along with many other customers and their sites (bear in mind this wouldn’t be the case with Kinsta). As your site starts to attract more traffic, the server that hosts all these many websites, including yours, is processing more and more requests to accommodate your growing traffic.

If your popularity trend continues, the server will eventually hit its resource limits for every site it’s hosting, including yours. You can spot this trend early to prevent downtime. A good hosting provider keeps a watchful eye on the volume. Your web host should contact you to warn you that your site will go down if it continues to consume resources at a higher rate than your plan permits.

Check Internal Processes Running on Your Site and Third-Party Code

The cause of a “508 Resource Limit Is Reached” error may not always be external. Resources can be excessively consumed by one or more rogue processes running internally on your site, such as:

• Site backups
• Cron jobs
• Long or complex database queries
• A hacked site running a harmful script
• Third-party code

In the case of third-party code, this can often be down to a particular Content Management Solution (CMS) extension. If, for instance, you’re running WordPress and have one or more plugins installed that are regularly consuming more resources than are allocated, then you’ll run into 508 errors sooner or later.

To avoid such a situation, it’s advisable to keep your CMS extensions up to date. With WordPress, this means keeping your themes and plugins updated to the latest versions.

If no update has been available for a particular theme or plugin for a while, then consider discontinuing using it in favor of a similar, more recently updated product or contacting the author to check if a new version is imminent.

Deactivate All Your Site’s Extensions and Enable Them One by One

It could be that one of your CMS extensions is consuming more server resources than it should—in which case you should try disabling them all. If the error vanishes, then your suspicion is confirmed—­­an extension is a culprit.

Begin by deactivating the site’s extensions.

Once all extensions are deactivated, reactivate them one at a time, retesting your site each time to identify the culprit. Your next course of action should be to contact the extension author to report the issue. If the extension is well maintained, its author should get back to you with a workable solution.

Deactivate Your Child Theme

Finally, if you’re using a WordPress child theme, you should check the changes that have been made to it to see if they could be causing any issues. You can quickly test this by temporarily swapping to the parent theme.

Contact Support

If none of those above ways helped you pinpoint the cause of the increased resource usage, you should contact your web host’s support team and ask them for more detailed information. Kinsta’s support team is available 24/7.

Preventative Measures

It’s a good idea to keep one eye on server resource usage as a preventative measure. It will give you a chance to get ahead of any potential issues that could bring your site down.

Self-maintenance is a sensible approach to helping keep hosting costs under control as your site grows and matures while simultaneously making sure your site’s downtime is minimized. Ideally, you’ll want to stay well below the allocated resource limit to reduce the risk.

Many add-on applications can help you keep track of your site’s usage. An application performance monitoring tool (like Kinsta APM) should be a top consideration when deciding how to keep watch over your site.

If you’re running any promotions or marketing drives, then expect and prepare for increases in site traffic. It can help to understand how your hosting provider counts visits to your site. In most cases, you won’t necessarily see a massive spike in traffic, but it’s still sensible to try and predict whether you’re likely to run close to your limits.

Additionally, make sure that your contact details (phone and email) are always up to date. That way, you won’t miss any resource usage alerts.

For peace of mind, we recommend investing in a dedicated webserver, or—barring that—a higher allocation of initial resources, such as with Kinsta’s disk space add-on. Having this flexibility will cost more, but the chances of your website going down will drop to nearly nothing.

Don’t let an HTTP Error 508 message ruin your day. 😥 With these quick tips you can troubleshoot it and take preventative measures to stop it from happening again👇Click to Tweet

Summary

When your site hits a “508 Resource Limit Is Reached” error, it can be challenging. You’ll want to get things back up and running as soon as possible. To prevent this error from happening again in the future, you should:

• Fix the current issue by checking what’s causing the high resource usage and
• Raise your site’s resources limits to take into account future growth and traffic as well

For more, check out how Kinsta does things differently with Google Cloud infrastructure and isolated software containers for each site.

Страниц: [1] 2   Вниз

Страниц: [1] 2   Вверх

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

Прежде чем переживать, стоит сделать данные действия:

• очистите кэш в браузере
• скопируйте сайт и откройте его в другом браузере
• почистите локальный DNS-кэш
• попробуйте открыть сайт с помощью онлайн-инструмента downforeveryoneorjustme.com
• откройте ресурс посредством прокси-сайтов: anonymouse.org, kproxy.com, zend2.com

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

500 Internal Server Error

Эта ошибка значит, что у веб-сервера появились с внезапным условием, что мешает выполнять ваши запросы для доступа к URL.

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

• Перезагрузите страницу.
• Удалите куки и очистите кэш браузера.
• Проверьте код или смените имя .htaccess файла для того, чтобы стало ясно, не связана ли ошибка с одним из прописанных в нем правил.
• Проверить разрешения на файлы и папки. Для Linux-систем корректными разрешениями на папки будут 0755, на файлы – 0644. Для public_html, в свою очередь – 0750. Для некоторых скриптов будет необходимо разрешение 0777. Нередко бывает так, что они будут блокироваться системой безопасности сервера. Тогда вам нужно написать в техподдержку.
• Сделайте проверку RAM, CPU, Entry processes. Вполне возможно, что по ним превышен лимит. В панели хостинга cPanel осуществите проверку данных значений в Метрике. Если сервер базируется на Linux, то можете использовать SSH и войдя на сервер, сделайте запуск команды top -c.
• Проверку php.ini файла или смените его имя. Оно может несовпадать с насущной PHP-версией, что работает на сайте.
• Обратиться в техподдержку провайдера хостинга с просьбой проверки, есть ли в mod_security блоков в логах веб-сервера или иных ошибок, что могут приводить к проблеме 500.

501 Error Not Implemented

Эта ошибка появляется нечасто, но все же она случается. Она говорит о том, что веб-сервер или не принимает, либо не поддерживает HTTP-метод, что занимается поисков в потоке HTTP-информации, отправленных ему клиентом.

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

502 Error Bad Gateway

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

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

Что тогда нужно делать:

• Проверить сайт посредством прокси-сервера типа anonymouse.org, kproxy.com.
• Если сайт запускается с помощью прокси-сервиса, можно очистить кэш или зайти на сайт через другой браузер.
• Если с помощью прокси-сервиса работать не получается – обратитесь к хостинг-провайдеру.

503 Error Service Unavailable

Данная ошибка говорит о том, что веб-сервер в настоящее время не способен обработать HTTP –запрос из-за перегрузок сервера или техническими работами на нем. Данная ошибка является временной, и ее должны решить без вашего участия спустя определенное время. Кроме этого, ошибка 503 может говорить о достижении вашим аккаунтом LVE-лимитов и невозможности выделения дополнительной памяти.

Что можно сделать:

• Очистить кэш или открыть сайт в других браузерах.
• Сделать перезапуск роутера.
• Попросить проверить сервер у вашего хостингового провайдера.

504 Error Gateway Timeout

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

Часто это свидетельство того, что второй сервер отключен или его работа некорректна. Ошибка может зависеть и от большой нагрузки на сервер – такой, что он становится неспособным отвечать на новые запросы. И последние таким образом создают некую очередь. Как итог – запросы вовремя не обработаны, а связь – оборвана.

Ошибку 504 могут исправить только админы сети второго сервера. Редко случается так, что ошибка может зависеть от всего сервера и вам необходимо увеличить max_execution_time в php.ini или произвести оптимизацию скриптов.

507 Error Insufficient Storage

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

Виртуальный хостинг данную ошибку выдает очень редко. Она более распространена на VPS и выделенных серверах.

508 Error Resource Limit is Reached

Если вам видна эта ошибка – то аккаунт достиг лимитов в ресурсах.

Это бывает в таких случаях:

Аккаунт на постоянной основе достигает лимитов, которые ему присваиваются. Серверы перегружены и сервисы – недоступны. В том числе, и cPanel.

Что можно совершить при этом:

• Если на сайте достигнуты лимиты в первый раз – нужно проверить последние обновления, сделанные на сайте. Обычно в них и кроется причина появления ошибки. Если установлен новый плагин либо тема, то стоит выключить их и понаблюдать за работой сайта в течение 15 минут.
• Проверку использования ресурсов своего аккаунта в онлайн режиме посредством cPanel >> Resource Usage. И если лимиты не превышаются, то в этом разделе вы сможете просматривать за статистикой по любым временным периодам.

В процентах на главной показано соотношение текущего пользования ресурсами.

Также можно сделать проверку ресурсов посредством SSH , зайдя на сервер и запустив top -c.

• Посмотрите error_log в корневой папке сайта. И проверьте информацию на отсутствие PHP-ошибок, которые могут быть причиной превышения лимитов. Если таковы найдены – тогда попытайтесь исправить их. Наиболее простым решением будет смена имени файла скрипта.
• Сделайте проверку статистики посещений вашего сайта при помощи cPanel >> AWStats.

Можно там найти увеличения числа посещений и подозрительную активность с тех или иных IP-адресов. Если вы обнаружили такие – попытайтесь заблокировать их посредством .htaccess  файла вашего сайта с добавлением кода:
order allow,deny
allow from all
deny from X.X.X.X

где X.X.X.X — это IP-адрес, который планируете заблокировать.

• Держите свой сайт и базу данных в постоянной оптимизации.
• Работайте с любой CDN-системой.
• Сделайте запрос хостинговому провайдеру на проверку серверных логов для определения точных причин превышения лимитов. Может быть, проблема связана с плагинами сайта и их нужно отключить. Иная причина – чересчур активные запросы от того или иного IP-адреса или подсети.

509 Error Bandwidth Limit Exceeded

Эта ошибка появляется, когда ваш аккаунт достигаем лимитов по трафику, что установлен вашим интернет- или хостинг-провайдером.

Тогда нужно решение проблемы с той компанией, которая установила лимит.

403 Error Forbidden

Ошибка 403 говорит о том, что доступ к странице либо ресурсу запрещается по определенным причинам.

Вот что наиболее часто вызывает такую ошибку:

• Некорректные разрешения в пользовательском аккаунте. Тогда нужна проверка разрешения на папки и файлы. На Linux-системах правильными разрешениями на папки будут 0755, на файлы – 0644. А вот для public_html показатели будут 0750. Ряд скриптов может нуждаться в разрешении 0777. Если они будут блокироваться – обращайтесь в техническую поддержку.
• Неверный владелец на директории /home и /publiс_html. С этим вопросом нужно сделать запрос к хостинговому провайдеру.
• Блоки mod_security. ModSecurity является модулем веб-сервера Apache, что будет блокировать exploit-приложения и защищать сайты от хакеров. Он будет работать в качестве файервола на виртуальных серверах. Данную ошибку также можно решить путем обращения к хостинговому серверу.
• Блоки HAProxy. HAProxy считается еще одним приложением на серверах во имя безопасности. С его помощью балансируется нагрузка при приеме TCP- и HTTP-запросов и распределяет сервер таким образом, что Apache обрабатывает их правильно.

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

— блокировка домента или аккаунта из-за DDoS-атаки. После прекращения атаки блок снимется.

— вы пробуете открыть админ-панель WordPress посредством HTTP 1.0 POST запроса. И прокси настроен решительно: он блокирует любые HTTP 1.0 POST, что связаны с wp-logn.php страницей.

Обратитесь к хостинг-провайдеру с просьбой внести домен в белый список.

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

— блокировка пользователя с определенным IP-адресом:

order allow,deny
allow from all
deny from X.X.X.X

— блокировка всех, кроме пользователей с определенным IP:
order deny,allow
deny from all
allow from X.X.X.X

Код, что блокирует доступ к файлам директории:
Options -Indexes

В подобных ситуациях советуем удалить код или сменить имя .htaccess файла для его выключения.

Белая страница на сайте

В основном она появляется из-за PHP-ошибок, что можно найти в error_log файле в корневой директории сайта. Как правило, такой лог содержит много полезных данных: определенный файл, путь, линия, место появления ошибки и другое. Кроме этого, при помощи php.ini файла возможно включение отображения ошибок на сайте. Для этого добавьте в php.ini данный код: display_errors = On

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

Server connection timed out или The connection was reset

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

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

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

Успехов!

Время прочтения
7 мин

Просмотры 27K

Работа в поддержке хостинга в основном однотипная, большинство запросов от клиентов решаются по проработанной схеме, но иногда всё же приходится сталкиваться с нетривиальными проблемами. Тогда главная задача инженера — найти тот самый — единственно верный путь, который приведёт к её решению. В этой статье хочу рассказать о том, как мы столкнулись с плавающей ошибкой «HTTP Error 503. Service Unavailable» на нашем shared-хостинге, как пытались её отловить, провели диагностику и получили неожиданный финал.

Начало

Хостинг предоставляет пользователям типичный стек 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/"

В итоге, получили название процесса /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.: Надеюсь, Вам было интересно ознакомиться с материалом статьи, а кому-нибудь она поможет быстрее решить подобную проблему.