第十七章 配置文件详解

模块addons目录

我们知道,odoo加载addons的目录是根据配置文件中的addons_path参数来读取的.

如果多个addons的目录中有相同名字的模块,那么odoo将只读取第一个模块的内容而自动忽略第二个模块的内容. 生产环境中,我们当然不希望多个addons目录中出现这种情况, 这种情况出现的一个场景是在开发过程中,不同的项目使用了同一个版本的odoo,两个项目中可能会出现模块重复的情况,这种情况就需要开发者管理好自己的代码目录,并加以区分,否则将可能造成困惑.

日志

配置文件中与日志相关的配置参数有:

• logfile
• log_db
• log_db_level
• log_handler
• log_level
• logrotate

分割日志

默认情况下odoo的日志都存储在一个文件内, 随着系统使用时间的增长这个文件也会跟着增长,尤其是如果log_level设置为debug的时候. 这个时候我们就需要一种分割日志的功能,将其按照某种规则(通常是时间中的日期,文件的大小限制)将其分割成若干个小文件以方便我们进行分析.

在配置文件中把logrotate设置为True可以开启日志分割功能,默认按照每天一个日志文件,并保留30天.

odoo的日志分割功能使用的是logrotate工具,logrotate是Linux系统的日志管理工具,可以对单个日志文件或者某个目录下的文件按照时间/大小的方式,压缩操作；指定日志保存数量；还可以在切割之后运行自定义命令. 关于logroate更多的内容,读者可以自行搜索相关资料进行学习.

如果配置文件中开启了logrotate=True,但是odoo依旧没有将日志分割成多个文件,那么请检查你的系统中/etc/logrotate.d/目录中是否存在odoo的配置文件. 一个典型的odoo日志分割配置如下: ``` /var/log/odoo/*.log { copytruncate missingok notifempty }

Workder的计算方法

生产环境下,最好开启多进程以最大化利用服务器的性能,开启多worker的方法即在配置文件中设置不为0的worker数量.

worker  = 1

worker数量的计算公式:

• CPU数量* 2 +1
• 定时任务需要一个worker
• 1个workder大概可以满足6个并发

内存计算方法

假设80%的请求是轻量级的请求,20%的请求是重量级的请求,在计算字段设计良好,SQL请求设计良好的情况下,一个重量的workder大概需要消耗1G的内存,一个轻量的workder需要150M的内存.

所以,内存的计算公式:

RAM = Workder数量 * ((0.8* 150) +(0.2*1024))

以市面上主流的4C8G服务器来计算的话,如果开启9个workder, 大概需要3G内存.

CPU时间限制

为了防止进程占用太多的资源,odoo默认给每个worker设置了CPU时间限制和进程的时间限制.

limit_time_cpu = 600
limit_time_real = 1200

• limit_time_cpu : 处理一个请求能占用CPU的最长时间,超过时间将强制worker退出进程,默认60秒
• limit_time_real: 处理一个请求能花费的最长时间,超过时间worker将被强制退出,默认120秒

实际过程中,我们通常会碰到需要长时间占用进程资源的场景,例如,批量导入导出数据,查询数据量过大的报表等等,这种情况下就需要我们根据实际的情况调整进程的时间配置参数.

内存限制

在内存的使用上同样有类似于CPU使用的限制条件.

limit_memory_hard = 1677721600
limit_memory_soft = 629145600

• limit_memory_soft: 每个worker所能使用的最大虚拟内存,超出后,workder将在请求处理完成后被回收
• limit_memory_hard: 每个worker所能使用的最大虚拟内存, 超出后worker将立即被中止而不管请求是否被完成

即limit_memory_soft是一个"缓刑"手段,允许进程完成当前还没有完成的工作. 而limit_memory_hard有点"死刑立即执行"的味道, 当进程触碰了红线,将被立即杀死.

瞬态模型参数

瞬态模型(TransientModel)的清理逻辑依赖两个参数:

• osv_memory_count_limit: 临时表的数据大小限制
• transient_age_limit: 瞬态模型的时间限制

transient_age_limit参数在14.0及之前的版本中为 osv_memory_age_limit

举个例子, 假设我们临时表内有55条数据, 其中10条是5分钟内创建/修改的, 12条是5-10分钟内修改的, 剩下的是12分钟前修改的. 我们的配置为最大条数为20, 最长时间是0.2H(12分钟). 那么它的运行逻辑如下:

• 基于时间限制, 将剩余10分钟内创建的22条数据
• 基于数量限制, 将删除5分钟前的12条数据(而不是2条)

为什么是2条? 请参考第三章关于瞬态模型的处理逻辑部分.