Fossil SCM
Add documentation (at [/doc/trunk/www/server.wiki#loadmgmt]) on how to use the new load-average limiter feature.
Commit
936fdaeef776eef7c458030d7d6261e631974b51
Parent
1847552c9239682…
1 file changed
+67
+67
| --- www/server.wiki | ||
| +++ www/server.wiki | ||
| @@ -241,6 +241,73 @@ | ||
| 241 | 241 | <p> |
| 242 | 242 | For more information, see <a href="./ssl.wiki">Using SSL with Fossil</a>. |
| 243 | 243 | </p> |
| 244 | 244 | </blockquote> |
| 245 | 245 | |
| 246 | +<a name="loadmgmt"></a> | |
| 247 | +<h2>Managing Server Load</h2><blockquote> | |
| 248 | +<p> | |
| 249 | +A Fossil server is very efficient and normally presents a very light | |
| 250 | +load on the server. | |
| 251 | +The Fossil [selfhost.wiki | self-host server] is a 1/24th slice VM at | |
| 252 | +[http://www.linode.com | Linode.com] hosting 65 other repositories in | |
| 253 | +addition to Fossil (and including some very high-traffic sites such | |
| 254 | +as [http://www.sqlite.org] and [http://system.data.sqlite.org]) and | |
| 255 | +it has a typical load of 0.05 to 0.1. A single HTTP request to Fossil | |
| 256 | +normally takes less than 10 milliseconds of CPU time to complete. So | |
| 257 | +requests can be arriving at a continuous rate of 10 or 20 per second | |
| 258 | +without significantly burdening the server. | |
| 259 | +<p> | |
| 260 | +However, there are some Fossil web pages that can consume large | |
| 261 | +amounts of CPU time, expecially on repositories with a large number | |
| 262 | +of files or with long revision histories. High CPU usage pages include | |
| 263 | +[/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball], | |
| 264 | +[/help?cmd=/annotate | /annotate] and others. On very large repositories, | |
| 265 | +these commands can take 15 seconds or more of CPU time. | |
| 266 | +If these kinds of requests arrive too quickly, the load average on the | |
| 267 | +server can grow dramatically, making the server unresponsive. | |
| 268 | +<p> | |
| 269 | +To help avoid problems, Fossil has the ability to fail CPU-intensive | |
| 270 | +web page requests with a | |
| 271 | +[http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.3 | "503 Server Overload"] | |
| 272 | +HTTP error if an expensive request is received while the host load | |
| 273 | +average is too high. To activate this | |
| 274 | +feature, visit the /Admin/Access setup page in the administrative web | |
| 275 | +interface and in the "<b>Server Load Average Limit</b>" box | |
| 276 | +enter the load average threshold above which "503 Server | |
| 277 | +Overload" replies will be issued for expensive requests. On the | |
| 278 | +self-host Fossil server, that value is set to 1.5. But you could easily | |
| 279 | +set it higher on a multi-core server. | |
| 280 | +<p> | |
| 281 | +The maximum load average can also be set on the command line using | |
| 282 | +commands like this: | |
| 283 | +<blockquote><pre> | |
| 284 | +fossil set max-loadavg 1.5 | |
| 285 | +fossil all set max-loadavg 1.5 | |
| 286 | +</pre></blockquote> | |
| 287 | +The second form is especially useful for changing the maximum load average | |
| 288 | +simultaneously on a large number of repositories. | |
| 289 | +<p> | |
| 290 | +Note that this load-average limiting feature is only available on operating | |
| 291 | +systems that support the "getloadavg()" API. Most modern unix systems have | |
| 292 | +this interface, but Windows does not, so the feature will not work on Windows. | |
| 293 | +Note also that Linux implements "getloadavg()" by accessing the "/proc/loadavg" | |
| 294 | +file in the "proc" virtual filesystem. If you are running a Fossil instance | |
| 295 | +inside a chroot() jail on Linux, you will need to make the "/proc" file | |
| 296 | +system available inside that jail in order for this feature to work. On | |
| 297 | +the self-hosting Fossil repository, this was accomplished by adding a line | |
| 298 | +to the "/etc/mtab" file that looks like: | |
| 299 | +<blockquote><pre> | |
| 300 | +chroot_jail_proc /home/www/proc proc r 0 0 | |
| 301 | +</pre></blockquote> | |
| 302 | +Pathnames should be adjusted for individual systems, of course. | |
| 303 | +<p> | |
| 304 | +To see if the load-average limiter is functional, visit the [/test_env] page | |
| 305 | +of the server to view the current load average. If the value for the load | |
| 306 | +average is greater than zero, that means that it is possible to activate | |
| 307 | +the load-average limiter on that repository. If the load average shows | |
| 308 | +exactly "0.0", then that means that Fossil is unable to find the load average | |
| 309 | +(either because it is in a chroot() jail without /proc access, or because | |
| 310 | +it is running on a system that does not support "getloadavg()") and so the | |
| 311 | +load-average limiter will not function. | |
| 312 | + | |
| 246 | 313 | </blockquote> |
| 247 | 314 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -241,6 +241,73 @@ | |
| 241 | <p> |
| 242 | For more information, see <a href="./ssl.wiki">Using SSL with Fossil</a>. |
| 243 | </p> |
| 244 | </blockquote> |
| 245 | |
| 246 | </blockquote> |
| 247 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -241,6 +241,73 @@ | |
| 241 | <p> |
| 242 | For more information, see <a href="./ssl.wiki">Using SSL with Fossil</a>. |
| 243 | </p> |
| 244 | </blockquote> |
| 245 | |
| 246 | <a name="loadmgmt"></a> |
| 247 | <h2>Managing Server Load</h2><blockquote> |
| 248 | <p> |
| 249 | A Fossil server is very efficient and normally presents a very light |
| 250 | load on the server. |
| 251 | The Fossil [selfhost.wiki | self-host server] is a 1/24th slice VM at |
| 252 | [http://www.linode.com | Linode.com] hosting 65 other repositories in |
| 253 | addition to Fossil (and including some very high-traffic sites such |
| 254 | as [http://www.sqlite.org] and [http://system.data.sqlite.org]) and |
| 255 | it has a typical load of 0.05 to 0.1. A single HTTP request to Fossil |
| 256 | normally takes less than 10 milliseconds of CPU time to complete. So |
| 257 | requests can be arriving at a continuous rate of 10 or 20 per second |
| 258 | without significantly burdening the server. |
| 259 | <p> |
| 260 | However, there are some Fossil web pages that can consume large |
| 261 | amounts of CPU time, expecially on repositories with a large number |
| 262 | of files or with long revision histories. High CPU usage pages include |
| 263 | [/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball], |
| 264 | [/help?cmd=/annotate | /annotate] and others. On very large repositories, |
| 265 | these commands can take 15 seconds or more of CPU time. |
| 266 | If these kinds of requests arrive too quickly, the load average on the |
| 267 | server can grow dramatically, making the server unresponsive. |
| 268 | <p> |
| 269 | To help avoid problems, Fossil has the ability to fail CPU-intensive |
| 270 | web page requests with a |
| 271 | [http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.3 | "503 Server Overload"] |
| 272 | HTTP error if an expensive request is received while the host load |
| 273 | average is too high. To activate this |
| 274 | feature, visit the /Admin/Access setup page in the administrative web |
| 275 | interface and in the "<b>Server Load Average Limit</b>" box |
| 276 | enter the load average threshold above which "503 Server |
| 277 | Overload" replies will be issued for expensive requests. On the |
| 278 | self-host Fossil server, that value is set to 1.5. But you could easily |
| 279 | set it higher on a multi-core server. |
| 280 | <p> |
| 281 | The maximum load average can also be set on the command line using |
| 282 | commands like this: |
| 283 | <blockquote><pre> |
| 284 | fossil set max-loadavg 1.5 |
| 285 | fossil all set max-loadavg 1.5 |
| 286 | </pre></blockquote> |
| 287 | The second form is especially useful for changing the maximum load average |
| 288 | simultaneously on a large number of repositories. |
| 289 | <p> |
| 290 | Note that this load-average limiting feature is only available on operating |
| 291 | systems that support the "getloadavg()" API. Most modern unix systems have |
| 292 | this interface, but Windows does not, so the feature will not work on Windows. |
| 293 | Note also that Linux implements "getloadavg()" by accessing the "/proc/loadavg" |
| 294 | file in the "proc" virtual filesystem. If you are running a Fossil instance |
| 295 | inside a chroot() jail on Linux, you will need to make the "/proc" file |
| 296 | system available inside that jail in order for this feature to work. On |
| 297 | the self-hosting Fossil repository, this was accomplished by adding a line |
| 298 | to the "/etc/mtab" file that looks like: |
| 299 | <blockquote><pre> |
| 300 | chroot_jail_proc /home/www/proc proc r 0 0 |
| 301 | </pre></blockquote> |
| 302 | Pathnames should be adjusted for individual systems, of course. |
| 303 | <p> |
| 304 | To see if the load-average limiter is functional, visit the [/test_env] page |
| 305 | of the server to view the current load average. If the value for the load |
| 306 | average is greater than zero, that means that it is possible to activate |
| 307 | the load-average limiter on that repository. If the load average shows |
| 308 | exactly "0.0", then that means that Fossil is unable to find the load average |
| 309 | (either because it is in a chroot() jail without /proc access, or because |
| 310 | it is running on a system that does not support "getloadavg()") and so the |
| 311 | load-average limiter will not function. |
| 312 | |
| 313 | </blockquote> |
| 314 |