How to Speed up Odoo

Jan 13, 2017 | Tips and Tricks | 13

Odoo is the most popular ERP (Enterprise Resource Planning) software, written in Python and uses PostgreSQL as database
back-end. The Odoo community edition is a free and open source software which includes project management,
manufacturing, accounting, billing and sales management, warehouse management, human resources and more. There are
about 30 core modules and more than 3000 community modules. Odoo is a complex software, and deploying a number of
modules, having huge data inside the database etc. could induce a slowdown. The two major Odoo bottlenecks are disk
access and database query time. In this tutorial we will show you how how to speed up Odoo.

In order to increase the performance of an Odoo instance, make sure to use:

 a fast disk drive for storage (preferably SSD)

 a Linux VPS with lots of RAM.

 activate multiprocessing mode in Odoo.

 configure and optimize the PostgreSQL service properly.

1. Get an SSD VPS with more RAM

Like we mentioned previously, the random disk access speed is one of the major Odoo bottlenecks, so make sure to host
Odoo on an SSD based VPS. Always install Odoo on a VPS with more RAM because Odoo is known as resource intensive
application, and load the entire Odoo instance and its database into RAM if possible. Solid state disk drives excel especially
in random access and they can achieve random access IOPS hundreds of times higher than conventional mechanical har
disk drives because SSDs do not have any moving parts. No matter how much optimizations and configurations you do on
your Odoo, if the server is not fast or powered by SSD, your Odoo will be slow. Getting the right hosting for your Odoo is the
most important factor of your Odoo’s performance.
[ecko_alert color=”blue”]Did we mention that Odoo is a resource-hungry app? It seems so. But fear not, RoseHosting will
provide you the ultimate solution – a performance-tailored Odoo SSD VPS optimized to match your most demanding needs.
Get an SSD VPS from us and find out what record-breaking Odoo speed really means. [/ecko_alert]

Other Odoo optimizations include:

2. Enable the Multiprocessing option in your Odoo configuration

To do so, locate the openerp-server binary file:

#updatedb
#locate openerp-server

/usr/bin/openerp-server

Run the following command:

#/usr/bin/openerp-server --help

The output of this command should be like this:

Usage: openerp-server [options]

Options:
--version show program's version number and exit

(...)

Multiprocessing options:
--workers=WORKERS Specify the number of workers, 0 disable prefork mode.
--limit-memory-soft=LIMIT_MEMORY_SOFT
Maximum allowed virtual memory per worker, when
reached the worker be reset after the current request
(default 671088640 aka 640MB).
--limit-memory-hard=LIMIT_MEMORY_HARD
Maximum allowed virtual memory per worker, when
reached, any memory allocation will fail (default
805306368 aka 768MB).
--limit-time-cpu=LIMIT_TIME_CPU
Maximum allowed CPU time per request (default 60).
--limit-time-real=LIMIT_TIME_REAL
 Maximum allowed Real time per request (default 120).
--limit-request=LIMIT_REQUEST
Maximum number of request to be processed per worker
(default 8192).

The number of workers should be equal to number of CPU cores allocated to the VPS, or if you want to leave some CPU
cores exclusively for the PostgreSQL database, cron jobs or other applications installed on the same VPS where the Odoo
instance is installed and running, set the number of workers to a lower value than CPU cores available on the VPS to avoid
resources exhaustion.
The limit-memory-soft and limit-memory-hard are self-explanatory, and you should leave them to the default value or
modify them depending on the RAM available on the actual VPS.
For example, if you have a VPS with 8 CPU cores and 16 GB of RAM, the number of workers should be 17 (CPU cores * 2 +
1), total limit-memory-soft value will be 640 x 17 = 10880 MB , and total limit-memory-hard 768MB x 17 = 13056 MB, so
Odoo will use maximum 12.75 GB of RAM.

For example, on a VPS with 16 GB of RAM and 8 CPU cores, edit the Odoo configuration file (e.g. /etc/odoo-server.conf), and
add the following lines to it:

vi /etc/odoo-server.conf
workers = 17

limit_memory_hard = 13690208256

limit_memory_soft = 11408506880

limit_request = 8192

limit_time_cpu = 60

limit_time_real = 120

max_cron_threads = 2

Do not forget to restart Odoo for the changes to take effect.

3. Properly configure and optimize PostgreSQL

As for the PostgreSQL optimization, it is a good idea to update to the latest PostgreSQL version whenever a new version
comes out. There are two settings in PostgreSQL configuration file (pg_hba.conf) which should be modified: shared_buffers
and effective_cache_size. Set shared_buffers to 20% of the available memory, and effective_cache_size to 50% of the
available memory.

For example, if Odoo is installed on an SSD VPS with 16 GB of RAM, use the following settings in the postgresql.conf file:

vi /var/lib/postgresql/data/postgresql.conf
shared_buffers = 3072MB
effective_cache_size = 8192MB

4. Restart PostgreSQL

Restart the PostgreSQL service for the changes to take effect.

5. Periodically clean up temporary data

Also, do not forget to run ‘VACUUM‘ manually periodically. ‘Vacuuming’ cleans up stale or temporary data, but please keep
in mind that it is heavy on both CPU and disk usage.

Of course, you don’t have to speed up Odoo, if you use one of our Odoo VPS Hosting services, in which case you can simply
ask our expert Linux admins to speed up Odoo for you. They are available 24×7 and will take care of your request
immediately.
Michael Paquier - PostgreSQL hacker

Postgres 9.4 feature highlight - ALTER SYSTEM SET for dynamic

