Community mailing list archives

Re: Odoo Performance and concurrency locks

ClearCorp S.A., Carlos Vasquez
- 09/14/2015 18:11:13
Hi Olivier,

(Out 2 cents for the concurrency part) We use a 2 server setup with load balancing and fail over with nginx, with multiple workers on each server. We use PG 9.3 and concurrency locks are not a problem. We run about 30 databases for small clients on those servers.

(My question for the performance part) But what we are seing is that database connections are being reset very often. Does this have any relation with the number of database connections in the config file, of with the cpu and real time limits for the workers? What values do you use for these settings?

Thank you,

On Mon, 14 Sep 2015 at 09:52 Olivier Dony <> wrote:
On 09/14/2015 08:34 AM, Alexandre Fayolle wrote:
> On 13/09/2015 21:57, Shawn Varghese wrote:
>> Right now, an immediate concern is the concurrency locks in the DB. Once
>> a lock occurs, Odoo only tries upto 5 times to resolve it and the delay
>> between each retry is too small.

By default the system retries up to 5 times, each after a random delay up to 
2**tries seconds. So that could take up to 1 minute if all attempts are 
necessary. For an interactive operation, this is actually very long - the user 
will be waiting in front of her screen!

Instead of playing with these settings or installing modules as an attempt to 
work around this, I would recommend 2 things:

1. Upgrade to PostgreSQL 9.3 or 9.4 if that is not done yet. PG 9.3 introduces 
new row locking levels (FOR KEY SHARE) that will drastically reduce the 
conflicts caused by foreign key constraints. Doing this alone could be 
sufficient to solve your problems.

2. Review your transactions and try to understand why you are seeing 
conflicts.. something fishy is probably going on.

2a. Before PG 9.3, you should only get TransactionRollbackErrors caused by 
logins if other transactions are creating or updating data with the same user 
as the one logging in. This is supposed to be rare even with hundreds of users 
unless you are sharing logins between users, cron jobs and/or web services. And 
even in this case, a TransactionRollbackError should only occur if the login 
occurs between the moment a transaction starts and the time it creates/updates 
the first record.

2b. As of PG 9.3, you should not see TransactionRollbackErrors caused by logins 
unless your transactions are actively updating user records themselves. This 
should not happen much with the standard Odoo distribution.

>> Also, to increase the number of HTTP workers, it is just a simple case
>> of giving a non-zero number to the *workers* parameter in the config file?

Yes, but you want to carefully consider the number of workers you're 
configuring, and the memory limits you configure. When you activate workers 
mode you make a better use of your CPU cores, but you risk introducing 
delays/bottlenecks if you don't tune it correctly. Too many workers is better 
than too few, as long as the memory limits ensure you can't fill up the whole 
memory and start swapping.

>> How exactly does one achieve load balancing?

Odoo's built-in workers mode performs load-balancing over multiple processes on 
a single machine. If you want to do the balancing over multiple machines just 
replicate this setup on several machines and put a reverse proxy in front of 
them (read up on Apache's mod_proxy [1] or nginx's upstream modules [2] for 


Post to:

Carlos Vásquez · ClearCorp
COO | Analista Experto

CR: +(506) 4000 2677
US: +1 (786) 472-4267