QOS and CGI Application Resources

Process, memory, and CPU (run-time) are some of the mechanisms we utilize to ensure quality of service (QOS) guarantees for your site. Most hosting providers who offer a shared hosting product do not use QOS mechanisms, or employ broken implementations that can result in runaway CGI applications that can quickly bring an entire server to a grinding halt. We believe we are the only hosting provider with a rock solid QOS solution for sites hosted in a shared hosting environment. We have made extensive changes to the Apache server to support this model and in turn ensure that the operation of your site is not interrupted by another "out of control" site hosted on the same server. NetGate uses proprietary technology to ensure that process, memory, and CPU quotas are working correctly to ensure the proper operation of your site. The NetGate QOS implementation provides a real difference in the hosting services market and brings a significant benefit to our customers.

All NetGate hosting accounts include a fixed number of system resources (memory, CPU time, and concurrent processes). The current base resource allocations are:

VP/FBX, VP/FBXE, VP/MB, VP/SA

VP/FB

Concurrent Processes

If your site is attempting to use more processes than are allocated visitors to your site who attempt to execute a CGI application will see a page explaining that your site is experiencing a temporary resource allocation problem instead of the output from your application as they expected. Here is an example of the page displayed when you exceed your process quota.

Website Error

The website www.netgate.net encountered a temporary resource allocation failure and was unable to complete your request. Please retry your request later.

Please contact the server administrator, webmaster@netgate.net and provide them with the following error information.

Error: Temporary resource allocation failure
Time: Wed Mar 28 00:06:09 2001
CGI Application: /cgi-bin/maxrsc
Error log: cgi_log

More information about this error may be available in the CGI process log file (cgi_log).

If you don't like that message you can replace the default text with your own page. Simply create a file named "maxrsc.html" in your "www" directory and that page will be displayed in the event of a resource allocation error instead of the above text.

Process Logging and Resource Tracking

There are two log files that you will want to check to see if your site is using more system resources than are available given your current allocation. The first is your "error_log" file located in your "raw logs" directory. The exact directory location is:

"/usr/local/apache/logs/site_name/http_error_log"

where "site_name" is the full name of your site (i.e. "www.mysite.com"). This file is used by the web server to store any errors related to your site. Use this file to track down CGI applications that are failing due to coding errors, memory quota issues, or CPU quota time exceeded related errors. It's a good idea to check this log file on a regular basis for problems with your site.

The second is the CGI error log located in:

"/usr/local/apache/logs/site_name/cgi_log"

where "site_name" is the full name of your site (i.e. "www.mysite.com"). The cgi_log file contains specific information related to the execution of CGI processes. It logs each execution and provides you with statistics that show the number of concurrent processes as well as any over quota (concurrent process) errors. If you are running out of processes the events will be logged in the CGI log (cgi_log) file with the following information:

[A failed CGI application execution]

[2000-02-24 09:36:05]: uid: (brooks/brooks) gid: (vuser/vuser) cmd: ads.pl
[2000-02-24 09:36:05]: uid: (brooks) Max proc limit = 5
[2000-02-24 09:36:05]: uid: (brooks) Current number of running procs (5)
[2000-02-24 09:36:05]: uid: (brooks) CGI execution failed, max procs exceeded, current procs >= max procs (5 >= 5)

[A successful CGI application execution]

[2000-02-24 09:36:05]: uid: (brooks/brooks) gid: (vuser/vuser) cmd: ads.pl
[2000-02-24 09:36:05]: uid: (brooks) Max proc limit = 5
[2000-02-24 09:36:05]: uid: (brooks) Current number of running procs (2)

Notice that the failed attempt to run the "ads.pl" application caused an additional line to be put into the CGI log file. The error displayed explains that you are currently running the maximum allowed number of concurrent processes (5). Since allowing the "ads.pl" application to execute would cause a 6th process to run the execution fails resulting in the error page and the log entry.

Process Quota Exceeded Notification

Because we believe you would want to know if you are exceeding your process quota we have implemented a customer notification mechanism. The event notifier runs nightly and will notify you via e-mail in the event you exceed your process quota.

What Now

If your site is exceeding the number of processes you have allocated to your account you have a choice. To support the site you will either need to purchase additional processes, limit the CGI applications you use, or live with the limits and the occasional failed script execution.

One common cause of exceeding process quotas that can easily be fixed is the case where your Perl script is attempting to execute a program from within the script when it itself is the last process allowed to run. Perl is a great programming language but it seems to lack the ability to understand that there may be limits that prevent it from executing the sub process. As a result the original script hangs waiting for the sub process to complete (never to happen) and consumes one of your available process slots. If this happens enough times all your available process slots will be used resulting in the failure of all your scripts. Fortunately, the fix is simple. Just make sure you add the following code to all your Perl scripts.

use CGI::Carp qw(fatalsToBrowser);

$SIG{'ALRM'} = sub {
syswrite(STDERR, "Caught SIGALAM in script info.cgi\n", 33);
die "My script detected an unrecoverable error - (this message is sent to browser)";
exit (-1);
};

alarm(5);

This sets a 5 second alarm event in the script. This will prevent the script from executing for more than 5 seconds and thus will prevent it from getting into an infinite loop. You can adjust the timer as needed. You can also change the error returned to the error_log by changing the text in the syswrite command, and the error returned to the web browser by changing the line in the die command. Please note that the syswrite command needs to know how many bytes it is writing. In this example there are 33 bytes of text being written, you may have to adjust this if you change the message.

Using the above code your visitors would see the following error displayed in their browser:

Software error:

My script detected an unrecoverable error at info.cgi line 20.
For help, please send mail to the webmaster (webmaster@netgate.net), giving this error message and the time and date of the error.

And the following error would be logged to your http error log file:

Caught SIGALAM in script info.cgi[Wed Mar 28 01:24:54 2001] info.cgi: Fatal error messages are now sent to browser at info.cgi line 20.

Purchasing Additional Process

Additional processes can be purchased in blocks of five additional concurrent processes. For current pricing please send an e-mail to sales@netgate.net.