Apache Mod_fcgid Can't Apply Process Slot For

4/6/2022admin

Apache Mod_fcgid Can't Apply Process Slot Form
Apache Mod_fcgid Can't Apply Process Slot For Real
Apache Mod_fcgid Can't Apply Process Slot For Cash

7mod_fcgid configuration settings
9Apache Event with FCGI Optimization Guide
- 9.6Troubleshooting and Caveats
  - 9.6.1Using a Custom / Local php.ini with FCGI on cPanel
  - 9.6.4Apache.org Special Considerations
10Plesk

Modfcgid: can't apply process slot after software upgrade 0 Increasing FcgidMaxProcesses does not help to solve “modfcgid: can't apply process slot” error. エラーログに modfcgid: can't apply process slot for /var/www/cgi-bin/cgiwrapper/cgiwrapper と表示された場合、fcgidのプロセスが足りないの. Also I noted that each 'httpd apache' process has 9 MB swap. Although process runs for only 1 second or 2-3 seconds it swaps 9 mb. 4254 apache 20 0 335m 4000 1892 S 0.0 0.4 0:00.01 9m httpd.

FCGI Overview

FCGI is one of many PHP handlers that Apache can use to interpret PHP code. The handlers are responsible for reading / interpreting PHP code then compiling it and executing the code. Selecting the best PHP handler for your server is critical to overall performance.

Once mod_fcgid is enabled, all PHP processing is done via the FastCGI protocol. mod_fcgid starts up a certain amount of persistent processes that listen for new PHP requests and process them when needed. These processes remain alive even if there are no PHP requests, so you must make sure you configure FCGID to run an appropriate amount of processes, otherwise the server might waste a lot of resources on idle PHP processes.

Generally speaking, you should keep a few (2 or 3) idle FCGID processes running to quickly respond to new requests, that way you limit idle resource usage, but still allow for FCGID to spawn more processes if traffic picks up. To determine the maximum FCGID processes you will want to determine how much Memory the average PHP process uses, then divide the available server RAM by this number.

There is no benefit in setting the max process limit too high, otherwise you will risk server instability, especially if it starts to utilize swap space due to lack of RAM. Generally 10 or 20 max FCGID processes is a good place to start.

Why FCGI instead of SuPHP?

Because FCGI is faster (3 - 5 times faster) than SuPHP.

Because FCGI has persistent processes, opcode caching is much more effective. Meaning less CPU is used to serve PHP.

Most distributions shipping in 2013 provide precompiled packages that let you run php with fcgid. If you look around you will see that in general, no one really suggests using DSO or suphp because there are better alternatives out there such as fcgi and PHP-FPM.

In a perfect world, cPanel would already have support for PHP-FPM, while it's possible to use PHP-FPM on cPanel, it's not officially built in and could potentially break lots of things down the road. Because of that we are stuck with FCGI for the time being.

FCGI is significantly faster than suPHP, and runs PHP as the user. In general you can swap out suPHP for FCGI and vice versa without having to modify file permissions or worry about sites breaking. There may be some cases where FCGI does not work with a customer's site, but a vast majority of the time FCGI should be the go to option.

A picture is worth 1000 words :D

FCGI Benefits

Huge performance boost, both in CPU and memory consumption

PHP runs as the user, just like suphp, assuming SuEXEC is enabled

Since FCGI processes are separate from Apache processes, we can fine tune the maximum amount of resources we want PHP to use, but still let Apache serve static content. You cannot do this with suphp unless you severly restrict Apache Max Clients, which generally is not worth messing around with.

FCGI Considerations for Shared Servers

One thing to keep in mind if you plan on using FCGI on a server that has say, 21 + cPanel accounts on it. If the server has 1GB of RAM, you might set FcgidMaxProcesses to 20 to limit memory usage and prevent too many requests from locking up the server due to too much swap usage, or overloading your CPU.