configuration
You liked this post or you have a comment? You can contact and help me here.
20 Jan 2014
Tags: 9.4, postgres, postgresql, system
PostgreSQL 9.4 has added a new SQL command called ALTER SYSTEM SET,
introduced by this commit:
commit 65d6e4cb5c62371dae6c236a7e709d503ae6ddf8
Author: Tatsuo Ishii
Date: Wed Dec 18 23:42:44 2013 +0900

Add ALTER SYSTEM command to edit the server configuration file.

Patch contributed by Amit Kapila. Reviewed by Hari Babu, Masao Fujii,

Boszormenyi Zoltan, Andres Freund, Greg Smith and others.

The feature that this commit introduces is really powerful (as much as
dangerous): it offers the possibility to set configuration parameters, the GUC
parameters of server, directly with a SQL query.
The parameter values that this command changes are located in a new system
file called postgresql.conf.auto located at the root of data folder. This file is
created by initdb, has its data uploaded on server and persists with the server.
 $ cat $PGDATA/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by ALTER SYSTEM command.

So basically avoid to modify it manually as this is used for ALTER SYSTEM.

When a parameter is modified, a temporary file called
postgresql.auto.conf.temp is created to rollback to the original state in case of
error.
Note that you can delete this file while server is running as well and still run
the ALTER SYSTEM commands.
$ rm postgresql.auto.conf
$ psql -c "ALTER SYSTEM SET shared_buffers TO '400MB'"
ALTER SYSTEM
$ cat postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by ALTER SYSTEM command.
shared_buffers = '400MB'

Using TO DEFAULT to reset a parameter removes the entry from

postgresql.auto.conf to keep it readable.
Deleting this file and restarting server results in an harmless LOG message
telling that the configuration file is skipped.
$ rm postgresql.auto.conf
$ pg_ctl restart
waiting for server to shut down....DEBUG: logger shutting down
done
server stopped
server starting
LOG: skipping missing configuration file "/to/pgdata/postgresql.auto.conf"
LOG: redirecting log output to logging collector process
HINT: Future log output will appear in directory "pg_log".
Note also that the file is not recreated immediately and that the first ALTER
SYSTEM command will do the job.
Parameters modified with ALTER SYSTEM SET are effective on server after
either reloading parameters or restarting server, depending on the parameters
types, like PGC_SIGHUP or PGC_POSTMASTER. And of course, some
parameters like the recently-added data_checksums that cannot be changed
after server initialization, cannot be set. For example, in the case of work_mem
(not really recommended to avoid system-wide plan changes for the queries
running but…):
=# ALTER SYSTEM SET work_mem TO '10MB';
ALTER SYSTEM
=# \! cat $PGDATA/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by ALTER SYSTEM command.
work_mem = '10MB'
=# SHOW work_mem;
work_mem
----------
1MB
(1 row)

The parameter is set but its new value will be visible on server only after
reloading it.
=# SELECT pg_reload_conf();
pg_reload_conf
----------------
t
(1 row)
=# SHOW work_mem;
work_mem
----------
10MB
(1 row)
An important thing to know is that server gives the priority to
postgresql.auto.conf and not postgresql.conf.
=# \! cat $PGDATA/postgresql.auto.conf | grep -v "\#"
work_mem = '10MB'
=# \! cat $PGDATA/postgresql.conf | grep -v "\#" | grep work_mem
work_mem = 1MB
=# SHOW work_mem;
work_mem
----------
10MB
(1 row)

As you might have guessed already, postgresql.auto.conf has the priority on

parameter values even for configuration files included in postgresql.conf with
‘include’ and friends.
Now let’s finish with a direct application of this feature: the possibility to
switch synchronous standby nodes directly with SQL. This can simply be done
by playing with synchronous_standby_names.
=# SELECT application_name, sync_state FROM pg_stat_replication;
application_name | sync_state
------------------+------------
node_5433 | async
(1 row)
=# ALTER SYSTEM SET synchronous_standby_names TO 'node_5433';
ALTER SYSTEM
=# select pg_reload_conf();
pg_reload_conf
----------------
t
(1 row)
=# SELECT application_name, sync_state FROM pg_stat_replication;
application_name | sync_state
------------------+------------
node_5433 | sync
(1 row)
This case has been mentioned on pgsql-hackers, called standby degradation.
Its opposite, the switch sync-to-async or standby elevation (?) is possible as
well.
 Ask Question

up vote259down vote favorite

58
I have recently reinstalled postgresql 8.3 on my Ubuntu 8.04 after update. Used
EnterpriseDB package. I can connect to the database locally, I see system DB postgres
but I can't configure it because I can't find config files. Searched through entire hard
drive and found only samples like pg_hba.conf.sample
Where are the postgres *.conf files?
postgresql configuration ubuntu-8.04

shareedit
edited Aug 24 '16 at 8:59

Kopezaur
189
asked Aug 30 '10 at 16:48

Timur Sadykov
5,00842540
 in Pg 9.6 see C:\PostgreSQL\data\pg96 – Sajeev Jan 30 at 7:28
add a comment
16 Answers
activeoldestvotes

¿No encuentras la respuesta? Pregunta en Stack Overflow en español.

✕

up vote561down vote accepted

Or ask your database:

$ psql -U postgres
postgres=# SHOW config_file;
shareedit
edited Feb 21 at 15:23
 Webliografía

https://sateliteguayana.wordpress.com/2014/07/22/configuracion-personalizada-para-desarrollar-
modulos-en-openerp-odoo-sobre-debian/

https://www.rosehosting.com/blog/how-to-speed-up-odoo/

https://stackoverflow.com/questions/3602450/where-are-my-postgres-conf-files