Странные проблемы на хостинге с CloudLinux

Возможно я неправильно объяснил.

Есть логи доступа. В логах доступа вместо обычного ответа 200 идет ответ 500 или 503.

Вот и все, отдельного лога ошибок с пояснениями нет.

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

Вы сделать ничего не можете для исправления ситуации.

Исходя из того, как я вижу ситуацию, это достаточно правдоподобно.

Спасибо за дельное замечание.

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

Если на сервере не хватает ресурсов то не будет ошибок, просто все будет жутко лагать. Ошибка возникает лишь при превышении лимитов, тогда запросы будут убиваться OOM-ом и LVE, тогда это 500 скорее всего будет. А 503 тоже подтверждение тому, что есть тяжелые долгие запросы, которые с большой вероятностью и грузят аккаунт. Уверен на 99% что все же нагрузка есть от кривых скриптов, но это ванга, не более без доступа к серверу.

smart2web, не совсем так всё же. Если на сервере всё хорошо (он не перегружен), то запросы обрабатываются быстро за счет того, что клиент получает все выделенные ему ресурсы, счетчики EP и NP (число соединений и процессов) могут быть практически на нуле. Если сервер перегружен, то клиент не будет получать всех выделенных ему ресурсов, запросы могут копиться из-за чего будет рост EP и NP, при достижении их лимитов будут 5XX ошибки.

Еще, если PHP работает через LSAPI, то во всех версиях библиотеки 1.1.Х есть баг с числом процессов, лимит берется как выставленный лимит EP + 1, в итоге, выделите 512 мегабайт памяти для пользователя, поставите ему 32 соединения и лимит в 64 процесса (так рекомендуют делать разработчики CloudLinux, NP > EP), в итоге при сравнительно небольшом числе процессов срабатывает лимит по памяти и выходят 500 ошибки. Если снизить число EP до 10, то сайт будет падать от лимита по числу соединений. В итоге, чтобы сайты работали хорошо, пользователю надо выделять много памяти и невысокие лимиты на EP и NP.

Для сравнения в LSAPI версии 1.0 можно поставить жесткий лимит lsphp процессов, например в те же 10, установить 32 EP и 64 NP и 512 мегабайт оперативной памяти. В данном случае пользователь не будет достигать лимита по памяти (при учете 10 процессов в среднем по 20-30 мегабайт) и при числе запросов от 10 до 32 в секунду сайт просто будет работать медленнее, так как будет ждать освобождения процессов lsphp, но не будет выбрасывать 5ХХ ошибки.

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

Все описанное исходя из личного мнения и расчета потребления памяти процессов lsphp в 20-30 мегабайт (в среднем).

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

Относительно проблемы автора - если бы проблема была с лимитами CloudLinux, то они бы отображались в статистике в виде faults, у меня за все годы работы такого не было, чтобы CL не отображал срабатывание по лимитам. Но при этом, были случаи, когда 500 ошибки возникали на ровном месте и без отображения в статистике CL, так как к не относились к лимитам. Например, в одном из случаев сайт клиента работал некорректно с zend opcache и PHP процесс завершался segfault, помогало php_value opcache.enabled 0 в файл .htaccess.

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

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

Евгений Русаченко, благодарю за интересную информацию по CloudLinux и LSAPI.

Отключил opcache в настройках PHP, проблема осталась.

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

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

это не совсем баг

счётчик процессов считает все lsapi процессы юзера + все активные httpd процессы, в которых произошёл вход в lve среду (через модуль hostinglimits)

Т.е. фактически на 1 запрос - 2 процесса = 1 lsapi процесс + 1 httpd процесс

Если убрать httpd модуль hostinglimits, то будут только lsapi учитываться, но тогда можно будет забить все свободные воркеры apache через одного юзера, и ляжет весь веб сервер