Server is within MinSpareThreads of MaxRequestWorkers, consider raising the MaxRequestWorkers setting

[ksgalicia]

Hello!

Checking the Apache logs of a VPS server with 32 GB RAM and 8-core processor, I find this:

[Fri Mar 26 07:35:23.082590 2021] [mpm_worker:error] [pid 789:tid 47280170771520] AH00287: server is within MinSpareThreads of MaxRequestWorkers, consider raising the MaxRequestWorkers setting
[Fri Mar 26 07:37:50.536138 2021] [proxy_fcgi:error] [pid 12507:tid 47280510383872] (70007)The timeout specified has expired: [client 147.135.194.103:58674] AH01075: Error dispatching request to : (polling)

To what is due? How the problem is solved?

Every time this happens I have to restart Apache.

Thanks!

 

[kodeslogic]

You will have to raise the Max Request Workers in the Apache configuration. You can also consult certified SafeAdmin System Administration Services for tunning your Apache configuration.

 

[ksgalicia]

These are the default values of the Apache configuration:

• Start Servers: 5
• Minimum Spare Servers: 5
• Maximum Spare Servers: 5
• Server Limit: 256
• Max Request Workers: 150
• Max Connections Per Child: 100000
• Keep-Alive: On
• Keep-Alive Timeout: 5
• Max Keep-Alive Requests: 100
• Timeout: 300

What are the recommended values or is there a tool to calculate the recommended values according to the VPS server processor and memory?

Thanks!

 

[cPRex]

There are no tools that will accurately give you the settings based on the server's hardware, as it also depends on the site content and traffic as well. You can increase the MaxRequestWorkers value to 200 to see if that keeps you from getting these warnings in the log.

 

[ksgalicia]

I understand that if I have to increase the value of MaxRequestWorkers to 200 then I have to proportionally increase the value of the other parameter ServerLimit more or less to 340, correct?

 

[kodeslogic]

You need to keep MaxRequestWorkers value less than the value set for ServerLimit. So you if you're planning to raise the MaxRequestWorkers value greater than the current ServerLimit then you should also adjust the ServerLimit value to be greater than MaxRequestWorkers whatever you set.

 

[ksgalicia]

Hi!

I keep having problems with Apache. It stays locked and reboot to unlock. Attachment screenshot. As you can see there are 100 requests currently being processed, 100 idle workers.

The setting of the parameter MaxRequestWorkers is 200.

It is normal? Do I have to increase the value of MaxRequestWorkers?

 

[cPRex]

Thanks for that screenshot. Nothing in the screenshot looks out of the ordinary for me, as that seems to be a server handling 100 requests as expected. With 100 idle slots available, I would expect the system to be responding quickly.

When you say "It stays locked and reboot to unlock" do the website pages not load at all? Do you get an error in the browser? Do you see anything in the main Apache log at /etc/apache2/logs/error_log?

 

[ksgalicia]

Apparently the sum of the values 100 requests currently being processed and 100 idle workers is equal to the value of MaxRequestWorkers, the Apache server stops working... I think the problem is there...

 

[cPRex]

That should be fine though, as those 100 workers are idle.

You're always welcome to open a ticket with our team so we can check the server directly.

 

[ksgalicia]

At what point are idle workers processes killed? In six days there are more than 225 inactive workers who are still there...

 

[cPRex]

Just so I am clear on the issue, how can you tell the workers are inactive? If you run this:

apachectl fullstatus

one of the output sections gives a graph of the active process IDs that will look something like this:

+--------------------------------------------------------------------------------------------+
|      |       |          |    Connections    |   Threads   |       Async connections        |
| Slot |  PID  | Stopping |-------------------+-------------+--------------------------------|
|      |       |          | total | accepting | busy | idle | writing | keep-alive | closing |
|------+-------+----------+-------+-----------+------+------+---------+------------+---------|
|0     |18873  |no        |0      |yes        |0     |25    |0        |0           |0        |
|------+-------+----------+-------+-----------+------+------+---------+------------+---------|
|1     |18876  |no        |0      |yes        |0     |25    |0        |0           |0        |
|------+-------+----------+-------+-----------+------+------+---------+------------+---------|
|2     |18877  |no        |0      |yes        |0     |25    |0        |0           |0        |
|------+-------+----------+-------+-----------+------+------+---------+------------+---------|
|3     |18882  |no        |0      |yes        |0     |25    |0        |0           |0        |
|------+-------+----------+-------+-----------+------+------+---------+------------+---------|
|4     |18885  |no        |0      |yes        |1     |24    |0        |0           |0        |
|------+-------+----------+-------+-----------+------+------+---------+------------+---------|
|Sum   |5      |0         |0      |           |1     |124   |0        |0           |0        |
+--------------------------------------------------------------------------------------------+

You could check the PID on the system to see how long that has been running with this:

ps aux | grep #####

For example, that 18873 process on my example machine is one of the main Apache processes that has been running for 24 hours:

# ps aux | grep 18873
nobody   18873  0.0  0.3 709672  7248 ?        Sl   Jul06   0:00 /usr/sbin/httpd -k start