This is all fine in most cases, but what happens if 20 of the sites already has a PHP process running as their own user, and someone tries to view website #21? Nothing happens, the website will hang and try and load for a long time, waiting for one of the occupied 20 FCGI processes to die off and be reborn again so it can serve user #21. In some cases this take be a minute or more. Obviously this is not a good thing, customer #21 is going to be mad their site doesn't load.

Why does this happen? Because of the way FCGI handles processes and what to do with them once they are done handling requests. For a single website, the ideal FCGI configuration would be to create 10 processes, or however many you want, then set their life time to a large number, like 600 seconds or more. You would do this because of opcode caching, it's best to reuse cached PHP as much as possible to reduce CPU load.

For a shared server though, long running PHP processes are not ideal unless you have enough memory to give every user a single FCGI process, but if you have limited memory and 1000 cpanel accounts, that's not going to be possible since 1000 processes using 32MB each is probably more than 2GB or whatever small amount of memory your server might have.

If you have a server with limited memory and lots of cpanel accounts and you can't set FcgidMaxProcesses to a value higher than the # of users, then your only option is to significantly reduce the timeouts, lifetimes and increase scan intervals to kill off idle processes faster, and create new processes sooner.

While I can't say this would be the best configuration, I will say that it will reduce the chances of a 'spinning website' or one that takes 30 seconds to load. By using 5 second intervals the worst case would be a 5 second delay, which sucks, a lot, but it's better than 30 seconds or more. For this to happen, 21 people all over the world would need visit 20 sites on your server within the same 5 seconds, then one other person would need to visit site #21 to run into the issue I described above, but it can happen.

Anyway, if this sounds like the problem you are having, try to use very low idle timeout and process lifetimes, this may reduce performance a but, but FCGI is still WAAAAY better than SuPHP.

A lot of the configuration settings above were inspired by - http://events.linuxfoundation.org/sites/events/files/slides/AC2014-FastCGI.pdf
And jpurkis!

I ran some quick tests to try and show how the IdleScanInterval and IdleTimeout settings can effect website load time. The results below were gathered on a cPanel server. I created 15 accounts and installed WordPress on each account. I then configured cPanel to use FCGI as the PHP handler and enabled PHP 5.5's built in OPcache. I limited FcgidMaxProcesses to 10 to replicate the issue. The theory was that after I curl the first 10 test sites, the other 5 sites would take significantly longer to load because the 10 FCGI processes would remain idle until the timeouts / scans decided it was time to kill the process off.

New processes can only be created once one of the existing 10 processes dies. As you can see here the most dramatic improvement happened when I lowered IdleTimeout from 300 (Orange Column) to 30 (Yellow Column). The longest delay between a page load dropped from 1 minute to 35 seconds.

Since IdleTimeout seems to be a huge factor, I lowered it again, from 30 seconds to 3 seconds (Blue Column). As you can see the delay dropped from 35 seconds to 9 seconds. Not bad, but if my website took 9 seconds to load, or even begin to display content I would not be happy. The green column looks much better, with a delay of 3 seconds. If you want to have the green column performance, you can have it! Below this section are some configurations based on various amounts of RAM which will provide good performance and will quickly kill off idle FCGI processes so that new ones can be created.

This is not an issue that will happen very often. The script I used is requesting 15 webpages as fast as it can. For the same situation to happen in the real world, 15 people would need to request 15 sites on your server within the same 6 seconds to notice a slight delay. On servers with a lot of traffic, this might be a common thing to have happen, but I'm testing out these settings for a 1GB VPS server, which is rather small. If I had 2GB of memory I would have raised FcgidMaxProcesses to at least 20, and none of this would be an issue.

Enabling and Configuring FCGI on a cPanel Server

The first thing to check is whether or not FCGI is listed as an available PHP handler. Run this command to see what the current handler is, and what handlers are available.

If you see fcgi listed, you can switch to it like so:

If you do not see fcgi listed then you will need to run EasyApache and select Mod FastCGI. I also recommend upgrading PHP to at least 5.5 and making sure that Apache is updated to at least version 2.4 with the EVENT MPM enabled.

These suggestions assume the customer is running on a relatively updated cpanel server. If they are using a very old version then some of the steps may not apply, if that is the case I highly recommend you get WHM / cPanel updated to the lastest version.

