What should you use for a server? Pretty much any physical server these days is more than enough to handle an average sized Odoo instance with about 10 simultaneous users. Since virtual machines typically have fewer resources provisioned, you will need to pay a little more attention to this if you are planning to run on a VM. Here are a few key figures to get you started. Obviously, they will need fine tuning to match your use of Odoo.

A small Odoo instance needs at least 1 GB of RAM. Don't be shy on this; the last thing you want to happen is your server swapping. 2 to 4 GB is a good starting point. Give your server, at the very least, two CPU/cores. If you are running the PostgreSQL server on the same host, provision at least four CPU/cores, and add 1 GB of RAM for the database. The additional CPU/cores will be used by the Odoo workers that are covered in the next recipe, Adapting the configuration file for production.

The source code of your instance will eat up 1 to 2 GB of hard disk if you are keeping the Git history, which we recommend in this recipe. The file store (data_dir in the configuration file) will grow as the instance is used, and the growth heavily depends on what you are doing in the instance. Start with 5 GB, which should give you plenty of time before getting full, and monitor the disk usage. If you are running the database on the same host, give plenty of disk space to the partition that will contain the database working files, starting at 50 GB.

You will also need space for the on-site backups, both of the database and the file store. A lot can depend on your backup plan; 200 GB is a good starting point.

Discussing PostgreSQL tuning is beyond the scope of this book. You may want to check out the books PostgreSQL 9 Admin Cookbook or PostgreSQL 9.0 High Performance, both from Packt Publishing, for an in-depth coverage of these topics.

The default configuration of PostgreSQL is generally very conservative and meant to prevent the database server from hogging all the system resources. On production servers, you can safely increase some parameters in the postgresql.conf file to get better performance. Here are some settings you can use to get started:

max_connections = 100
shared_buffers = 256MB
effective_cache_size = 768MB
work_mem = 10MB
maintenance_work_mem = 64MB
checkpoint_segments = 16
wal_buffers = 8MB
checkpoint_completion_target = 0.9

You will need to restart PostgreSQL after modifying these settings.

The pgtune utility can help in finding a suitable configuration. You can install it by running the following:


sudo apt-get install pgtune

To get a suitable configuration, you can run the following:

$ pgtune -T OLTP -i /etc/postgresql/9.4/main/postgresql.conf 
-M 1073741824 -c 100

The options we use are as follows:

If your instance is heavily loaded, you will benefit from separating the database server and the Odoo server onto two different hosts. Don't use two virtual machines running on the same physical server if you are getting down to this; use two physical servers with a high speed network connection between both. In that case, you will need to ensure that the pg_hba.conf file on the database server host allows password authenticated connections on the database from the Odoo server, and that the postgresql.conf file lets the PostgreSQL server listen in on the network interface connecting both servers.

When cloning Odoo and the third-party dependencies, you may want to ensure that you are using the exact same revision as the one you had in developments. There are several ways to do this:

The recipe does not cover backups. At the very least, you should have the cron task on the server running a daily backup. A simple and basic solution is to edit the crontab file as root by running crontab -e and to add the following lines:

@daily su postgres -c pg_dumpall | gzip > /backups/postgresql-$(date +%u).dump.gz
@daily tar czf /backups/odoo-data-$(date +%u).tgz /home/odoo/odoo-prod/project/data

Don't forget to create the /backups directory. The backup files should not be stored on the same hard disk, and ideally, they would be mirrored on a server in a different physical location. Check these backups on a regular basis; having backups that you can't restore when you need them is useless.

The proposed solution is to keeps daily backups of the last 7 days, which means you will lose one day of work in case of a problem. There are more advanced solutions available for PostgreSQL that allow point-in-time recovery. You will find more information about this in the book PostgreSQL 9 Admin Cookbook, Packt Publishing. Similarly, there are many Linux tools, such as duplicity (http://duplicity.nongnu.org/), which you can use for file backups allowing easy management.