gateway timeout php fpm apache
Долгий скрипт на Nginx, php5-fpm. Ошибка 504 через 60 сек. Куда смотреть?
Форум работает отлично, кроме этого скрипта.
Кусок конфига nginx:
Браузер при обращении к скрипту выдает через минуту: «504 Gateway Time-out»
phpinfo() утверждает, что max_execution_time = 0
Кто еще может ограничивать время выполнения скрипта? Куда копать?
Сервер, на котором возникла проблема не имеет белого IP, а проброшен через виртуальные хосты другого nginx`а. Он, наверное и не дожидался ответа бэкенда.
Всем спасибо за обсуждение, проблема решена.
ну раз получаете ответ c 504 значит тюнить надо nginx
fastcgi_connect_timeout
также возможно придется поднять keepalive_timeout
а вообще перенесите выполнение этого скрипта на cron
Алексей Сундуков: это время сохранения неактивного соединения с браузером пользователя, похоже же разве нет?
а по поводу 75 секунд можно всетаки пруф, вот вам исходник fastcgi модуля
https://github.com/nginx/nginx/blob/master/src/htt.
единственный таймаут который по умолчанию 75 секунд это keepalive_timeout
https://github.com/nginx/nginx/blob/master/src/htt.
neolink: Правильнее было говорить, что это механизм передачи по одному tcp сокету разных http ресурсов. Это ключевой момент. Потому что «неактивным» может быть и простое, не keepalive, соединение.
Пруф по исходникам я не найду, он упоминался в рассылке Максимом Дуниным если не ошибась, можно поискать либо поднять этот вопрос повторно. Пруф по докам вот: nginx.org/ru/docs/http/ngx_http_fastcgi_module.htm.
https://github.com/nginx/nginx/blob/bb8c0683da7735.
для spdy это точно такой же таймер как и например *_read_timeout, я поэтому и написал «возможно»
neolink: Не закрывать сокет после отправки последнего байта клиенту можно и не по keepalive соединению.
Касательно таймаутов и харкода посмотрю на досуге, может в последних версиях харкод убрали.
neolink: Ситуация прояснилась. Насчет харкода ввели меня в свое время в заблуждение. Но не важно. В общем хардкодом не ограничивают, ограничивает само ядро. 75 секунд величина сложилась исторически, т.к. изначально nginx работал под фряхой и это дефолтное значение по умолчанию.
Значит автору нужно либо выносить в крон, либо тюнить ядро, либо не выходить за таймауты (по времени исполнения, либо сбрасывая буфера).
75 секунд это таймаут на доставку syn пакета, то есть если у вас бекенд не упал (или сеть не перегружена и т.п.) вы в это не упретесь
Apache2 Php-Fpm No Response on Same Time Daily (504 Gateway Timeout)
My server stop response everyday at the same time (12.15pm-12.30pm),
I already check with my server cron job but did not see any cron are working in that time.
I also make some change to my mpm event file to increase the MaxRequestWorkers but the problem still unsolved.
Do you have any suggestion for me the fix this?
Below is my error.log
Related
Join 1M+ other developers and:
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
According to the logs, it does seem like the ApacheWorkers have hit their limit and afterwards some requests have timed out due to the wait time.
Increasing the ApacheWorkers was a good solution however it it’s still happening you’ll need to further investigate. I have two suggestions, one is during the said time, someone is on purpose flooding your server. The other one is your website gets updated or something similar and there are a lot of requests which actually make the server unusable.
Anyway, to actually confirm this, you can try and run the following command and see what is feeling up your ApacheWorkers
Or if this doesn’t work
I’ve had cases where apps created a million connections at a specific time and didn’t close them up afterwards causing my server to reach it’s maximum.
Kind regards,
Kalin
When the server downtime today, i try to check apachectl fullstatus & my server response as code below :
It’s really weird because after the 15 minutes downtime everyday,
the server are back to normal without any apache or php-fpm restart until the next day with the same time the server will down again.
When the server down, i don’t see any activities or CPU & MEM overload at the time.
Attached is “TOP” for your reference
Imgur
Как я победил ошибку 502 Gateway timeout error в nginx+php-fpm
Php-fpm считается на сегодняшний день одним из самых быстрых движков для веб-сервера.
Но он очень нестабилен при работе со сложным php-кодом. И в один прекрасный день вы можете получить ошибку 502 Gateway timeout error.
У меня в проекте так и получилось. На VPS стоял nginx + php7.0-fpm + MariaDB + memcached.
Код php-скрипта использовал весь этот стэк технологий и работал благополучно пару месяцев, а потом вдруг стал выдавать 502-ю.
Для проверки, когда мой скрипт все-таки работает, я написал скрипт-чекер на php и запускал каждые 10 минут его по сron. Чекер запускался через консоль, а обращался через функцию file_get_contents() к url скрипта на сайте.
В случае недоступности скрипта я отсылал через mail() письмо себе на почту.
Я выяснил, что ошибка 502 Gateway timeout error возникала не всегда. Могла появиться раз в час, а могла и на протяжении многих часов.
Временно исправить проблему помогала перезагрузка nginx и memcached.
Почитав мануалы, я решил применить то, что советуют — увеличить proxy timeout в директиве Location, а также timeout в настройках php-fpm.
Не помогло. Причем, когда я вообще сделал timeout в php-fpm бесконечным, скрипту все равно не хватало времени и он выполнялся без конца.
Решив, что все-таки дело в php-fpm я подумал, чем же его заменить. Порывшись в интернете я нашел решение для замены — OpenLightSpeed Webserver + php-модуль к нему.
Установив этот вебсервер, что было не совсем просто, но все же осуществимо в конце концов я обнаружил, что 502-я ошибка появляется все также.
Еще я не смог настроить BasicAuth авторизацию на папках, поэтому недолго думая запустил восстановление бэкапа диска VPS-сервера и через 10 минут снова работал с nginx+php-fpm.
Последнее обстоятельство толкало на новую мысль — дело не в сервере, а в скрипте. И это оказалось правильным.
Я залез в скрипт — там было 5 sql-запросов к mysql. 2 я слил в 1 при помощи LEFT JOIN, из 2-х запросов сделал 1. И еще 1 оставил, как есть.
Исследуя запросы, я обратил внимание на запрос
Как исправить 504 gateway time out Nginx
Веб-сервер Nginx часто работает не только в качестве самого веб-сервера для отдачи контента, но и в качестве прокси, когда он вступает только посредником. Такая ситуация наблюдается намного чаще, чем можно было бы ожидать. Например, при работе с php-fpm и другими модулями динамических языков.
Именно в таком режиме может наблюдаться ошибка 504 gateway time out Nginx. В нашей сегодняшней статье мы попытаемся разобраться почему она возникает и как с ней бороться. Разберем несколько способов решения и причин.
Что значит 504 gateway time out Nginx?
Как я уже сказал, такая ошибка возникает, когда сервер Nginx работает в режиме прокси. Например, при использовании php-fpm или Apache. Дословно, она означает, что превышено время ожидания ответа от сервера. В нашем случае, превышено время ожидания ответа от php-fpm. Рассмотрим несколько причин такого поведения:
Дальше рассмотрим что можно сделать если вы встретились с ошибкой 504 gateway time out Nginx.
Как исправить 504 gateway time out Nginx?
Нагрузку на процессор можно узнать командой htop:
Естественно, если вы видите, что PHP занимает все процессорное время, то значит проблема в ресурсах сервера. Вы можете покопаться в движке своего сайта, пытаться оптимизировать те или иные моменты, об этом будет отдельная статья или же выбрать более мощный VPS сервер.
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
Здесь 300 означает 300 секунд, для большинства скриптов, этого будет вполне достаточно, но вы можете еще больше увеличить значение если это нужно. Также ошибка 504 может возникать, когда Nginx используется в качестве прокси для Apache или любого другого веб-сервера, тогда нужно еще настроить время ожидания для прокси. Добавьте эти строки в секцию server:
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
sudo systemctl restart nginx
Более подробную информацию иногда можно увидеть в error.log:
Дальше, если проблема именно в php-fpm, вы можете отследить какие скрипты выполняются медленно с помощью встроенной функции slow-log. Для ее активации добавьте следующие строки в конфигурацию вашего пула:
sudo vi /etc/php-fpm.d/www.conf
slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 5s
Здесь 5 секунд, означает, что в лог файл будут добавляться скрипты, которые выполняются дольше пяти секунд. Вы можете менять это значение по своему усмотрению. В логе вы сможете увидеть не только сами скрипты, но и трассировку методов, которые привели к проблемам:
Дальше останется только разобраться что с этим делать, например, оптимизировать скрипты или отключить лишние плагины.
Выводы
В этой статье мы рассмотрели как исправить 504 gateway time out Nginx 1.2 7, а также почему может возникнуть эта ошибка. Надеюсь, эта информация была полезной для вас.
Gateway timeout with traefik and php fpm
I have a problem with setting up mailcow with traefik, I encounter gateway timeouts. I also have this problem with nextcloud, so I would be really interested, what causes these issues with gateway timeout.
I guess it has to do with port 9000 and php-fpm upstream or sth.
But I want to know for sure, and how to deal with it.
My traefik docker-compose.yml :
My mailcow docker-compose.yml :
4 Answers 4
I think I may have had a similar issue to what you are/were experiencing. Take a look at this GitHub issue: https://github.com/containous/traefik/issues/979
If your problem is the same as mine, here is the issue:
Traefik is on a «front facing» network, so is one of your services, but that service is also part of a «back facing» network. Traefik, by default, doesn’t know what network to send requests to. so it sends them to a randomly chosen one of the two IP address options (picked at the creation of that container). If Traefik isn’t part of that network, it wont be able to reach that container, and will give you a Gateway Timeout.
Solution: add a label to your container to directly specify to Traefik what network it should be communicating on:
Pro tip: use docker network ls to figure out what the actual name of your network is, because it is not what docker-compose says in the file. The actual network name is prefixed based on the name of the folder that it is run in. (I don’t know why, and I don’t like it, but that is the world we live in)