I have Odoo 9 with postgreSQL 9.6, with nginx and the longpolling well configured.
Everything is working fine, and suddenly, the server crashes and this message appears in the log:
OperationalError: FATAL: sorry, too many clients already
2018-05-16 13:00:02,496 141 INFO ? openerp.sql_db: Connection to the database failed
2018-05-16 13:00:02,496 141 ERROR ? openerp.service.server: Worker (141) Exception occured, exiting...
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/openerp/service/server.py", line 721, in run
self.process_work()
File "/usr/lib/python2.7/dist-packages/openerp/service/server.py", line 790, in process_work
db_names = self._db_list()
File "/usr/lib/python2.7/dist-packages/openerp/service/server.py", line 783, in _db_list
db_names = openerp.service.db.list_dbs(True)
File "/usr/lib/python2.7/dist-packages/openerp/service/db.py", line 323, in list_dbs
with closing(db.cursor()) as cr:
File "/usr/lib/python2.7/dist-packages/openerp/sql_db.py", line 643, in cursor
return Cursor(self.__pool, self.dbname, self.dsn, serialized=serialized)
File "/usr/lib/python2.7/dist-packages/openerp/sql_db.py", line 177, in __init__
self._cnx = pool.borrow(dsn)
File "/usr/lib/python2.7/dist-packages/openerp/sql_db.py", line 526, in _locked
return fun(self, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/openerp/sql_db.py", line 594, in borrow
**connection_info)
File "/usr/lib/python2.7/dist-packages/psycopg2/__init__.py", line 164, in connect
conn = _connect(dsn, connection_factory=connection_factory, async=async)
I have to restart the server to temporal fix, but I don't know what is the cause.
I have a 4 cores CPU with 8 GB RAM.
I set these parameters in Odoo.conf file:
...
workers = 7
max_cron_threads = 2
db_maxconn = 64
What is the reason of the crash? Is it an odoo config error or a postgreSQL config error?
We're suffering from a similair problem, only when running the scheduler. It seems like Odoo is keeping the connections "alive" (even though they might be idle) for well over 2 days. This might be the cause.
21south, Ludo - 21South
Do you have a better solution than set workers to 0?
check postgres and system logs. you will surely find something. monitor how many idle users you have hanging in postgres so on. can't say much by looking at that log