AndyBoell
asked on
Ubuntu Wordpress Client error "Inactivity Timeout. Description: Too much time has passed without sending any data for document."
I am running Ubuntu 14.04 LTS and Wordpress 4.4. This is a minimal site with under 10 pages. However, the site has been going down regularly and I am not very familiar with Wordpress/Apache/Ubuntu to understand how to troubleshoot it.
If I restart the apache process, the site comes up. If I reboot the server then obviously it also comes up. When the server is "down", the error received on the client machine is "Inactivity Timeout. Description: Too much time has passed without sending any data for document." Aside from figuring out how to get it working again (temporarily), I have noticed that in the down state it is in, there are 155 processes running "/usr/sbin/apache2 -k start". That seems strange to me, but I don't know what it means.
When searching the Internet for any clues, one suggested I run the top command and check out the RES value. About once every 5 to 10 seconds apache2 pops to the top with a value around 40000. Also, mysqlid pops to the top once every 5 to 10 seconds and has a RES value of 72000. The rest of the RES values are under 5000. Not sure if that's normal or helpful, but thought I'd include it.
Any direction would be appreciated.
If I restart the apache process, the site comes up. If I reboot the server then obviously it also comes up. When the server is "down", the error received on the client machine is "Inactivity Timeout. Description: Too much time has passed without sending any data for document." Aside from figuring out how to get it working again (temporarily), I have noticed that in the down state it is in, there are 155 processes running "/usr/sbin/apache2 -k start". That seems strange to me, but I don't know what it means.
When searching the Internet for any clues, one suggested I run the top command and check out the RES value. About once every 5 to 10 seconds apache2 pops to the top with a value around 40000. Also, mysqlid pops to the top once every 5 to 10 seconds and has a RES value of 72000. The rest of the RES values are under 5000. Not sure if that's normal or helpful, but thought I'd include it.
Any direction would be appreciated.
ASKER
So apache is running...
In checking /var/log/apache2/error.log
AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
So I did a quick search and ran across this article http://serverfault.com/que
Here's what I came up with:
Then I followed the recommendation of opening up 10 tabs and rapidly refreshing to determine the Average Process Size, which was 37.9MB
Taking 5.2G / 37.9M = 140 simultaneous connections
Then I opened the file
Finally, I checked
What do you think, should I just increase MaxRequestWorkers anyway, and if so, to what value? I can allocate more RAM to this VM if necessary.
In checking /var/log/apache2/error.log
AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
So I did a quick search and ran across this article http://serverfault.com/que
Here's what I came up with:
free -htThen I followed the recommendation of opening up 10 tabs and rapidly refreshing to determine the Average Process Size, which was 37.9MB
Taking 5.2G / 37.9M = 140 simultaneous connections
Then I opened the file
/etc/apache2/mods-enabled/mpm_preform.confFinally, I checked
/etc/apache2/apache2.confWhat do you think, should I just increase MaxRequestWorkers anyway, and if so, to what value? I can allocate more RAM to this VM if necessary.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Actually I opened the access.log file and I'm getting attacked from the Netherlands, around 2-3 per second.
I'm going to block a few supernets on my firewall to see if that helps.
"POST /xmlrpc.php HTTP/1.0" 200 596 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"I'm going to block a few supernets on my firewall to see if that helps.
ASKER
The access.log indicated the server was being attacked. Implementing a firewall change has blocked those attackers (for the time being). I will continue to monitor the server behavior and see if it stays up longer now.
I use Cloudflare - make it their problem.
Open in new window
will tell you.A look at the log files might also cast light on the problem.