Odoo中文社区可以通过以下两个域名访问:shine-it.net , odoo.net.cn

由于系统升迁的原因,本论坛部分较早期的内容存在格式和链接损坏失效的问题,并非本论坛系统本身的缺陷,望谅解

本社区没有维护任何QQ群讨论组,任何与本社区同名的QQ群讨论组的言论与本社区无关!

开发人员可以登录gitter讨论组: http://gitter.im/odoo-china/Talk, 需要github账号

如果您登录系统碰到问题,请在微信公众号留言:

OpenERP 6.1多进程模式配置方法



    1. 问题背景
          由于Python的GIL问题,OpenERP 6.1以前的版本,只能单进程运行。在单进程模式下,OpenERP永远只能利用单核CPU。也就是说,即使你的服务器硬件非常牛,例如有多核多颗CPU,但OpenERP却不会利用。较高负荷的情况下,网页响应速度很慢,但用top看CPU利用率,却非常低(急煞人又气煞人)!
          从OpenERP 6.1开始,事情有了改变。这得从“绿色独角兽“说起。在互联网开发领域,Python语言由于其简洁、快速、强大的编程能力,很多Web程序都用Python编写。为了应对互联网的海量访问,这些Web程序必须能够充分利用多核和多CPU!”绿色独角兽“ Gunicorn就是用来解决这个问题的!凡是遵循WSGI标准的Web应用,在gunicorn的帮助下,可以自动fork出多进程,从而充分利用CPU。OpenERP 6.1开始,完全遵循WSGI标准,重写了Web端代码,能够支持多进程,从而大幅提高系统性能。更多的背景知识,参考帖子: [检测到链接无效,已移除]

      2)准备工作
            OpenERP多进程配置,安装好OpenERP 6.1,能正常启动之后,还需要:第一步,需要安装gunicorn, psutil包;第二步,通过gunicorn启动OpenERP;第三步,启动OpenERP的cron 程序。
            安装gunicorn。在Ubuntu下,这个非常简单,apt-get install gunicorn 即可。
            安装psutil包,这个也非常简单,执行完下述命令即可:
      wget [检测到链接无效,已移除] br />tar -xzf psutil-0.6.1.tar.gz
      cd psutil-0.6.1
      python setup.py install
      cd ..

      3)启动OpenERP多进程
          在OpenERP 6.1源码的Server目录下,有个文件gunicorn.conf.py,遵循该文件说明,启动OpenERP即可。启动命令如下:
          gunicorn openerp:wsgi.core.application -c gunicorn.conf.py

      4)启动OpenERP Cron进程
          OpenERP有一些定期执行的作业,典型的如定期安全库存检查,定期收发EMail。OpenERP默认的单进程模式下,系统会自动启动Cron进程执行定期任务。但在多进程模式下,由于通过gunicorn启动OpenERP,系统不会启动cron进程,需要单独启动它。
          从这里下载独立执行的OpenERP cron程序: http://bazaar.launchpad.net/~openerp/openobject-server/6.1/view/4184/openerp-cron-worker
          设置linux crontab作业,一分钟执行一次该脚本即可,脚本执行参考命令:
            python openerp-cron-worker -c openerp-server.conf


  • 谢谢分享



  • 这是好东西,建议老肖下次补充到书里面去



  • 收藏之...............



  • 强!



  • 好贴  标记



  • 在OE7中,openerp-server --help中,可以看到,OE7已经集成了多处理器支持:

    Multiprocessing options:
        --workers=WORKERS  Specify the number of workers, 0 disable prefork mode.
        --limit-memory-soft=LIMIT_MEMORY_SOFT
                            Maximum allowed virtual memory per worker, when
                            reached the worker be reset after the current request
                            (default 671088640 aka 640MB).
        --limit-memory-hard=LIMIT_MEMORY_HARD
                            Maximum allowed virtual memory per worker, when
                            reached, any memory allocation will fail (default
                            805306368 aka 768MB).
        --limit-time-cpu=LIMIT_TIME_CPU
                            Maximum allowed CPU time per request (default 60).
        --limit-time-real=LIMIT_TIME_REAL
                            Maximum allowed Real time per request (default 120).
        --limit-request=LIMIT_REQUEST
                            Maximum number of request to be processed per worker
                            (default 8192).

    有谁测试过这个workers=X的性能的,可以公布一下给大家。


Log in to reply