хостинг 502 error nginx

А когда nginx виновник-то? Факты где?

Неумение его настраивать это не аргумент.

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

пусть будет постановка вопроса именно, так потому как на сегодняшний день видимо мало кто удиляет этому достаточное внимание и ошибки эти видны по всему интернету !

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

Готовить действительно умеют не все, а есть приходится всем ...

Т.е. вам больше понравится ошибка "соединение не удалось" из-за того, что Apache лежит?

Посмотрите по интернету, эта ошибка более распространена.

А 502-ю вы можете заменить html-Заглушкой типа "Сайт на профилактике" и не будете пугать своих посетителей.

Himiko добавил 12.03.2011 в 19:20

P.S.: При ошибках в скриптах вы тоже можете получить 502-ошибку.

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

Guru911 добавил 12.03.2011 в 19:54

я вот тут порыл и вот чего накопал:

Apache (worker MPM) + mod_php

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

При этом, так как php работает в адресном пространстве сервера, разделяемые потоками данные периодически портятся, поэтому связка нестабильна и не рекомендована. Это происходит из-за ошибок в mod_php, который включает в себя ядро PHP и различные php-модули.

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

Поток

Внутри сервера

Динамика

Чистый

Apache (event mpm) + mod_php

Event MPM - это стратегия работы с worker'ами, которую использует только Apache. Все - точно так же, как с обычными потоками, но с небольшим дополнением для обработки Keep-Alive

Установка Keep-Alive служит для того, чтобы клиент мог прислать много запросов в одном соединении. Например, получить веб-страницу и 20 картинок. Обычно, worker заканчивает обработку запроса - и ждет какое-то время (keep-alive time), не последуют ли в этом соединении дополнительные запросы. То есть, просто висит в памяти.

Event MPM создает дополнительный поток, который берет на себя ожидание всех Keep-Alive запросов, освобождая рабочего для других полезных дел. В результате, общее количество worker'ов значительно сокращается, т.к никто теперь не ждет клиентов, а все работают.

Поток

Внутри сервера

Динамика

Чистый

Пути работы с FastCGI

С FastCGI можно работать двумя путями. Первый способ - самый простой, его использует Apache.

получить запрос -> отдать на обработку в FastCGI -> подождать ответа -> отдать ответ клиенту.

Второй способ используют сервера типа lighttpd/nginx/litespeed/и т.п.

получить запрос -> отдать на обработку в FastCGI -> обработать других клиентов -> отдать ответ клиенту, когда придет.

Отмеченное отличие позволяет Lighttpd + fastcgi работать эффективнее, чем это делает Apache, т.к пока процесс Apache ждет - Lighttpd успевает обслужить другие соединения.

Режимы работы FastCGI

У FastCGI есть два режима работы.

Responder - обычный режим, когда FastCGI принимает запрос и переменные, и возвращает ответ

Authorizer - режим, когда FastCGI в качестве ответа разрешает или запрещает доступ. Удобно для контроля за закрытыми статическими файлами

Оба режима поддерживаются не во всех серверах. Например, в сервере Lighttpd - поддерживаются оба.

кому интересно http://algolist.manual.ru/web/servers.php

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

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

Да не так на самом деле бывает.

Мне интересно другое. У вас хоть какие-то есть данные, что виноват именно nginx ?

И исхожу из практического опыта, а вы похоже просто хоть каким-то образом пытаетесь отстаивать свою необоснованную точку зрения. (такое впечатление).

На хостинге только нашем nginx используется более 2,5 лет. На других проектах даже больше, которые администрируем.

и вы что целыми днями логи клиентов просматриваете ? не смешите меня ... Если клиент (хозяин сайта) сам не заметит эти баги, то врядле это вообще где то всплывет ... А хозяева сайтов как правило занимаются бизнес логикой, а не перезагружают странцу собственно сайта 24/7 ...

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

свой личный опыт с эджином я тут приводил неоднократно.

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

PHP-ZTS!!! Это две большие разницы.

Еще вопросы? :). Никогда! не следует использовать mod_php в режиме Worker. Он для этого не предназначен. Или полностью отказавшись от апача, вы думаете, кто-то будет работать в mod_php?

Ну так всё-таки? Если была бы ошибка "сервер не доступен" от apache, вы винили бы его?

У любого хостера бывают проблемы и далеко не факт, что ПО хоть как-то виновато в этом.

Himiko добавил 12.03.2011 в 20:44

Используется нами на серверах для крупных сайтов (есть до 1 млн. посетителей в сутки). nginx в данном случае повёл себя немного не адекватно :)

Они использовались вообще без apache.

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