Community mailing list archives
Re: Odoo Performance and concurrency locksby
You know much more than me obviously in terms of Odoo and Postgres, but IMO there is a design flaw in how transactional isolation is implemented in Odoo, and I think it has been an ignored problem. I stand firm behind this point. I have worked in over 10 enterprise systems with many users and seen this problem in all of them.
The part you said in 2a, I can see this at any point while a transaction is executing, it does not have to be the beginning.
Hello,Thanks for your interest in this thread. From what I have seen in my experience, it is much different than what you describe. Transaction rollback errors are a plague of this system, and as mentioned in my first post you can easily see this problem when the im chat presence is updated. I can get the transaction rollback error with an idle system, no custom modules.
On Mon, Sep 14, 2015 at 10:52 AM, Olivier Dony <email@example.com> 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  or nginx's upstream modules  for example).  http://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html  http://nginx.org/en/docs/http/load_balancing.html