|
1
|
# Managing Server Load |
|
2
|
|
|
3
|
A Fossil server is very efficient and normally presents a very light |
|
4
|
load on the server. The Fossil [self-hosting server][sh] is a 1/24th |
|
5
|
slice VM at [Linode.com][lin] hosting 65 other repositories in addition |
|
6
|
to Fossil, including some very high-traffic sites such as |
|
7
|
<http://www.sqlite.org> and <http://system.data.sqlite.org>. This small |
|
8
|
VM has a typical load of 0.05 to 0.1. A single HTTP request to Fossil |
|
9
|
normally takes less than 10 milliseconds of CPU time to complete, so |
|
10
|
requests can be arriving at a continuous rate of 20 or more per second, |
|
11
|
and the CPU can still be mostly idle. |
|
12
|
|
|
13
|
However, there are some Fossil web pages that can consume large amounts |
|
14
|
of CPU time, especially on repositories with a large number of files or |
|
15
|
with long revision histories. High CPU usage pages include |
|
16
|
[`/zip`](/help/zip), [`/tarball`](/help/tarball), |
|
17
|
[`/annotate`](/help/annotate), and others. On very large repositories, |
|
18
|
these commands can take 15 seconds or more of CPU time. If these kinds |
|
19
|
of requests arrive too quickly, the load average on the server can grow |
|
20
|
dramatically, making the server unresponsive. |
|
21
|
|
|
22
|
Fossil provides two capabilities to help avoid server overload problems |
|
23
|
due to excessive requests to expensive pages: |
|
24
|
|
|
25
|
1. An optional cache is available that remembers the 10 most recently |
|
26
|
requested `/zip` or `/tarball` pages and returns the precomputed |
|
27
|
answer if the same page is requested again. |
|
28
|
|
|
29
|
2. Page requests can be configured to fail with a |
|
30
|
“[503 Server Overload][503]” HTTP error if any request is |
|
31
|
received while the host load average is too high. |
|
32
|
|
|
33
|
Both of these load-control mechanisms are turned off by default, but |
|
34
|
they are recommended for high-traffic sites. Users with [admin |
|
35
|
permissions](caps/index.md) are exempt from these restrictions, |
|
36
|
provided they are logged in before the load gets too high (login is |
|
37
|
disabled under high load). |
|
38
|
|
|
39
|
The webpage cache is activated using the [`fossil cache init`](/help/cache) |
|
40
|
command-line on the server. Add a `-R` option to |
|
41
|
specify the specific repository for which to enable caching. If running |
|
42
|
this command as root, be sure to “`chown`” the cache database to give |
|
43
|
the Fossil server write permission for the user ID of the web server; |
|
44
|
this is a separate file in the same directory and with the same name as |
|
45
|
the repository but with the “`.fossil`” suffix changed to “`.cache`”. |
|
46
|
|
|
47
|
To activate the server load control feature visit the Admin → Access |
|
48
|
setup page in the administrative web interface; in the “**Server Load |
|
49
|
Average Limit**” box enter the load average threshold above which “503 |
|
50
|
Server Overload” replies will be issued for expensive requests. On the |
|
51
|
self-hosting Fossil server, that value is set to 1.5, but you could |
|
52
|
easily set it higher on a multi-core server. |
|
53
|
|
|
54
|
The maximum load average can also be set on the command line using |
|
55
|
commands like this: |
|
56
|
|
|
57
|
fossil setting max-loadavg 1.5 |
|
58
|
fossil all setting max-loadavg 1.5 |
|
59
|
|
|
60
|
The second form is especially useful for changing the maximum load |
|
61
|
average simultaneously on a large number of repositories. |
|
62
|
|
|
63
|
Note that this load-average limiting feature is only available on |
|
64
|
operating systems that support the [`getloadavg()`][gla] API. Most |
|
65
|
modern Unix systems have this interface, but Windows does not, so the |
|
66
|
feature will not work on Windows. |
|
67
|
|
|
68
|
Because Linux implements `getloadavg()` by accessing the `/proc/loadavg` |
|
69
|
virtual file, you will need to make sure `/proc` is available to the |
|
70
|
Fossil server. The most common reason for it to not be available is that |
|
71
|
you are running a Fossil instance [inside a `chroot(2)` |
|
72
|
jail](./chroot.md) and you have not mounted the `/proc` virtual file |
|
73
|
system inside that jail. On the [self-hosting Fossil repositories][sh], |
|
74
|
this was accomplished by adding a line to the `/etc/fstab` file: |
|
75
|
|
|
76
|
chroot_jail_proc /home/www/proc proc ro 0 0 |
|
77
|
|
|
78
|
The `/home/www/proc` pathname should be adjusted so that the `/proc` |
|
79
|
component is at the root of the chroot jail, of course. |
|
80
|
|
|
81
|
To see if the load-average limiter is functional, visit the |
|
82
|
[`/test-env`][hte] page of the server to view the current load average. |
|
83
|
If the value for the load average is greater than zero, that means that |
|
84
|
it is possible to activate the load-average limiter on that repository. |
|
85
|
If the load average shows exactly "0.0", then that means that Fossil is |
|
86
|
unable to find the load average. This can either be because it is in a |
|
87
|
`chroot(2)` jail without `/proc` access, or because it is running on a |
|
88
|
system that does not support `getloadavg()` and so the load-average |
|
89
|
limiter will not function. |
|
90
|
|
|
91
|
|
|
92
|
[503]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.4 |
|
93
|
[hte]: /help/www/test-env |
|
94
|
[gla]: https://linux.die.net/man/3/getloadavg |
|
95
|
[lin]: http://www.linode.com |
|
96
|
[sh]: ./selfhost.wiki |
|
97
|
|