Community mailing list archives

Re: Odoo Performance and concurrency locks

Antony Lesuisse (al)
- 09/14/2015 17:15:47
That said, we will consider adding a separate append only table for last login 
(actually it would be last presence it would be used for chat presence too) 
because res.users is a foreign key to every row and i think most of the 
concurrency issues comes from that.

The patch would be very similar to base_concurrency module, the fonction 
should be called when login and when longpolling on the bus (for chat and 
notification). It would be append only to the table only if lasttime-now() is 
 > that presence delay (maybe 5min). And we would GC it in a cron.

On 09/14/2015 05:53 PM, 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
> example).
> [1]
> [2]
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe: