Skip to content
David Cook edited this page Sep 2, 2024 · 4 revisions

Timeouts

One common problem are timeouts. If a shop doesn't load after adding a bunch of products to the order cycle or you can't edit the cart while shopping a lot, the server might struggle dealing with these requests. If a timeout occurs, the server often seems to be very busy and the browser might receive a server error. These errors are not shown in the log file or reported to Bugsnag. The timeout is set by the unicorn_timeout variable in your vars file. You can change in on your server:

ssh example.com
vi apps/openfoodnetwork/shared/config/unicorn.rb  # change timeout
service unicorn_openfoodnetwork stop
sleep 3
service unicorn_openfoodnetwork start

If that solves the problem, you might want to upgrade your server or help us improve the performance of the code. Your problems may also be solved by updating your version of OFN.

Memory

Your server might not have enough memory if you see a message like this:

Errno::ENOMEM: Cannot allocate memory

There are several solutions to this.

  • Add a swap file: If you run out of memory during a deploy or other administration tasks, extending your memory with a swap file is the easiest solution. Your tasks will be slow, but not crash. So do this only for infrequent tasks.
  • Restart the server / the app: If your server is running for a long time, it might occupy more memory than it actually needs. While we are working on methods to reduce the long-term memory usage, a restart may still help in the short term.
  • Upgrade the server: If you face memory shortages frequently, you have to upgrade the server. Have a look at our current server specifications to get an idea of what is needed.
  • Optimise the code: You are more than welcome to improve the performance of the Open Food Network and open a pull request.

Disk space

The most common large use of disk space is old gems. These are not (currently) automatically cleaned up and can take up several gigabytes. The quick and easy way is to delete the directories for any unused ruby versions, eg:

df -h # check usage before
/home/openfoodnetwork/.gem/ruby$ sudo rm -rf 2.* 
df -h # and after

A tool like ncdu is helpful for tracking down large files. Other things to look for are:

  • Ruby versions (~/.rbenv/versions/)
  • Unused temporary files like database dumps in /tmp or anywhere under the home dir.
  • Backups from previous releases (apps/openfoodnetwork/releases-old/, these include lots of node_modules)

If the instance is configured to store images in the filesystem, there might be a lot there. Are old images cleaned up?