redmine mysql 优化_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

针对不同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