`` –Db_maxconn``

Вот определение из `` odoo / tools / config.py``

group.add_option("--db_maxconn", dest="db_maxconn", type='int', my_default=64,
                 help="specify the the maximum number of physical connections to posgresql")

Более точное объяснение этой опции следующее:

`` db_maxconn`` - указать максимальное количество физических подключений к posgresql ** на процесс odoo, но для всех баз данных **

** Сколько процесс ODOO работает? **

  • : Документ: `longpolling <longpolling> `- не более 1 процесса
  • : Doc: `рабочие <workers> `
  • : Doc: `max_cron_threads <max_cron_threads> `

** Что это означает практически? **

Если у вас развертывание с большим количеством баз данных или одновременных пользователей, вы можете столкнуться со следующей ошибкой:

File "/opt/odoo/vendor/odoo/cc/odoo/service/wsgi_server.py", line 128, in application
    return application_unproxied(environ, start_response)
File "/opt/odoo/vendor/odoo/cc/odoo/service/wsgi_server.py", line 117, in application_unproxied
    result = odoo.http.root(environ, start_response)
File "/opt/odoo/vendor/odoo/cc/odoo/http.py", line 1331, in __call__
    return self.dispatch(environ, start_response)
File "/opt/odoo/vendor/odoo/cc/odoo/http.py", line 1300, in __call__
    return self.app(environ, start_wrapped)
File "/opt/odoo/.local/lib/python3.7/site-packages/werkzeug/wsgi.py", line 766, in __call__
    return self.app(environ, start_response)
File "/opt/odoo/vendor/odoo/cc/odoo/http.py", line 1501, in dispatch
    result = ir_http._dispatch()
File "/opt/odoo/vendor/odoo/cc/addons/auth_signup/models/ir_http.py", line 19, in _dispatch
    return super(Http, cls)._dispatch()
File "/opt/odoo/vendor/odoo/cc/addons/web_editor/models/ir_http.py", line 22, in _dispatch
    return super(IrHttp, cls)._dispatch()
File "/opt/odoo/vendor/odoo/cc/odoo/addons/base/models/ir_http.py", line 207, in _dispatch
    return cls._handle_exception(e)
File "/opt/odoo/vendor/odoo/cc/odoo/addons/base/models/ir_http.py", line 174, in _handle_exception
    raise exception
File "/opt/odoo/vendor/odoo/cc/odoo/addons/base/models/ir_http.py", line 203, in _dispatch
    result = request.dispatch()
File "/opt/odoo/vendor/odoo/cc/odoo/http.py", line 840, in dispatch
    r = self._call_function(**self.params)
File "/opt/odoo/vendor/odoo/cc/odoo/http.py", line 351, in _call_function
    return checked_call(self.db, *args, **kwargs)
File "/opt/odoo/vendor/odoo/cc/odoo/service/model.py", line 97, in wrapper
    return f(dbname, *args, **kwargs)
File "/opt/odoo/vendor/odoo/cc/odoo/http.py", line 344, in checked_call
    result = self.endpoint(*a, **kw)
File "/opt/odoo/vendor/odoo/cc/odoo/http.py", line 946, in __call__
    return self.method(*args, **kw)
File "/opt/odoo/vendor/odoo/cc/odoo/http.py", line 524, in response_wrap
    response = f(*args, **kw)
File "/opt/odoo/vendor/odoo/cc/addons/auth_signup/controllers/main.py", line 21, in web_login
    response = super(AuthSignupHome, self).web_login(*args, **kw)
File "/opt/odoo/vendor/odoo/cc/odoo/http.py", line 524, in response_wrap
    response = f(*args, **kw)
File "/opt/odoo/vendor/odoo/cc/addons/web/controllers/main.py", line 484, in web_login
    values['databases'] = http.db_list()
File "/opt/odoo/vendor/odoo/cc/odoo/http.py", line 1517, in db_list
    dbs = odoo.service.db.list_dbs(force)
File "/opt/odoo/vendor/odoo/cc/odoo/service/db.py", line 379, in list_dbs
    with closing(db.cursor()) as cr:
File "/opt/odoo/vendor/odoo/cc/odoo/sql_db.py", line 657, in cursor
    return Cursor(self.__pool, self.dbname, self.dsn, serialized=serialized)
File "/opt/odoo/vendor/odoo/cc/odoo/sql_db.py", line 171, in __init__
    self._cnx = pool.borrow(dsn)
File "/opt/odoo/vendor/odoo/cc/odoo/sql_db.py", line 540, in _locked
    return fun(self, *args, **kwargs)
File "/opt/odoo/vendor/odoo/cc/odoo/sql_db.py", line 608, in borrow
    **connection_info)
File "/usr/local/lib/python3.7/site-packages/psycopg2/__init__.py", line 130, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: FATAL: sorry, too many clients already

Для ее решения необходимо настроить следующие параметры:

  • В оду
    • `` db_maxconn``
    • : Doc: `рабочие <workers> `
    • : Doc: `max_cron_threads <max_cron_threads> `
  • В posgresql

Эти параметры должны удовлетворять следующему условию:

(1 + workers + max_cron_threads) * db_maxconn < max_connections

Например, если у вас есть следующие значения:

  • работники = 1 (минимальное значение, чтобы заставить работать долго)
  • max_cron_threads = 2 (по умолчанию)
  • db_maxconn = 64 (по умолчанию)
  • max_connections = 100 (по умолчанию)

затем `` (1 + 1 + 2) * 64 = 256&gt; 100``, т.е. условие не выполняется, и такое развертывание может столкнуться с ошибкой, описанной выше.

** Хорошо, но какие значения хороши для конкретного сервера и условий нагрузки? **

Оформить заказ <https://github.com/odoo/odoo/issues/39825#issuecomment-555175814>`__ из одони. В частности, для параметра `` db_maxconn`` цитата приведена ниже.

PostgreSQL’s max_connections should be set higher than db_maxconn * number_of_processes. You may need to tweak the kernel sysctl if you need max_connections higher than 1-2k.

В режиме многопроцессорной обработки каждый рабочий HTTP обрабатывает один запрос за раз, поэтому теоретически может работать `` db_maxconn = 2`` (для некоторых запросов требуется 2 курсора, следовательно, 2 дБ соединения). Однако для мультитенанта это не оптимально, потому что каждый запрос должен будет заново открывать новое соединение с другой базой данных - лучше установить его немного выше. С большим количеством работников 32 - это хороший компромисс, так как 64 может заставить вас достичь ограничений ядра. Также имейте в виду, что ограничение применяется и к работнику с длинным опросом, и вы не хотите слишком долго откладывать сообщения чата из-за полного пула соединений, поэтому не устанавливайте его слишком низким, несмотря ни на что. Сохранение значения в диапазоне 32-64 обычно кажется хорошим выбором.

Для многопоточного режима, поскольку существует только 1 процесс, это размер глобального пула соединений. Во избежание ошибок его следует устанавливать между 1x и 2x ожидаемым количеством одновременных запросов одновременно. Можно оценить на основе количества баз данных и ожидаемой активности. Если один процесс обрабатывает более 20 запросов одновременно на одном ядре (помните, что многопотоковость зависит от GIL) вряд ли даст хорошую производительность, поэтому, опять же, настройка в диапазоне 32-64, скорее всего, будет работать для нормальная нагрузка.