It is common to get 99% CPU usage on Post Update or Post Publication with WordPress Blog with huge number of posts. Errors are related to Server. If one goes to WordPress official forum, the likely answer will be
disable plugins and
revert to default theme. If you need to do soft reboot or even a hard reboot due to the hanging event, it is most likely that at there are indicative stuffs in the
memcached(daemon) are notorious for creating conflicts. The example setup we are talking about is a cloud server with 2 GB RAM, 2 virtual cores, database server is different, is hosted on Rackspace with Infrastructure level support only, the setup is for only one domain, we are using Ubuntu 14.04 LTS and Latest Apache. Since Ubuntu 13.10 and Apache 2.4.x there are difference with previous versions. Possibly you did an update and/or upgrade, may be you have done apparently nothing. But, this guide will help you in such helpless situation. At least you can go to
Quora and tell some minimum stuffs to the others.
Fix Failing Server on WordPress Post Publish
It is usually not Plugin, but some Plugin can help WordPress to do the wrong. Indeed, in past; only WordPress Permalink used to simulate the situation :
That issue has been fixed but there can be hundreds of unknown bugs. We will discourage to ask in WordPress Official forum, instead ask on
Quoraor somewhere you’ll find server side experts. If you ask in WordPress Official forum, there is more chance to get in the wrong direction. Removing a Plugin might temporarily fix an issue, but you should know what actually happened to make you reboot.
I have a friend who has a WordPress installation with a database which probably none can repair. He always login to server before hitting the Publish button. After clicking the Publish button, the server expectedly hangs and he type
rebootand hit Enter key on SSH. As he uses one server to host all – database server, web server – it is practically quite time consuming to reach towards the diagnosis. Practically as he do not write blog on regular basis or professionally, this trick works, but obviously this is not the right way.
By default, the Apache related error file will be located at :
If its location is changed, check the
php.ini file :
You can open the file either via SFTP or with
nano on Shell. Like :
cd /var/log/apache2/error.log && nano error.log
You might see something like this :
Obviously, depending on the error, you should fix it either by asking somewhere or just searching a bit on Web Search. For this particular situation, we might want to try to disable :
# disables a module of Apache2
sudo a2dismod module_name
# enables a module of Apache2
sudo a2enmod module_name
# both requires Apache to restart
service apache2 restart
For centos/ fedora and others, things work differently than in Ubuntu/ Debian.
There can be conflict due to a declaration in Apache ini file itself. Which can throw this type of error on restart :
* Restarting web server apache2 [fail]
* The apache2 configtest failed.
Output of config test was:
AH00526: Syntax error on line 99 of /etc/apache2/apache2.conf:
Invalid command 'ThisExampleRequest', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
Apache2, unfortunately has lot of peculiar problems, on version update; they can show colors.