Make sure updating PHP is ok with the customer, some sites might be using older CMS, so make sure sites load after you apply these settings. If the customer must be at PHP 5.3 or 5.4 that's ok, but in general newer versions of PHP are faster and more secure.

Once EA is done you will want to run this command to make sure EVENT is in use.

The image below shows the default WHM configuration, using SuPHP as the handler. I have already ran EA, so FCGI is listed here, if it is not listed then you need to rerun EA and select Mod FastCGI. Anyway, make sure this is set to FCGI, then click 'save new configuration'. This usually takes less than 10 seconds to switch over. SuPHP and FCGI both use the same permissions for www/ so you should not need to update permissions before changing these two handlers.

If the server is using DSO, please follow the procedure in our wiki on how to update www permissions so that the change to FCGI will not result in broken websites.

Now it's time to configure fcgi and Apache Event default settings. To do this we will place both fcgi and event directives in /usr/local/apache/conf/includes/pre_virtualhost_global.conf. We are doing this to prevent cpanel settings from messing up our configuration, as cPanel likes to replace / remove some directives if they are placed in the main httpd.conf file.

If you are using Apache 2.4 Event with FCGI then the settings below should be a great starting point. If you are using Apache 2.2 then you may get some warnings about MaxRequestWorkers not being valid, if this is the case please remove the MaxRequestWorkers directive and replace with MaxClients. If the PHP memory limit is 128MB or higher then you might want to lower the FcgidMaxProcesses value, which sets the limit on how many PHP processes can run at once. If you set FcgidMaxProcesses too high you are allowing the server to go OOM which is NOT good.

/usr/local/apache/conf/php.conf includes a few fastcgi settings, this is what cPanel applies by default. You should not have to modify this file 99.99% of the time.

/usr/local/apache/conf/includes/pre_virtualhost_global.conf This is where we set fcgi directives like the ones covered in the sections below. By default cPanel does not really apply any settings other than what is shown below.

FcgidMaxRequestLen

If the size of the request body exceeds this amount, the request will fail with 500 Server Error. By default this is set to 131072 Bytes. For cPanel the default is 1073741824, which is about 1GB.

FcgidMaxProcessesPerClass

This directive sets the maximum number of processes that can be started for each process class, turns out that class means PER USER. If you have multiple users, or have a cPanel server please DO NOT USE THIS. Use FcgidMaxProcesses which sets the global limit. If you set the per class value, it gets multiplied by the amount of users. By default this value is set to 100. If you do not have lots of RAM, lower this to around 20 or so, assuming your app uses about 30MB per process.

FcgidMaxProcesses

This sets the global / server limit for how many PHP processes can run. Unlike the FcgidMaxProcessesPerClass directive, which is a per user limit, this directive is for all users. This is basically MaxClients but for PHP.

FcgidMaxRequestsPerProcess

FastCGI application processes will be terminated after handling the specified number of requests. By default this is set to 0 which means there is no limit / check.

There is a known caveat that causes sites to throw what appears to be a random 500 Internal Server Error when running FCGI and the Apache, FCGI and PHP layers all do not agree on the amount of requests that should be sent to a process. One or another of each of the layers will expect another request be sent to the process, while the others expect the process to be recycled. By default this occurs every 500 requests on cPanel as the default cPanel FCGI Wrapper sets this directive to 500. The default max requests behavior of apache is 10,000 requests and the default PHP behavior is unlimited requests. The best way to avoid this caveat is to equalize all three layers so they agree on the number of requests a process should handle. My practice is to default this to the Apache default value of 10,000. However, if the PHP software being ran on the server has large memory leaking problems, this value may be too high so adjust it downward if needed. Setting this too low will cause PHP processes to be recycled too frequently during traffic spikes adding further load to an already busy system.

MaxRequestsPerChild :: This directive controls the apache layer's max request per process expectation
FcgidInitialEnv :: This directive is used to set environment values
- PHP_FCGI_MAX_REQUESTS :: This environment value controls the number of requests PHP expects a process to handle before being recycled.
- PHP_FCGI_CHILDREN :: This environment value controls how many children PHP should manage. We want to force this to 0 so that PHP does not prematurely recycle processes.

