解析Odoo的配置文件中的参数

在Odoo的配置文件中有许多的配置参数，合理的配置这些参数可以使Odoo更高效的运行，本篇文章会结合源码以及官方文档对一些参数进行解析，方便开发人员更深入的理解参数背后的含义。

workers

Odoo根据workers的数量，会使用不同的服务器来处理请求。

• 如果workers的值为0，Odoo会使用多线程服务器来处理请求，服务器接收到请求后会为请求生成一个新的线程。该服务器受限于Python的GIL，不能充分利用硬件性能，但是该服务器对操作系统的兼容性很好，通常在开发环境下会使用该服务器。
• 如果workers的值大于0，Odoo会使用多进程服务器来处理请求，该服务在启动时会创建一个基于workers配置值的进程池，请求会存入到队列中，等待空闲进程进行处理，多进程环境下会运行一个可配置的进程监控，监控进程的资源使用情况以及对失败的进程进行结束/重启操作。多进程服务器充分利用了硬件性能，在生产环境中应该使用该配置。
  • 注意：多进程服务器只支持Linux系统

根据硬件计算workers数量

• 经验公式：workers = (CPU * 2) + 1
• 一个worker可以处理6个并发请求
• 如果一个Odoo实例需要支持的最大并发数量为54，则服务器需要配置4核的CPU，计算公式：((54/6) - 1) / 2 = 4

limit_time_cpu

当workers数量大于0时，Odoo使用多进程服务器，该配置项限制进程处理请求所占用的CPU时间（时间片的总和），例如limit_time_cpu=60，则请求只能使用60秒的CPU时间。

• 时间片：CPU在运行时不会一直运行单一进程，而是在进程之间不断切换，一个进程允许运行的时间即一个时间片

limit_time_cpu通过操作系统提供的方法对worker占用的资源进行限制，源码

def check_limits(self):
    ...
    # update RLIMIT_CPU so limit_time_cpu applies per unit of work
    # resource为Python的内置模块
    # getrusage（get resource usage?）方法用于获取资源占用情况
    # 参数resource.RUSAGE_SELF代表获取进程本身的资源占用，还支持其他参数，例如：resource.RUSAGE_CHILDREN子，可以获取紫禁城
    r = resource.getrusage(resource.RUSAGE_SELF)
    # CPU时间包含用户态时间utime(user time)与内核态时间stime(system time)  
    cpu_time = r.ru_utime + r.ru_stime
    # 获取资源的大小限制，soft(软限制)/hard（硬限制），硬限制是用来指定软限制能设定的最大值，由系统管理员通过设置系统级参数来决定
    soft, hard = resource.getrlimit(resource.RLIMIT_CPU)
    # 这里与cpu_time相减目的是将执行限制指令之前的CPU时间排除掉
    # `setrlimit`(*resource*, *limits*) 设置资源的大小限制，limits必须是格式(soft,hard)，soft/hard都必须为整数
    resource.setrlimit(resource.RLIMIT_CPU, (int(cpu_time + config['limit_time_cpu']), hard))

limit_time_real

多进程模式下worker执行的最大实际时间。

• 实际时间（real time）： CPU时间+CPU切换到其他进程时的等待时间

通过进程监控实现资源的限制，源码：

def process_timeout(self):
    now = time.time()
    for (pid, worker) in self.workers.items():
        # watchdog_timeout即配置文件中的limit_time_real
        if worker.watchdog_timeout is not None and \
                (now - worker.watchdog_time) >= worker.watchdog_timeout:
            _logger.error("%s (%s) timeout after %ss",
                          worker.__class__.__name__,
                          pid,
                          worker.watchdog_timeout)
            self.worker_kill(pid, signal.SIGKILL)