@Franco,
1. Huge pages error: sure, I can do that, but that's not relevant for the current issue: the bad gateway upon restart has been there for ages, long before php7. Indeed my parameter for php7 is 1 (was not there before). I understand setting it to 0 would avoid the zend error, but isn't that voiding the php7 speed advantage?
The "opcache.huge_code_pages=0" setting is not "voiding the php7 speed advantage", nor is it disabling opcache.
In essence, it is just preventing that, in the case that appropriate OS configuration is absent, the Huge Pages support is claiming memory in such a fashion that the server underperforms.
2. Swapfiles: how do I if they function correctly?
Just run the command "free -m" from the command line: any value in the columns "free, used or total" is an indication that the swap is working.
Note that, in some cases, swap is not persistent: to check this (on a dedicated server), you can have a look at the fstab file, which should contain a line for the swap file.
Also note that, if you are using a VPS, swap is mostly assigned to the VPS by the host server, implying that the fstab file on the VPS does not contain information about swap partitions.
3. FW rules: I know that the rules set in plesk work fine for me, but how to make sure something else does not interfere restoring bad rules at system restart? AFAIK, the only cron jons I have is ntp and the domains backups. I also have the iptables before and after the problem, but the issue is, again, who's restoring the bad ones?
You do have a number of other cronjobs, one cronjob directly follows from the casaluna-access-log.txt file: a WordPress cronjob.
The WordPress cronjobs are notorious, in the sense that they can be causing a resource overload.
To prevent this, just login into the Plesk panel and go to the domain(s) mentioned in your error logs and
1 - increase the memory_limit assigned to domain (by default 64M, change it to 128M or 256M), (and)
2 - increase the max_execution_time and max_input_time (by default 60, change it to 120)
and note that increasing the execution time will often resolve many issues at the same time.
In short, changing these values would often do the trick, in the sense that it is a decent work-around, but it has to be mentioned that this work-around does not address the root cause of the problem (implying that you can be encountering similar issues in the future and/or have to increase before mentioned values a little bit more).
By the way, one thing has to be made quite clear.
The regular tasks and cronjobs can cause the 504 Nginx error and increasing values according to points 1 and 2 can do the trick.
The WordPress cronjobs are on a whole different level and can also cause a 504 Nginx error separately (!), simply as a result of default memory settings within WordPress.
The default memory settings in WordPress are 40MB, a little bit on the low side, causing huge "delays" in php-fpm worker processes when executing scripts, tasks or cronjobs.
In order to change the WordPress memory settings, open the wp-config.php file of the domain in question and add:
/** Custom memory settings. */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );
just below the line containing the $table_prefix variable.
Note that you have to adjust the value "256M" to the value you have chosen for the memory_limit variable (!).
Also note that it is often better to set WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT slightly lower than the value for memory_limit.
Hope the above helps!
Regards....
Facebook
Twitter
