WordPress Backend throwing 50x error

[Paul Barrett]

One of my WordPress instances keeps stalling in the backend when I update a post / page. The update gets saved. The backend throws the error but the front end is fine and I can see the updated content while the backend is sorting itself out. It takes about 10 minutes.

The logs contain entries like this

Code: Select all

5016
2018-06-18T13:37:11+01:00 NAS02-php56-fpm[23724]: -[WARNING] -[pool www] -seems busy (you may need Co increase pm.scart_servers, or pm.min/max_spare_servers), spawning 8 children, there are 0 idle, and 6 total children®
2018-06-18T13:37:12+01:00 NAS02-php56-fpm[23724]:•[WARNING]•[pool www]•seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 16 children, there are 0 idle, and 7 total children®

I can see that I can change these settings in Web Station, but to what? Current settings are:

Code: Select all

FPM mode: Dynamic
Max processes: :20
Start servers: 2
Min spare servers: 1
Max spare servers: 3

I'd welcome any suggestions.

[Paul Barrett]

I tried increasing the values from 20 / 2 / 1 / 3 to 40 / 8 / 4 / 12

Do I need to stop / start any services? If so, what and how please?

UPDATE:
This may be a moot point. 18 package updates including php and MariaDB have just hit my DS. They are busily stopping and starting services all over the place

UPDATE 2:
Package updates and a complete server reboot have made no difference. It must be those php FMP settings

[Paul Barrett]

The issue seems to be linked to the USM Social media plugin, I have contacted them for assistance as I have paid for support

[steven]

I’m away on business and have been in meetings all morning. Some online posts refer to reaching the API limit but I’m not familiar with this plugin. Tech support is probably your best bet. Please let me know if you get this resolved.

[Paul Barrett]

I never did find an explanation of what was going on.

Synology released a whole bunch of updates last week, after which the problem disappeared. Fair enough!

Paul

[steven]

Great! I'm glad that worked. I'm still getting the 504 Gateway error when importing a large GEDCOM. To avoid the error, I use the NGINX back-end server for imports and switch back to Apache when the import completes.