Ticket #2485 (new defect)
Encourage leak containment by limiting the number of requests a CKAN process serves
Reported by: | nils.toedtmann | Owned by: | icmurray |
---|---|---|---|
Priority: | awaiting triage | Milestone: | ckan-v1.9 |
Component: | ckan | Keywords: | |
Cc: | pudo, amercader, seanhammond, kindly | Repository: | ckan |
Theme: | none |
Description (last modified by nils.toedtmann) (diff)
CKAN has memory leaks. They can be contained by limiting the time-to-live of a ckan process. An easy way to achieve this is to limit the number of requests a ckan server process can serve before it gets killed and replaced.
One should ...
- research ways to limit requests-per-process with the different web servers (see below for a start);
- explain these safeguards in the CKAN documentation and encourage users to apply them;
- consider the helper script ckan-create-instance to generate Apache configs with WSGIDaemonProcess ... maximum-requests=XY being active instead of commented out. Or at least let it warn the user to use MaxRequestsPerChild;
- Investigate current CKAN deployments whether they suffer from mem leaks, and if so contain them.
How to limit requests-per-process
- Apache:
- Use WSGIDaemonProcess with maximum-requests=50 or whatever limit is appropriate. We did this sucessfully on datahub.io and the ckan farm
- (This need to be verified) Without WSGIDaemonProcess, MaxRequestsPerChild 50 should achieve the same.
- nginx/supervisord: to be researched.
Change History
Note: See
TracTickets for help on using
tickets.