504 Gateway timeout error

[mbparmar10]

Hello,

I am using Magento v2.2.6 on a Linux server with 8gb RAM, Apache v2.4.43 and PHP 7.0

Whenever I try to edit the orders from Magento Admin panel it shows me the 504 Gateway Timeout error. 

I tried increasing the max_execution_time to 3000 and max_input_vars to 10000 using PHP INI editor. But still have the same issue.

Please help me.

[Vimal Kumar]

Hi @mbparmar10 

Increase the php fpm value.

fastcgi_read_timeout 600;
proxy_read_timeout 600;

restart the php-fpm.

For more info: 
https://asdqwe.net/blog/solutions-504-gateway-timeout-nginx/ 

I hope it will help you!

[mbparmar10]

Thank you very much, I will try it and let you know.

Another same issue that I encountered today was after upgrading the store to 2.2.10 version of Magento. The whole site went down with the same 504 gateway error message.

Shall I go ahead and upgrade to 2.3.0 ignoring the message?

Any ideas on that?

[Vimal Kumar]

Hi @mbparmar10 

Definitively you should upgrade to Magento latest version 2.3.4.

But it will not resolve the 504 gateway error.

I think you should fix this 504 error first from server side.

[mbparmar10]

Hi Vimal,

Will your solution work on our Apache server? As mentioned we are using Apache dedicated server with 8gb ram and PHP v7.0

There is no Nginx or fastcgi installed.

[Vimal Kumar]

Hi @mbparmar10 

Try the below values

1. Update the below values in the php.ini file.

upload_max_filesize:1000M
max_execution_time:18000
memory_limit:4086M
max_input_time:18000
max_input_vars:3000
post_max_size:1000M

2. And then save the php.ini file.

3. Then we restart Apache service

On a CentOS server : service httpd restart
In Ubuntu: service apache2 restart

Might me It will help you!

[mbparmar10]

Hello @Vimal Kumar ,

I already tried putting the value of 18000 in max_execution time and current max_input_time is set to -1 which is for no memory limit.

However, Godaddy my server provider sent me the following message and asked to reduce the max_execution_time:

top - 14:25:30 up 13:18,  0 users,  load average: 0.06, 0.20, 0.24

Tasks:  68 total,   2 running,  66 sleeping,   0 stopped,   0 zombie

Cpu(s): 12.7%us,  0.4%sy,  0.0%ni, 86.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   8388608k total,  8087048k used,   301560k free,        0k buffers

Swap:        0k total,        0k used,        0k free,  5464480k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

 1551 mysql     20   0 6556m 1.5g  14m S  0.3 18.2   4:52.17 mysqld

 2044 cpanelco  20   0 14792 6740 4376 S  0.0  0.1   1:30.77 p0f

 1276 root      20   0  165m  29m 2224 S  0.0  0.4   0:39.75 lfd - sleeping

16658 nobody    20   0 2150m  27m  11m S  0.3  0.3   0:19.93 httpd

16751 nobody    20   0 2150m  28m  11m S  0.0  0.3   0:19.85 httpd

16717 nobody    20   0 2150m  28m  11m S  0.0  0.3   0:19.76 httpd

16689 nobody    20   0 2150m  28m  11m S  0.0  0.4   0:18.27 httpd

 3294 highfive  20   0  635m  85m  62m S  1.7  1.0   0:17.60 php-fpm

 3361 highfive  20   0  561m  82m  59m S  0.0  1.0   0:16.30 php-fpm

16752 nobody    20   0 2150m  27m  11m S  0.0  0.3   0:15.90 httpd

 3499 highfive  20   0  645m  87m  55m S  0.0  1.1   0:15.36 php-fpm

 3691 highfive  20   0  560m  69m  47m S  0.0  0.8   0:09.70 php-fpm

 2011 root      20   0  110m  25m 6832 S  0.0  0.3   0:09.33 cpsrvd (SSL) -

 1673 root      20   0  230m 114m 5420 S  0.0  1.4   0:07.32 spamd

 2780 root      20   0  231m 112m 1856 S  0.0  1.4   0:05.42 spamd child

 1196 root      20   0  243m 2008 1112 S  0.0  0.0   0:04.70 rsyslogd

 2035 root      20   0 68628  17m 2732 S  0.0  0.2   0:03.19 tailwatchd

So this is probably cause due to the (18000 seconds / 50 hours) time limit that your server has been set to allow php requests/scripts to run. Now, maybe there is a valid reason for this. But if you are going to let your php run for that long then your code has to be more responsible of the fact that connections and requests need to be killed after certain amount of time. Otherwise those 15m processes will add up and dry up your resources which translates into server timeouts and "500-type" errors

The above reply is from Godaddy after we had issues with the backup of site and not able to connect the FTP. So our current max_executon_time is set to 3000.

[Manish Mittal]

Hello @mbparmar10 

You should upgrade your php version. 

The Magento 2.2.10 patch enables support for PHP 7.2. Supported PHP versions for Magento 2.2.x are 7.2 and 7.1. PHP 7.0 is no longer supported.

For your reference:https://devdocs.magento.com/guides/v2.2/install-gde/system-requirements-tech.html

Apart from that Please note that Magento has no longer support for below > Magento 2.3 version so recommendable it to upgrade php and latest version of Magento. on 28 April Magento going to release new version which is Magento 2.3.5. You can upgrade to that version there are many old functions deprecated and fixes core issues, security issues. 

https://devdocs.magento.com/release/

[mbparmar10]

Hello @Manish Mittal 

Thanks for your reply, I have cloned my live store to a development store and it is using the PHP v7.2 and has been upgraded to the latest Magento v2.3.4. But despite this, there is a 500 Internal Server error showing both in the admin and frontend. The whole site is down and not even a single error log is generated. 

Can you please help me out.

@Vimal Kumar your input to this will be appreciated as well.

Please help me.

[Manish Mittal]

Please check server level logs of not generated Magento logs.