Issue Wordpress Server Error 505 - Memory_Limit

[theXxX]

Server operating system version

Ubuntu 20.04.5 LTS

Plesk version and microupdate number

Plesk Obsidian v18.0.48_build1800221104.03 os_Ubuntu 20.04

Hi,

i have a problem with Wordpress and Plesk.

Details

• When I try to save something in Wordpress with Elementor I get the error message Server Error 505.

I have already done the following:

• Tested the same WordPress site with Elementor on another server. Everything works here.
• It's not because of a broken plugin or because of Elementor. On another server (from a hoster), everything works without problems.
• memory_limit was set to: 456M
  • After I increased to 456 it worked without errors for a few days. But now the error comes back.

After more detailed research, I realized that there are two settings for memory_limit. The server-side setting and the setting of WordPress itself.
In Plesk at Domains - PHP Settings memory_limit was increased to 456M. In Wordpress under Elementor - System Information, 128M was set. Therefore, I have increased the memory_limit to 456 for the used PHP version memory_limit under Plesk > Tools & Settings > PHP Settings > PHP handler (8.1.13 FastCGI application) > php.ini. Now 456M is also displayed in Wordpress. However, the error is still there.


Plesk settings:
PHP: 8.1.13 FastCGI Apache

CPU	Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz (4 core(s))
Version	Plesk Obsidian v18.0.48_build1800221104.03 os_Ubuntu 20.04
Betriebssystem	Ubuntu 20.04.5 LTS

Any ideas about the problem?

 

[Peter Debik]

This type of error is often caused by nested scripts that recursively call themselves. Example: A rewrite rule defines a specific 404 error page, but that page does not exist, so the webserver redirects to a "not found" page, redirects to a "not found" page, redirects to a "not found" page ... The same can happen when in a post or a page a script is included that recursively opens itself. For that reason more and more RAM is consumed as the script is stock in a recursive loop. You can test this simply by increasing RAM per script execution to an abnormally high value such as 1 GB or even 2 GB (most scripts need less than 100 MB).

Should you have migrated the site recently, make sure that all your paths and absolute URLs are set correctly.