FcgidConnectTimeout

This is the maximum period of time the module will wait while trying to connect to a FastCGI application on Windows. (This directive is not respected on Unix, where AF_UNIX defaults will apply.)

FcgidIOTimeout

This is the maximum period of time the module will wait while trying to read from or write to a FastCGI application. If you have a slow application you may want to raise this, however 40 seconds is plenty of time. IF you site / app takes 40 seconds to load then odds are no one will ever want to visit your site again. (Either that, or you have a back-end application that takes awhile to run.. large report crons immediately come to mind) This is what you are hitting if you get 'mod_fcgid: read data timeout in 40 seconds' errors.

FcgidIdleTimeout

Application processes which have not handled a request for this period of time will be terminated, if the number of processses for the class exceeds FcgidMinProcessesPerClass. A value of 0 disables the check. The default value is 300 seconds.

FcgidMinProcessesPerClass

This directive sets the minimum number of processes that will be retained in a process class after finishing requests. By default the value is 3.

In a cpanel server, the 'class' it refers to is the domain-user. Up to this number of processess will be kept alive, even if they would otherwise be closed because of the various idle or lifetime timeouts. As a result, it is strongly recommended that you set this value to 0, unless the server is dedicated to a single, or relatively few, sites (or domain users).

Generally you do not want to raise this value past 3 unless the website is getting tons of traffic and you start to notice time out issues with the website. On a shared server with many websites and cPanel users you will want to start with 1 Process Per Class. If there are 100 cPanel Users on the server, that means there could be up to 100 PHP processes running at any given time.

FcgidProcessLifeTime

Idle application processes which have existed for greater than this time will be terminated, if the number of processses for the class exceeds FcgidMinProcessesPerClass. A value of 0 disables the check. By Default this is set to 3600, if you want to save RAM you can set this to something like 30 to kill off unused processes

FcgidIdleScanInterval

This is the interval at which the module will search for processes which have exceeded FcgidIdleTimeout or FcgidProcessLifeTime. The default is 120 seconds, you can lower this if you want shorter living processes.

FcgidOutputBufferSize

A common issue that occurs when FCGI and PHP do not agree with each other on the size of their output buffers. By default, the FCGI output buffer is very small: 64 bytes. By default the PHP output_buffering is off. However, if anything changes the php output_handler or an output_buffering function is used, (typically compression software) PHP's default behavior is to automatically switch output_buffering to On without a size limit. When this occurs and the buffered data is larger than the FCGI buffer (which most everything is larger than 64 bytes) PHP will exit unexpectedly terminating additional script processing. This will also cause FCGI to spawn a new PHP process to replace the recently terminated one. You can see evidence of this occurring in the Apache error logs like this:

Should the a site use significant output_buffering, the server can easily become over-loaded filling up with PHP processes as they are constantly terminated and started. Driving the load levels of the system up.

This is remedied by getting FCGI to accept a large enough buffer for the software that is running. The buffer size should be at-least equal to or larger than the defined PHP memory_limit directive. Below is a sample of setting the buffer to 1G which should cover most scenarios:

You will of course need to stop/start apache for this to take affect, but it should resolve the majority of errors this situation produces.

FcgidFixPathInfo

This directive is commonly mis-configured. This is due to the a change in expected default behavior between PHP versions. Apache describes this directive as follows:

This directive enables special SCRIPT_NAME processing which allows PHP to provide additional path information. The setting of FcgidFixPathinfo should mirror the cgi.fix_pathinfo setting in php.ini.

The default value for FcgidFixPathInfo is 0 which matches that of the default value of cgi.fix_pathinfo in some older versions of PHP. Since PHP 5.4 the default value of cgi.fix_pathinfo is now 1 instead of 0. So out of the box this directive comes misconfigured on modern systems. Typically, you will just need to set this directive to 1 to correct the problem. However, since cgi.fix_pathinfo can be changed as with all php directives. It's good practice to verify in the system php.ini (and any custom php.ini files) that the cgi.fix_pathinfo directive is unset (which is equal to 1). Setting the directive to one is as simple as:

