zoukankan      html  css  js  c++  java
  • Redmine性能优化方案

    近来公司redmine服务器表现很糟糕,在16核,64GRAM的机器上,压测结果竟然只有每秒5~7个请求,部分页面一个都出不来。

    以下是我对Redmine性能优化方案: 

    redmine服务器性能问题排查与优化建议:
     
    以下建议的方案是基于redmine运行期的log文件中的render耗时、activerecord耗时,linux系统性能指标采样与 mysql 性能指标采样分析,以及redmine在不同web server下的benchmark而得:
     
    一. 问题排查与定量分析
    通过分析redmine运行期的log,对比mysql高峰时段的请求量与此时系统cpu、mem、disk、iowait等指标,以及我在本地的相同环境下的伪造并发量的性能测试结果,可以看出服务器中高峰时段并未有效利用cpu与内存. 最主要的4个原因是:
    1. rails框架过于笨重,运行效率低,
    2. 一个ruby进程只能利用单核cpu,其多线程受GIL所控,多线程效率较低,无法有效利用多核cpu,因此在高峰时段只有passenger进程占用的几个cpu满载,其余利用率基本为0。
    3. 目前redmine的发布方式是apache+passenger, passenger没有进过优化,只开启了6个worker,而且只是进程级支持,这导致了iredmine服务器的吞吐量非常低。
    4. mysql的运行模式没有进过优化配置,基本裸跑。
     
    1.1 性能指标说明:
    linux性能指标数据使用shell脚本来采集,已经存储,如需分析可以参考如下:
      1. linux系统采样脚本:在~/performanceLog/collectLog.sh中,或者看这篇linux系统性能指标的采集博客;
         采样结果在~/performanceLog下,以日期命名的文件中。
         注: 如果以后想使用此脚本采集数据,如果mysql的地址或者目录有更换,此脚本中dstat 的mysql相关数据的采集需要重写其mysql连接部分的代码。
      2. mysql的指标数据可以通过运行如下命令: 
          mycheckpoint --user=root --password=xxxx --socket=/redmine/mysql/tmp/mysql.sock --database=mycheckpoint http
          然后浏览器打开: http://172.26.1xx.xx:8080/mycheckpoint/ 可以查看mysql的各项指标。
     
    1.2 redmine服务器的压测、benchmark定量分析方法说明:伪造并发http请求,查看每秒并发10个请求时,不同web server的性能表现。
    针对不同web server的负载测试方法如下:
    在量化性能时,本方案带来的的性能提升时,为了方便ab测试,建议关闭redmine代码中csrf保护,并利用session,自动登陆,以保证测试的地址有sql操作,确保测试过程包含sql请求,方法如下:
     
    取消csrf保护方法:
    找到redmine发布的代码中controller目录下的ApplicationController.rb文件,将其中的csrf保护函数protect_from_forgery中cookie.delete(auto_cookie_name)行注释掉。 (production模式记得调回来)
     
    ab模拟并发测试步骤:
    0.  ./ctlscript.sh stop apache
    1.  使用puma -w 16 -t 16 -p 8080 /redmine/apps/redmine/htdocs/config.ru启动 redmine
    2.  chrome浏览器,打开url, 查看inspect tools, 复制cookies
    3.  使用ab工具: ab -n 800 -c 16  -H “Cookie: Key1=Value1; Key2=Value2”   http://localhost:8080/issues/48575
     
     
    二:优化方案说明:
    1. 并发量过大时反应慢的问题                                 #ok,使用multi-process * multi-thread的 web server
    2. 数据库读写性能过低                                          #ok,打开mysql查询缓存等。
    3. 使用异步io库em-Synchrony,提升IO吞吐量。      #failed, 经测试,不稳定,接口版本有时不匹配,需3.1以上版的rails。
    4. 使用rubinus or jruby 提升执行性能                     #failed,经测试jruby 内存损耗太大, rubinus有兼容性问题。
    5. 去除rails默认加载的非必需的middleware             #rails默认加载20多个中间件,有些是无需的。
     
    进过以上几个步骤的优化调整,进过ab测试发现,吞吐量可以提升2到3倍, 负载能力也有提升,但没有去测极限数据。
     
     
    三:web服务器优化建议:
         建议使用多进程多线程版的puma替代多进程单线程passenger, 或者 任然使用passenger,但是配置成默认开启14个worker,方便高峰时段留两个cpu给mysql使用。 另外, 由于puma可以一定程度利用多线程来serve http请求,为了保证线程安全,需修改iredmine代码: 
        添加config.threadsafe!到config/enviroment目录下的production.rb文件中
        # enable multithread, and keep thread safe.
        config.threadsafe!
    1. puma的使用: 启动14个工作进程*16个线程,提升吞吐率。
        puma -w 14 -t 16 -p 8080 /redmine/apps/redmine/htdocs/config.ru
     
    2. 配置passenger方法:
        配置文件在:/redmine/apache2/conf/bitnami 目录下,添加以下:
        PassengerMaxPoolSize 14
     
     
    四:mysql服务器优化建议:
    mysql的服务器优化主要依赖mycheckpoint采集的mysql性能指标可视化之后的分析,以及mysqltuner.pl的调优建议。
    1. 在mysql的配置文件中开启一下设置(以下有两个变量设置后需要重启mysql):
        Threads_cached  -> ON
        thread_cache_size = 64;
        query_cache_size (>= 8M)
        join_buffer_size (> 128.0K)
        tmp_table_size (> 16M)
        max_heap_table_size (> 16M)
        thread_cache_size (start at 4)
        table_open_cache (> 800)
        innodb_buffer_pool_size (>= 371M)
    另外还有: thread_concurrency = 32;  (cpu*2)
    关于mysql的用户请求压力情况,请查看http://172.26.1xx.xx:8080/mycheckpoint/
     
     
    五:rails优化建议: 删除不需要的middleware
    请联合目前redmine插件开发人员,根据当前rails的实际middleware使用情况进行筛选删除。
    方法:可以在application configuration 文件中添加以下代码来删除。
    # config/application.rb
    config.middleware.delete "Rack::Lock"
    config.middleware.delete 'Rack::Cache'                          # 整页缓存,似乎在redmine中没有用上。
    config.middleware.delete 'Rack::Runtime'                      # 记录X-Runtime(方便客户端查看执行时间)
    config.middleware.delete 'ActionDispatch::RequestId'     # 记录X-Request-Id(方便查看请求在群集中的哪台执行)
    config.middleware.delete 'ActionDispatch::RemoteIp'      # IP SpoofAttack
    config.middleware.delete 'ActionDispatch::Callbacks'       # 在请求前后设置callback
    config.middleware.delete 'ActionDispatch::Head'             # 如果是HEAD请求,按照GET请求执行,但是不返回body
    config.middleware.delete 'ActionDispatch::BestStandardsSupport' # 设置X-UA-Compatible, 在nginx上设置
    等等。。
     
     
    六: 去除production 模式下rails不需要的log 与 某些异常的修正。
    1. 由于在production.log中发现了大段的debug模式才需要的log全部输出到了log文件中,耗时较长,建议删除。
    2. 某些url出现了 runexception. 建议修正, 或者在 middleware中去除名称为: use ActionDispatch::ShowExceptions
    use ActionDispatch::DebugExceptions

    七: 部分redmine插件写的比较糟糕,render耗时长达3000ms 

    相关信息:

    1. linux系统性能定位与排查: http://www.cnblogs.com/ToDoToTry/p/4423577.html

    2. redmine的ab压力测试方法:http://www.cnblogs.com/ToDoToTry/p/4442384.html

    3. mysql性能记录与分析:http://www.cnblogs.com/ToDoToTry/p/4394249.html

    4. mysql优化工具:

    5. linux IO问题分析与排查:

    6. mysql性能测试工具与方法: 

  • 相关阅读:
    Elasticsearch 机制 架构 集群 选举
    《Leo the late bloomer》阿虎开窍了
    各行业发明专利排行榜
    接口响应 越来越慢
    知识产权代理 与 工作流
    MBA Business Org Responsbility Account Stock
    心理学 防内耗
    Apache Kafka Zookeeper Quorum
    The different aspect of architecture(架构的不同方面)
    hPaPaas low-code/no-code 低代码
  • 原文地址:https://www.cnblogs.com/ToDoToTry/p/4462609.html
Copyright © 2011-2022 走看看