-
-
Notifications
You must be signed in to change notification settings - Fork 112
Troubleshooting
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.
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.
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 ofnode_modules
)
If the instance is configured to store images in the filesystem, there might be a lot there. Are old images cleaned up?
Provisioning
Deployment
Sysadmin
External services
- Sending emails from OFN
- Email Deliverability
- SSL certificates
- Google Maps
- File storage
- Backups
- Server monitoring
- Issue reporting (Bugsnag)
Contributing