However, if the php.ini defines cgi.fix_pathinfo=0 then you can either change the 1 from above to 0 or remove the directive all together.

FcgidCmdOptions (app/script specific config)

If you find yourself in a situation where you need to adjust FCGI directives on a per application level this can be accomplished with: FcgidCmdOptions

The following example usage syntax sets specific variables/directives whenever FCGI executes the script: /home/user/public_html/index.php

InitialEnv MAX_REQUESTS=2000	Sets the shell variable MAX_REQUESTS to 2,000
MaxRequestsPerProcess 2000	Sets FcigMaxRequestsPerProcess to 2,000
IOTimeout 9	Sets FcgidIOTimeout to 9

At the time of this writing, the following table outlines what directives/variables can be set in this manner:

Option name and syntax	Corresponding Directive
ConnectTimeout seconds	FcgidConnectTimeout
IdleTimeout seconds	FcgidIdleTimeout
InitialEnv name[=value]	FcgidInitialEnv
IOTimeout seconds	FcgidIOTimeout
MaxProcesses value	FcgidMaxProcessesPerClass
MaxProcessLifeTime seconds	FcgidProcessLifeTime
MaxRequestsPerProcess value	FcgidMaxRequestsPerProcess
MinProcesses value	FcgidMinProcessesPerClass

Unfortunately, this directive cannot exist within .htaccess files so you will need to add it to an appropriate location within an apache include file. (e.g. /usr/local/apache/conf/includes/pre_virtualhost_global.conf). It is also good practice to enclose these statements within IfModule statements to allow for a more portable configuration file.

Use Apache 2.4.12 with the Event MPM if possible

Use FCGI as the PHP handler

If possible, upgrade the server to PHP 5.5 or newer. In some cases this might not be possible, as some CMS still needs PHP 5.4, and will break with PHP 5.5. If the server is using PHP 5.4 and the customer doesn't want to upgrade to 5.5 / knows some sites will break, that's fine, leave PHP at 5.4.

Enable Zend OPcache for PHP 5.5 PHP 5.4 doesn't have a built in opcache like 5.5, which is why we suggest using PHP 5.5. If you can't use PHP 5.5 then I suggest utilizing Xcache or APC instead. Any type of opcode cache is better than none!

Please make sure you are apply these settings in WHM if possible. If you do not know where this section is in WHM, please reference the image below.

1GB Server

If the server already has PHP 5.5+, enable Zend OPcache. If it does not have PHP 5.5 then suggest upgrade to client, if upgrading is not possible, or will break websites, stick with PHP 5.4 and look into using Xcache or APC instead of opcache. Also, make sure that mod_fastcgi has been select in EasyApache, once that has been done you should be able to select FCGI as the PHP handler.

If the server is running PHP 5.5, modify the main php.ini file

Add this to the bottom of the ini file, then restart apache. The opcache.so extension should already exist on the server if PHP 5.5 is updated. The actual location of the extension is /usr/local/lib/php/extensions/no-debug-non-zts-20121212/opcache.so but to enable it all you should have to do is paste in the code below.

The next step is to use Apache Event, don't worry about Apache settings, but make sure you use FCGI as PHP handler and set these limits to prevent the server from running out of memory. These settings are for apache event 2.4 and may not work for apache event 2.2. If that is the case and you run into errors when applying these settings you should remove any <prefork> or <worker> directives in /usr/local/httpd/conf/httpd.conf and also remove any <event> settings in pre_virtualhost_global.conf. Yep, that's right, the best way to optimize apache event is to not even try and optimize it!. The settings below are default settings, so if you can apply them please do so just so someone doesn't think there aren't optimizations in place.

Please use WHM Pre VirtualHost Include Editor to apply the FCGI and Apache settings. If you apply these settings to another includes file that's not visible via WHM, there may be issues down the road with conflicting settings.