diff options
Diffstat (limited to 'www/loadmgmt.md')
| -rw-r--r-- | www/loadmgmt.md | 96 |
1 files changed, 96 insertions, 0 deletions
diff --git a/www/loadmgmt.md b/www/loadmgmt.md new file mode 100644 index 0000000..c81fdfc --- /dev/null +++ b/www/loadmgmt.md @@ -0,0 +1,96 @@ +# Managing Server Load + +A Fossil server is very efficient and normally presents a very light +load on the server. The Fossil [self-hosting server][sh] is a 1/24th +slice VM at [Linode.com][lin] hosting 65 other repositories in addition +to Fossil, including some very high-traffic sites such as +<http://www.sqlite.org> and <http://system.data.sqlite.org>. This small +VM has a typical load of 0.05 to 0.1. A single HTTP request to Fossil +normally takes less than 10 milliseconds of CPU time to complete, so +requests can be arriving at a continuous rate of 20 or more per second, +and the CPU can still be mostly idle. + +However, there are some Fossil web pages that can consume large amounts +of CPU time, especially on repositories with a large number of files or +with long revision histories. High CPU usage pages include +[`/zip`](/help/zip), [`/tarball`](/help/tarball), +[`/annotate`](/help/annotate), and others. On very large repositories, +these commands can take 15 seconds or more of CPU time. If these kinds +of requests arrive too quickly, the load average on the server can grow +dramatically, making the server unresponsive. + +Fossil provides two capabilities to help avoid server overload problems +due to excessive requests to expensive pages: + +1. An optional cache is available that remembers the 10 most recently + requested `/zip` or `/tarball` pages and returns the precomputed + answer if the same page is requested again. + +2. Page requests can be configured to fail with a + “[503 Server Overload][503]” HTTP error if any request is + received while the host load average is too high. + +Both of these load-control mechanisms are turned off by default, but +they are recommended for high-traffic sites. Users with [admin +permissions](caps/index.md) are exempt from these restrictions, +provided they are logged in before the load gets too high (login is +disabled under high load). + +The webpage cache is activated using the [`fossil cache init`](/help/cache) +command-line on the server. Add a `-R` option to +specify the specific repository for which to enable caching. If running +this command as root, be sure to “`chown`” the cache database to give +the Fossil server write permission for the user ID of the web server; +this is a separate file in the same directory and with the same name as +the repository but with the “`.fossil`” suffix changed to “`.cache`”. + +To activate the server load control feature visit the Admin → Access +setup page in the administrative web interface; in the “**Server Load +Average Limit**” box enter the load average threshold above which “503 +Server Overload” replies will be issued for expensive requests. On the +self-hosting Fossil server, that value is set to 1.5, but you could +easily set it higher on a multi-core server. + +The maximum load average can also be set on the command line using +commands like this: + + fossil setting max-loadavg 1.5 + fossil all setting max-loadavg 1.5 + +The second form is especially useful for changing the maximum load +average simultaneously on a large number of repositories. + +Note that this load-average limiting feature is only available on +operating systems that support the [`getloadavg()`][gla] API. Most +modern Unix systems have this interface, but Windows does not, so the +feature will not work on Windows. + +Because Linux implements `getloadavg()` by accessing the `/proc/loadavg` +virtual file, you will need to make sure `/proc` is available to the +Fossil server. The most common reason for it to not be available is that +you are running a Fossil instance [inside a `chroot(2)` +jail](./chroot.md) and you have not mounted the `/proc` virtual file +system inside that jail. On the [self-hosting Fossil repositories][sh], +this was accomplished by adding a line to the `/etc/fstab` file: + + chroot_jail_proc /home/www/proc proc ro 0 0 + +The `/home/www/proc` pathname should be adjusted so that the `/proc` +component is at the root of the chroot jail, of course. + +To see if the load-average limiter is functional, visit the +[`/test-env`][hte] page of the server to view the current load average. +If the value for the load average is greater than zero, that means that +it is possible to activate the load-average limiter on that repository. +If the load average shows exactly "0.0", then that means that Fossil is +unable to find the load average. This can either be because it is in a +`chroot(2)` jail without `/proc` access, or because it is running on a +system that does not support `getloadavg()` and so the load-average +limiter will not function. + + +[503]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.4 +[hte]: /help/www/test-env +[gla]: https://linux.die.net/man/3/getloadavg +[lin]: http://www.linode.com +[sh]: ./selfhost.wiki |
