Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.

Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
Redmineチューニングの
実際と限界
〜200万チケットでもサクサクなRedmineの作り方〜
第1版 2015年5月16日第 8回 Redmine.Tokyo
第2版 2016年3月 5日第14回 RxTstudy
第3版 2017年8月26日第17回 Redmine大阪
株式会社島津ビジネスシステムズ基盤技術部
赤羽根州晴 kakahane@sbs.shimadzu.co.jp

2
ありがとう｡
Thanks a lot.
Merci beaucoup.

話者紹介
赤羽根州晴（@akahane92）
島津製作所業務系システム子会社
・ソフトウェア開発技術者
↓障害対策専任
↓内部統制
・基盤技術標準化 (現在)
3
参加団体
・Redmine大阪
・AFFORDD 関西部会

お話しすること
4
１）200万チケットでもサクサク動くRedmineの全レシピ*
２）Redmine2.6 を 3.4 へUpdateすると平均で○○％速くなる
３）Ruby2.0 を 2.4 へUpdateすると平均で○○％速くなる
４）HDDをSSDに変更すると平均で○○％速くなる
５）非索引型の全文検索は○○万チケットで性能限界に到達するが、
FTS-Pluginの導入によって○○倍速くなり、
200万チケットの環境で平均○○～○○秒で全文検索できる
６） Redmineチューニング事例 9種
*全レシピ：設定値の一括ダウンロードはこちら (GitHub Gist)
Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt
https://gist.github.com/akahane92/771f9a52d81af9864dd8

お話ししないこと
5
１）大規模な並列トランザクション
２）DBMSチューニングの秘境探索

ご注意
6
本発表の内容には様々な設定が含まれていますが、
ご利用は自己責任でお願い致します。
参考になさった場合に生じたいかなる損害も補償できません。
あらかじめご了承下さい。

Redmine使用状況 (アンケート結果）
7
使用しているRedmineは？
有効回答数 69件、複数回答（2017/8/26 Redmine大阪 #17）
Redmine 3.0～3.3
65%
Redmineを使用していない
17%
Redmine 3.4.x
8%
Redmine 2.x
10%
Redmine 3.0～3.3
Redmine 3.4.x
Redmine 2.x
Redmine 0.x
Redmine 1.x
trunk

8
使用しているRedmineは？
Redmine 3.0～3.3
65%
17%
Redmine 3.4.x
8%
Redmine 2.x
10%
Redmine 3.0～3.3
Redmine 3.4.x
Redmine 2.x
Redmine 0.x
Redmine 1.x
trunk
Redmine3.x ：73％
Redmine2.x ：10％
未使用：15％

9
Redmineの環境と構築方法は？
ソース入手
（Linux), 21%
使用していない,
19%
Bitnami(Window
s), 15%
Bitnami(Linux),
11%
ソース入手
（Win), 11%
11%
6%
4%
0% ソース入手（Linux)
使用していない
Bitnami(Windows)
Bitnami(Linux)
ソース入手（Win)
その他
クラウドサービス
VMイメージ
RPM等パッケージ
ソース入手（MacOS)
ソース入手（JRuby)
ALMinium

10
Redmineの環境と構築方法は？
ソース入手
（Linux), 21%
使用していない,
19%
Bitnami(Window
s), 15%
Bitnami(Linux),
11%
ソース入手
（Win), 11%
11%
6%
4%
0% ソース入手（Linux)
Bitnami(Windows)
Bitnami(Linux)
ソース入手（Win)
その他
クラウドサービス
VMイメージ
RPM等パッケージ
ソース入手（MacOS)
ソース入手（JRuby)
ALMinium
UNIX Like ：48％
Windows ：32％
その他：20％

11
Redmineの使用年数は？
3年以上
47%
15%
使い始めたばかり
12%
1～3年ぐらい
15%
1年ぐらい
11%
3年以上
1～3年ぐらい
1年ぐらい

12
Redmineの使用年数は？
3年以上
47%
15%
12%
1～3年ぐらい
15%
1年ぐらい
11%
3年以上
1～3年ぐらい
1年ぐらい
使用者 85%

教えて下さい
13
Redmine
・遅いと感じている方は？
・性能チューニング経験は？
・使用しているDBMSは？
（Postgresql、MySQL、SQLite、他）
Eric Peacock
https://www.flickr.com/photos/evilpeacock/6365513881/

目次
14
第１部背景と要求
第２部チューニングの基本
第３部ベンチマーク
第４部性能改善事例集
第５部まとめ
第６部付録 14

目次
15
第５部まとめ
第６部付録 15

株式会社島津製作所
2017年3月31日現在
創業｜
設立｜
資本金｜
従業員数｜
3,422億円 (2017年3月期)グループ売上高｜
社是｜科学技術で社会に貢献する
経営理念｜｢人と地球の健康｣への願いを実現する
16
11,528名 (連結)
明治8（1875）年
大正6（1917）年
266億円

事業領域
産業機器
航空機器医用機器
分析・計測機器
17

概要
18
島津製作所グループ
業務システム
情報系
子会社委託
IT全般統制
ISO
内部統制
省庁監査

概要
19
島津製作所グループ
業務システム
情報系
子会社委託
IT全般統制
ISO 他
内部統制
省庁監査
複数の統制･認証に対応
大量の記録が必要

概要｜背景モデル
20
要件結果
業務用ITシステムの全般的な管理記録は
内部統制や各種認証（ISO,ISMS,省庁監査）の
要求に答えなければならない
•記録と整合
•精査と承認
•追跡可能性
•目的合理性
•品質管理
•セキュリティー

概要｜背景モデル
21
課題 3 課題・要望
問合せ受付
調査と確認
状況報告
方針決定
対処と確認
結果報告
時
間課題 2 変更
問合せ受付
調査と確認
状況報告
方針決定
対処と確認
結果報告
時
間課題１トラブル
問合せ受付
調査と確認
状況報告
方針決定
対処と確認
結果報告
時
間複数
ユーザー複数
ユーザー
複数
ユーザー
複数
ユーザー複数
ユーザー
複数
担当者
C事業部
B事業部
A事業部 X System
Y System
Z System
関係者増加／事案多様化／システム増加・分散
N ： N ： N

概要｜業務システムの運営状況
22
業務システム
１００種
利用者
7000人
事案
36000件
改版(コミット)
20000回
1700
KLOC
開発運用
２００人
／年
／年
／年
自動生成コード含む７～２0年超

概要｜問題要約
23
1. 人の記憶が頼り「生き字引き」
2. システム毎の管理台帳で情報お蔵入り
3. 経緯は担当者のMail-Box に蓄積
4. システムと組織の壁が情報流通を阻害
5. パートナー契約、引継ぎ不足
6. 横断検索できない
7. ツールが現実を表現できない
8. 統制･監査･査察への対応負担増

概要｜解決策
24
統合管理
全面導入
Issue
Tracking
System

概要｜事案関係モデル
3.6万件／年
２万コミット／年
／年
関係性
25
記憶の消滅
×
二次元 Excel 表現できる…何か

概要｜事案関係モデル
3.6万件／年
２万コミット／年
／年
関係性
26
記憶の消滅
×
二次元 Excel ITS
OSS

概要｜ITS導入の全体像
27
Project A
問合せ
要望･課題
障害･バグ
タスク
Project B
問合せ
要望･課題
障害･バグ
タスク
課題管理システム
(ITS)
版数管理ツール
■日常業務に浸透
•トータルで負担減少
•状態の掌握が容易
•コミュニケーション促進
■トレーサビリティー
一意性
永続的な連鎖性
履歴追跡性
■変化への適応
状況変化を記録し追従
後々の参照が容易に
SVN

概要｜放置チケット対策の定着
28
週次ミーティングで、
積極的にチケット完了
ITSを使った会議

概要
・プロジェクト数、ユーザー数の経年変化
29
0
50
100
150
200
250
300
350
400
450
500
0
20
40
60
80
100
120
140
160
180
200
2010 2011 2012 2013 2014 2015 2016 2017
プロジェクト数 ITSユーザー数
ユ
ー
ザ
ー
数
プ
ロ
ジ
ェ
ク
ト
数
Project数182
User数 459
調査日 2017/7

概要｜チケットの発行数と完了率
30
調査日 2017/7
0
10
20
30
40
50
60
70
80
90
100
0
5,000
10,000
15,000
20,000
25,000
30,000
35,000
40,000
45,000
50,000
2010 2011 2012 2013 2014 2015 2016 2017
完
了
率
チ
ケ
ッ
ト
発
行
数
Ticket発行数完了率近似曲線（線形）
完了率 87% → 93%
累計 26万件 3,500/月
％

0
20
40
60
80
100
120
140
160
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
2010 2011 2012 2013 2014 2015 2016 2017
完
了
所
要
日
数
の
平
均
完
了
所
要
日
数
の
分
布
6ヶ月以上
6ヶ月
3ヶ月
1ヶ月
2週間
1週間
1日
平均完了日数
概要｜完了所要日数の分布と平均
調査日 2017/7
日
2011年 147日
2016年 41日

概要｜チケット説明欄の文字数変化
32
0
100
200
300
400
500
600
700
800
900
1000
0
5,000
10,000
15,000
20,000
25,000
30,000
35,000
40,000
45,000
2009 2010 2011 2012 2013 2014 2015 2016 2017
チ
ケ
ッ
ト
毎
の
記
録
文
字
数
チ
ケ
ッ
ト
発
行
数
チケット発行数説明欄文字数（平均）近似曲線（線形）
2011年 529文字
2016年 738文字
調査日 2017/7
2016年 2億7千万文字
2017年 3億3千万文字
文字

0
0.2
0.4
0.6
0.8
1
1.2
1.4
0
10,000
20,000
30,000
40,000
50,000
60,000
2010 2011 2012 2013 2014 2015 2016 2017
チ
ケ
ッ
ト
毎
の
添
付
フ
ァ
イ
ル
数
チ
ケ
ッ
ト
発
行
数
チケット発行数添付ファイル数 1チケット毎の添付数
概要｜添付ファイル数の経年変化
33
ファイル
調査日 2017/7
2017年 26万3千ファイル

概要｜チケット関係性の経年変化
34
関係性カウント
線をカウントする
例）３カウント
Ticket
Ticket
Ticket
Ticket
関係記録数
2011年 11%
2015年 22%
調査日 2016/9
0%
5%
10%
15%
20%
25%
30%
0
5
10
15
20
25
2010 2011 2012 2013 2014 2015 2016
関
係
保
持
割
合
チ
ケ
ッ
ト
発
行
数
の
累
計
万
チケット発行数累計関係数累計関係保持割合線形 (関係保持割合)

0
20
40
60
80
100
120
140
160
180
0
500
1,000
1,500
2,000
2,500
3,000
2010 2011 2012 2013 2014 2015 2016 2017
完
了
所
要
日
数
平
均
障
害
・
バ
グ
チ
ケ
ッ
ト
数
障害・バグチケット数完了所要日数平均
概要｜障害･バグチケット数と完了所要日数の平均
35
調査日 2017/7
No Ticket,
No Commit 開始
日
所要日数平均
157日 → 56日

概要｜｢障害･バグ｣チケット密度
36
0
10
20
30
40
50
60
70
80
90
0
5,000
10,000
15,000
20,000
25,000
30,000
35,000
40,000
45,000
2011 2012 2013 2014 2015 2016 2017
障
害
・
バ
グ
チ
ケ
ッ
ト
密
度
チ
ケ
ッ
ト
発
行
数
チケット発行数
障害･バグチケット発行数
障害･バグチケット密度
障害･バグチケット密度
(Spike除去)
2012年 59件/KT
2016年 52件/KT
調査日 2017/7
件／KT
(Kilo Ticket)

概要｜監査手続の定性評価
37
【例示】｢全てのIT統制対象システムにおいて、任意の
6ヶ月間に発生した全ての変更事案の中から、設計書と
プログラムの両方、或いはいずれかを変更し、かつ、
データ強制変更を伴う事案の一覧を提出。ここから25
件をサンプリングし承認行為を示す証憑･証跡を提出｣
３時間以内
複数人がかりで
２〜３日

概要｜まとめ
38
統制実現
コスト低減
属人性軽減
品質, CS向上
業績貢献
【経営要求】
【現場要求】
現業務を表現可能
入力コストに見合う
いつでもどこでも
素早く見つかる
休みやすい
【管理手法】
【統制要求】
IT全般統制
ISO
省庁監査
一意識別
↓
関連維持
↓
追跡可能
↓
信頼可能
現場の利益を動機とする
部分最適型の行動規範
が、結果として経営要求
を満たす統合情報基盤と
して、全体最適型の均衡
を得た

概要｜まとめ
39
１）100種の業務システムを200人が運用する現場
２）IT統制に対応するため高水準の管理品質を維持
網羅性は必達（全員が全情報を入力し続ける）
３）文房具：常にサクサクの応答性能と盤石な安定性
４）運営のための余力は皆無。省力化の徹底と、
安定性･信頼性の同時成立が不可欠（さもないと帰れない）

目次
40
第５部まとめ
第６部付録 40

目次
41
第５部まとめ
第６部付録 41

チューニングの基本
42図引用元： http://ja.wikipedia.org/wiki/ボトルネック概念図.png

43図引用元： http://ja.wikipedia.org/wiki/ボトルネック概念図.png
電子計算機
ネットワークシステム
ボトルネックの
発見と解消

 ボトルネックはどこか？
44
＃対象対策例
１通信狭帯域を回避 Ethernet
２情報量圧縮 HTML, Text
３電子計算再処理を回避多段キャッシュ
４永続化高速装置へ置換 HDD
５アルゴリズム
算法選択による
計算量削減
Sort, Index, GC

 対策１狭帯域通信を避ける
45
Ethernet等の
低速通信
2M, 10M, 100Mbit / 秒
経路上の最も狭い帯域

Local Loopback adapter
同一OS内のTCP/UDP/Socket通信
 対策１狭帯域通信を避ける
46
狭帯域
６→３

 対策２情報量の圧縮
47
HTTP/1.1 Compression
情報量 1/4 ～ 1/10
最大10倍速

 対策３再処理回避
48
Server
Pass
enge
r
RAID
OS FS NW
Ruby
Rails
Redmine
DBMS
HTTP
Reverse
Proxy
Client
Browser
JavaScript / DOM
OS FS NW

 対策３再処理回避
49
Server
Pass
enge
r
RAID
OS FS NW
Ruby
Rails
Redmine
DBMS
HTTP
Reverse
Proxy
Client
Browser
JavaScript / DOM
OS FS NW
㋖㋖
㋖㋖
㋖
㋖
㋖
㋖
㋖
㋖
㋖㋖
・潤沢なメモリ
・多段キャッシュ

 対策４永続化
50* 情報の永続化「電源をOFFにしてもデータが消えないようにすること」
Server
Pass
enge
r
RAID
OS FS NW
Ruby
Rails
Redmine
DBMS
HTTP
Reverse
Proxy
情報の永続化*
SSDの登場
劇的な速度向上

 対策５算法選択による計算量削減
51
算法の選択による
速度向上*
Sort, GC, Index
* 算法の変更によって計算処理量を減らし、より少ない時間で同一の処理を実施する
Server
Pass
enge
r
RAID
OS FS NW
Ruby
Rails
Redmine
DBMS
HTTP
Reverse
Proxy

 チューニング要点
52
Passenger5.1
OS CentOS7 （64bit）
Ruby 2.4
Rails4.2
Redmine 3.4
DBMS
MySQL
5.6
HTTP
Apache
2.4
Memory 4〜16GBCPU 4〜6 Cores
VMware （可用性、信頼性）
VCS
Subversion
1.8
HTTP
Reverse
Proxy
---
：8 Key Points
Network

 チューニング要点
53
Passenger5.1
Ruby 2.4
Rails4.2
Redmine 3.4
DBMS
MySQL
5.6
HTTP
Apache
2.4
Memory 4〜16GBCPU 4〜6 Cores
VMware （可用性、信頼性）
VCS
Subversion
1.8
HTTP
Reverse
Proxy
---
：8 Key Points
Network
Redmine本体は変更しない
安定、安全、信頼

目次
54
第５部まとめ
第６部付録 54

目次
55
第５部まとめ
第６部付録 55

ベンチマーク
56
【背景】
・年間36,000チケットを起票
・業務の中心にITS（Redmine）
・処理遅延や障害停止の回避は必須
【2012年10月】
・ITSの業務活用が急拡大（10万チケット越）
・200万チケットまでの動作を先行して確認
・問題を洗い出して対策
【2015年5月、2016年3月、2017年7月】
・2012年の予測値と、今までの実績値を比較
・Redmine, Ruby, Rails, H/Wの変化
・再度、性能ベンチマークを計測して最適解を選ぶ

ベンチマーク
57
“サクサク”の
基準

ベンチマーク
58
画面応答時間の基準*とは？
100ms 直接操作している一体感
1000ms 遅延を感じつつも軽快
10000ms 集中限界、進捗表示必須
* 参考文献
Jakob Nielsen (1993). Response Times: The 3 Important Limits
http://www.useit.com/papers/responsetime.html
Miller, R. B. (1968). Response time in man-computer conversational transactions.
http://theixdlibrary.com/pdf/Miller1968.pdf

ベンチマーク
59
画面応答時間の基準*とは？
100ms 直接操作している一体感
1000ms 遅延を感じつつも軽快
10000ms 集中限界、進捗表示必須
* 参考文献
Jakob Nielsen (1993). Response Times: The 3 Important Limits
http://www.useit.com/papers/responsetime.html
Miller, R. B. (1968). Response time in man-computer conversational transactions.
http://theixdlibrary.com/pdf/Miller1968.pdf
Redmineは文房具

ベンチマーク｜実績値
60
Redmine月間アクセス数*の経年変化
* 8年分のApache アクセスログに記載されたURI - 2017年7月
0
500
1,000
1,500
2,000
2,500
0
5
10
15
20
25
30
35
40
2009 2010 2011 2012 2013 2014 2015 2016 2017
累
計
ア
ク
セ
ス
数
万
月
間
ア
ク
セ
ス
数
万
ITSアクセス数の経年変化
月平均アクセス数累計
累計：2000万月間：34万アクセス
調査日 2017/7

ベンチマーク｜実績値
8年間の運用結果*を集計
61
統計要約
最小値 : 1
第１四分位点 : 73
中央値 : 193
平均値 : 396
第３四分位点 : 317
最大値 :24708230
・1443万回の処理
・半分が200ms以下
・95%が1秒以下
・中央値193ms
* 8年分のProduction.logに記載された処理応答時間 (Redmine～DB) - 2017年7月
調査日 2017/7
100ms
31%
200ms
20%
300ms
21%
400ms
10%
500ms
600ms
700ms
800ms
900ms
1000ms
1000ms超
5%
100ms
200ms
300ms
400ms
500ms
600ms
700ms
800ms
900ms
1000ms
1000ms超

ベンチマーク｜評価対象
8年間の運用結果*を集計し、主要画面を決定
62
・2000万アクセス
・■チケット表示＋
■チケット一覧で50%
・利用頻度、遅延
を体感しやすい画面
33%
17%
6%
5%
5%
4%
3%
3%
3%
2%
2%
2% 2%
1%
1%
11%
2000万アクセス：ベンチマーク対象
チケット表示
チケット一覧
Wikiページ
(Redmine_Draft)
プロジェクトTop
検索（プロジェクト）
添付ダウンロード
（Work_Time)
ログイン画面
マイページ
添付画像サムネイル
RedmineTop
時間入力
リポジトリ閲覧
チケット起票
その他
* 8年分のApache アクセスログに記載されたITSのURI - 2017年7月
調査日 2017/7

ベンチマーク｜評価対象
8年間の運用結果*を集計し、主要画面を決定
63
・2000万アクセス
・■チケット表示＋
■チケット一覧で50%
・利用頻度、遅延
を体感しやすい画面
・ベンチマーク対象が
全体の59.4%を網羅
33%
17%
5%
3%
2%
2000万アクセス：ベンチマーク対象
チケット表示
チケット一覧
Wikiページ
(Redmine_Draft)
検索（プロジェクト）
添付ダウンロード
（Work_Time)
ログイン画面
マイページ
添付画像サムネイル
RedmineTop
時間入力
リポジトリ閲覧
チケット起票
その他
* 8年分のApache アクセスログに記載されたITSのURI - 2017年7月
調査日 2017/7

ベンチマーク｜テストデータ*
64
規模
0
2
4
6
8
10
12
14
16
0
500
1,000
1,500
2,000
2,500
3,000
10万件 20万件 30万件 50万件 70万件 100万件 150万件 200万件
記
録
文
字
数
億文字
デ
ー
タ
レ
コ
ー
ド
数
万行
チケット数
チケット数
Custom Field（種類）
Custom Field（記録）
添付ファイル
時間記録
注記欄
リポジトリ変更
リポジトリ変更セット
ウォッチャー
Ticket関係性
記録文字数
* 実データ10万チケットを複写して製作
調査日 2017/7
200万チケットは
・3000万レコード
・14億9000万文字
カスタムフィールドは
77種に固定

ベンチマーク｜テストデータ*
65
200万チケットの内訳
種類件数
チケット数 200万
カスタムField値 1,200万
添付ファイル 140万
時間記録 74万
注記欄 363万
ウォッチャー数 76万
Ticket間参照数 27万
記録文字数 14億9,000万
プロジェクト数 113
ユーザー数 457
* 実データ10万チケットを複写して製作
調査日 2017/7

ベンチマーク｜計測方法
66
Ruby OOBGC* Redmine
Ruby 2.0 2016/2/24 EOL Normal 2.6 / 3.0 / 3.1 / 3.2 / 3.3 / 3.4
Ruby 2.1 2017/3/31 EOL Normal / OOBGC 2.6 / 3.0 / 3.1 / 3.2 / 3.3 / 3.4
Ruby 2.2 2018/3/31 EOL Normal / OOBGC 2.6 / 3.0 / 3.1 / 3.2 / 3.3 / 3.4
Ruby 2.3 Normal / OOBGC 3.3 / 3.4
Ruby 2.4 Normal 3.4
組合せ
• OOBGC; Out Of Band Garbage Collection。Request処理中にRubyがGCを実行すると応答に遅延が生じる。
指定回数の処理毎に、間隙を縫ってGCを実行させることで応答の遅延を軽減する機能。
Passenger5.1
Ruby 2.4
Rails4.2
Redmine 3.4 DBMS
MySQL 5.6
（BP 8GB）
HTTP
Apache 2.4
Memory 16GBCPU 4cores
VMware ESXi 6 【CPU】Intel Xeon E5-2670 2.3GHz x2 (24Cores/48Threads) , 【Memory】256GB,
【SSD】8.7TB SAS RAID6, 【HDD】6TB 10K RPM SAS RAID6
VCS
Subversion1.9
環境構成
SSD/HDD NIC

ベンチマーク｜計測方法
67
① 主要画面8種に対して2並列でそれぞれ10回アクセスし、これを5回繰返して計測。
② 上記①を、下記3種のDBキャッシュ状態を順次切り替えて計測。
DBキャッシュ無 → DBキャッシュ保存･復元 → Fullメモリキャッシュ
③ 上記②のFullメモリキャッシュの計測値を平均した値を採用。
④ 上記①～③を、下記要素の全組み合わせ環境で繰り返す。
Redmineバージョン、 Rubyバージョン、OOGBC有無、
10万～200万チケット、SSD/HDD
10万 20万 30万 50万 70万 100万 150万 200万
所要時間合計（ミリ秒） 679.7 677.2 810.1 839.9 816.3 865.4 845.4 866.1
Redmine3.4
Ruby2.4.1
MySQL5.6
BufferPool 8G
SSD
主要画面７種のURI
/its34 14.2 14.3 14.8 13.1 13 12.9 13 12.9
/its34/projects 6.6 6.9 6.6 6.4 6.3 6.3 6.3 6.4
/its34/login 31 31.1 29.7 30.4 29.2 30 29.2 29
/its34/projects/sscope 89.1 87.6 86.4 87.5 84.4 86.2 84.1 84.3
/its34/issues?per_page=200 224.5 217.5 227.2 231.1 215.6 230 216.2 215
/its34/issues/1 86.9 69.1 186.5 194.3 184.8 191.6 182 184.5
/its34/issues/47548 149.4 161.3 168.6 184.1 192.8 215.3 225.5 244
/its34/issues/51782 78 89.4 90.3 93 90.2 93.1 89.1 90
調査日 2017/7

0 2000 4000 6000 8000 10000 12000
Ruby2.0 nml
Ruby2.1 oobgc
Ruby2.1 nml
Ruby2.2 nml
Ruby2.3 nml
Ruby2.2 oobgc
Ruby2.3 oobgc
10万 20万 30万 50万 70万 100万 150万 200万
ベンチマーク｜計測結果１
68
Redmine3.3の最速ベンチ
ms
調査日 2017/7

0 2000 4000 6000 8000 10000 12000
Ruby2.0 nml
Ruby2.1 oobgc
Ruby2.1 nml
Ruby2.2 nml
Ruby2.3 nml
Ruby2.2 oobgc
Ruby2.3 oobgc
10万 20万 30万 50万 70万 100万 150万 200万
69
ms
最も遅い Ruby2.0 に比して、
最も速い Ruby2.3+OOBGC は 32.1% 速い
調査日 2017/7

70
0 2000 4000 6000 8000 10000 12000
Ruby2.0 nml
Ruby2.3 oobgc
Ruby2.2 oobgc
Ruby2.1 oobgc
Ruby2.1 nml
Ruby2.2 nml
Ruby2.3 nml
Ruby2.4 nml
10万 20万 30万 50万 70万 100万 150万 200万
ms
調査日 2017/7

71
0 2000 4000 6000 8000 10000 12000
Ruby2.0_nml
Ruby2.3_oobgc
Ruby2.2_oobgc
Ruby2.1_oobgc
Ruby2.1_nml
Ruby2.2_nml
Ruby2.3_nml
Ruby2.4_nml
10万 20万 30万 50万 70万 100万 150万 200万
ms
最も遅い Ruby2.0 に比して、
最も速い Ruby2.4 は 26.9% 速い
調査日 2017/7

0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
Redmine
2.6
Redmine
3.0
Redmine
3.1
Redmine
3.2
Redmine
3.3
Redmine
3.4
10万 20万 30万 50万 70万 100万 150万 200万
ベンチマーク｜計測結果２
72
Redmine3.4は速いのか
ms
調査日 2017/7

0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
Redmine
2.6
Redmine
3.0
Redmine
3.1
Redmine
3.2
Redmine
3.3
Redmine
3.4
10万 20万 30万 50万 70万 100万 150万 200万
73
ms
・性能向上（平均）
2.6 → 3.0 8.8%
2.6 → 3.1 5.6%
2.6 → 3.2 4.2%
2.6 → 3.3 3.5%
2.6 → 3.4 24.9%
・原因推測
＋ Redmine3.4
＋ Ruby2.4
－機能増加
調査日 2017/7

0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
Redmine
2.6
Redmine
3.0
Redmine
3.1
Redmine
3.2
Redmine
3.3
Redmine
3.4
10万 20万 30万 50万 70万 100万 150万 200万
74
ms
・性能向上（平均）
2.6 → 3.0 8.8%
2.6 → 3.1 5.6%
2.6 → 3.2 4.2%
2.6 → 3.3 3.5%
2.6 → 3.4 24.9%
・原因推測
＋ Redmine3.4
＋ Ruby2.4
－機能増加Redmine2.6から3.4へアップデートすると、
平均で24.9％の性能向上が得られる
調査日 2017/7

0
2,000
4,000
6,000
8,000
10,000
12,000
Ruby2.0
nml
Ruby2.3
oobgc
Ruby2.2
oobgc
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.4
nml
Redmine 3.4
10万 20万 30万 50万 70万 100万 150万 200万
ベンチマーク｜計測結果３
75
Rubyバージョン変更の効果
Ruby2.0
nml
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.2
oobgc
Ruby2.3
oobgc
Redmine3.3
10万 20万 30万 50万 70万 100万 150万 200万
ms
調査日 2017/7

0
2,000
4,000
6,000
8,000
10,000
12,000
Ruby2.0
nml
Ruby2.3
oobgc
Ruby2.2
oobgc
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.4
nml
Redmine 3.4
10万 20万 30万 50万 70万 100万 150万 200万
76
Ruby2.0
nml
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.2
oobgc
Ruby2.3
oobgc
Redmine3.3
10万 20万 30万 50万 70万 100万 150万 200万
Redmine3.4 性能向上(平均)
Ruby2.0→2.4 26.9%
Ruby2.0→2.3OOBGC 24.5%
Ruby2.0→2.3 31.2%
ms
調査日 2017/7

0
2,000
4,000
6,000
8,000
10,000
12,000
Ruby2.0
nml
Ruby2.3
oobgc
Ruby2.2
oobgc
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.4
nml
Redmine 3.4
10万 20万 30万 50万 70万 100万 150万 200万
77
Ruby2.0
nml
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.2
oobgc
Ruby2.3
oobgc
Redmine3.3
10万 20万 30万 50万 70万 100万 150万 200万
Ruby2.0→2.4 26.9%
Ruby2.0→2.3 31.2%
Redmine3.4において、Ruby2.0から2.4へ
Updateすると平均26.9％の性能向上が得られる
調査日 2017/7
ms

78
OOBGCの効果
78
Ruby2.0
nml
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.2
oobgc
Ruby2.3
oobgc
Redmine3.3
10万 20万 30万 50万 70万 100万 150万 200万
調査日 2017/7
0
2,000
4,000
6,000
8,000
10,000
12,000
Ruby2.0
nml
Ruby2.3
oobgc
Ruby2.2
oobgc
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.4
nml
Redmine 3.4
10万 20万 30万 50万 70万 100万 150万 200万
ms

79
OOBGCの効果
0
2,000
4,000
6,000
8,000
10,000
12,000
Ruby2.0
nml
Ruby2.3
oobgc
Ruby2.2
oobgc
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.4
nml
Redmine 3.4
10万 20万 30万 50万 70万 100万 150万 200万 79
Ruby2.0
nml
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.2
oobgc
Ruby2.3
oobgc
Redmine3.3
10万 20万 30万 50万 70万 100万 150万 200万
OOBGC効果
OOBGC効果
Ruby2.3→2.3OOBGC -7.1%
調査日 2017/7
ms

ms
80
OOBGCの効果
0
2,000
4,000
6,000
8,000
10,000
12,000
Ruby2.0
nml
Ruby2.3
oobgc
Ruby2.2
oobgc
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.4
nml
Redmine 3.4
10万 20万 30万 50万 70万 100万 150万 200万 80
Ruby2.0
nml
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.2
oobgc
Ruby2.3
oobgc
Redmine3.3
10万 20万 30万 50万 70万 100万 150万 200万
OOBGC効果
OOBGC効果
Redmine3.3において、Ruby2.3にOOBGCを適用すると
平均 3.1％の性能向上が得られる
平均 -7.1％の性能低下が生じる
調査日 2017/7

ms
81
OOBGCの効果
0
2,000
4,000
6,000
8,000
10,000
12,000
Ruby2.0
nml
Ruby2.3
oobgc
Ruby2.2
oobgc
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.4
nml
Redmine 3.4
10万 20万 30万 50万 70万 100万 150万 200万 81
Ruby2.0
nml
Ruby2.1
oobgc
Ruby2.1
nml
Ruby2.2
nml
Ruby2.3
nml
Ruby2.2
oobgc
Ruby2.3
oobgc
Redmine3.3
10万 20万 30万 50万 70万 100万 150万 200万
OOBGC効果
OOBGC効果
平均 3.1％の性能向上が得られる
平均 -7.1％の性能低下が生じる
調査日 2017/7
【事実】
今回の計測では、Redmine3.4ではOOBGCの効果が
出なくなった。
【推測】
本ベンチマークの処理条件においては、Redmine3.4
の内部処理変更によってオブジェクト生成と破棄が少
なくなり、5回に1度の高頻度なOOBGCは不要（処理
コスト＞メリット）になったのではないかと推測。
【知見】
Ruby2.3でRedmine3.4を動作させる場合は、利用条
件によってOOBGCが有効でない場合があるとわかっ
た。
Redmine3.4は、Ruby2.4で動作させるのが最速。

ベンチマーク｜計測結果４
82
過去のRedmineと比較
Redmine自体は速くなった？遅くなった？
調査日 2017/7

0
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
Redmine1.4
最
速
Redmine2.0
最
速
Redmine2.1
最
速
Redmine2.3
最
速
Redmine2.6
最
速
Redmine3.0
最
速
Redmine3.1
最
速
Redmine3.2
最
速
Redmine3.3
最
速
Redmine3.4
最
速
10万 20万 30万 50万 70万 100万 150万 200万
83
ms
調査日 2017/7

0
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
Redmine1.4
最
速
Redmine2.0
最
速
Redmine2.1
最
速
Redmine2.3
最
速
Redmine2.6
最
速
Redmine3.0
最
速
Redmine3.1
最
速
Redmine3.2
最
速
Redmine3.3
最
速
Redmine3.4
最
速
10万 20万 30万 50万 70万 100万 150万 200万
84
最速ベンチマークを
比較すると、
2.3 → 2.6 - 30%
2.3 → 3.4 - 5.9%
性能が低下してい
る。
ms
調査日 2017/7

0
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
Redmine1.4
最
速
Redmine2.0
最
速
Redmine2.1
最
速
Redmine2.3
最
速
Redmine2.6
最
速
Redmine3.0
最
速
Redmine3.1
最
速
Redmine3.2
最
速
Redmine3.3
最
速
Redmine3.4
最
速
10万 20万 30万 50万 70万 100万 150万 200万
85
ms
性能変化の原因推測
＋ Redmine内部改善
＋ Ruby高速化
＋ Multi Thread対応
＋ Rails4.2の内部改善
－機能増加
※ Redmine2.3以前の計測は当時の
計算機とRuby1.8, 1.9, 2.0による
もの。現在は電算機の能力が向上し
ており比較精度は完全でない。よっ
て参考値とする。
調査日 2017/7

0
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
Redmine1.4
最
速
Redmine2.0
最
速
Redmine2.1
最
速
Redmine2.3
最
速
Redmine2.6
最
速
Redmine3.0
最
速
Redmine3.1
最
速
Redmine3.2
最
速
Redmine3.3
最
速
Redmine3.4
最
速
10万 20万 30万 50万 70万 100万 150万 200万
86
ms
機能増加
Redmine
2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 3.2, 3.3, 3,4
Spent time
2013-03 ～ 2017-07
Includes
306 Features implemented
495 Patches applied
561 Defects fixed
Still very fast and
reliable!
調査日 2017/7

0
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
Redmine1.4
最
速
Redmine2.0
最
速
Redmine2.1
最
速
Redmine2.3
最
速
Redmine2.6
最
速
Redmine3.0
最
速
Redmine3.1
最
速
Redmine3.2
最
速
Redmine3.3
最
速
Redmine3.4
最
速
10万 20万 30万 50万 70万 100万 150万 200万
87
ms
機能増加
Redmine
2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 3.2, 3.3, 3,4
Spent time
2013-03 ～ 2017-07
Includes
192 Features
294 Patches
406 Defects repaired
Still so fast and reliable!
・Redmine2.3を3.4へUpdateすると5.9%性能が
低下する
・多くの有益な機能が追加されている。
コア開発チームの努力と技術の進歩により、
応答性能の低下は最小限にとどまった。
調査日 2017/7

ベンチマーク｜小まとめ
88
Redmine3.4の性能が大幅に改善した主な理由
理由1：Ruby2.3, 2.4の処理性能向上
Ex. Towards Faster Ruby Hash Tables Vladimir Makarov
理由2：Redmine core パフォーマンス改善11種
Issue# Subject
25022 Add an index on attachments.disk_filename
24865 Load associations of query results more efficiently
24839 Minor performance improvement - Replace count by exists?
24787 Don't preload all filter values when displaying issues/time entries
24587 Improve custom fields list performance
24433 The changeset display is slow when changeset_issues has very many
records
23987 Add an index on issues.parent_id
23743 Add index to workflows.tracker_id
23519 Don't preload projects and roles on Principal#memberships association
22850 Speedup remove_inherited_roles
21608 Project#allowed_to_condition performance

ベンチマーク｜計測結果5
89
今回のベンチマークはSSD主体で行った。
HDDとSSDの性能差はどの程度か？

0
2000
4000
6000
8000
10000
12000
Redmine2.3 HDD Redmine2.6 HDD Redmine3.4 HDD Redmine3.4 SSD
10万 20万 30万 50万 70万 100万 150万 200万
ms
ベンチマーク｜計測結果５
90
HDDをSSDに置換する効果
調査日 2017/7

0
2000
4000
6000
8000
10000
12000
10万 20万 30万 50万 70万 100万 150万 200万
ms
91
Redmine3.4
HDD → SSD
平均18.6%の性能向上
【参考】2015年5月の調査
（今回の調査でSSDの性能を生
かし切れていない可能性）
調査日 2017/7

0
2000
4000
6000
8000
10000
12000
10万 20万 30万 50万 70万 100万 150万 200万
ms
92
【参考】2015年5月の調査
（今回の調査でSSDの性能を生
かし切れていない可能性）
HDDをSSDに交換すると、環境によって
平均18.6％～25.7％の性能向上が得られる
Redmine3.4
HDD → SSD
調査日 2017/7

ベンチマーク｜計測結果６
93
複数プラグイン導入の性能への影響
Redmineの性能に、プラグインがどの程度
の影響を与えるのか？

94
Redmine Pluginの多くはHook
によって各処理に割り込みをか
けている。性能が十分に考慮さ
れていないコードが呼び出され
た場合、応答性能に影響する。
選出した16種のうち8種は
Redmine3.0に未対応だった。
プラグインを追加して応答時間
を計測した結果、平均4%の性能
低下が計測された。
0
2000
4000
6000
8000
10000
12000
Redmine3.0 Redmine3.0 -
With Plugins
10万 20万 30万 50万 70万 100万 150万 200万
ms
調査日 2015/5

95
0
2000
4000
6000
8000
10000
12000
Redmine3.0 Redmine3.0 - With
Plugins
10万 20万 30万 50万 70万 100万 150万 200万
ms
Redmine Pluginの多くはHook
によって各処理に割り込みをか
けている。性能が十分に考慮さ
れていないコードが呼び出され
た場合、応答性能に影響する。
選出した16種のうち8種は
Redmine3.0に未対応だった。
プラグインを追加して応答時間
を計測した結果、平均4%の性能
低下が計測された。
不要なPluginを除去することで、
応答性能が平均4%向上するケースがある
調査日 2015/5

ベンチマーク｜計測結果７
96
FTS* 応答性能の計測
* FTS; Full Text Search 全文検索（索引型／非索引型）
Redmineの全文検索性能は改善されたのか？
FullTextSearchプラグインの導入によって、
どの程度の高速化されるのか？

0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
No
Cash
BP
Save &
Load
Full
Cash
No
Cash
BP
Save &
Load
Full
Cash
No
Cash
BP
Save &
Load
Full
Cash
Redmine3.0 非索引型 Redmine3.3 非索引型 Redmine3.3 索引型
全
文
検
索
所
用
時
間
積
算
（
秒
）
10万 20万 30万 50万 70万 100万 150万 200万
97
秒
調査日 2017/7
* BP; データベースのBuffer Pool メモリ。一度読込んだらメモリ上に貯蔵してDisk I/Oを削減
非索引型索引型
Redmineの全文検索処理
・非索引型
・索引型（プラグイン導入）
Redmine Full Text Search V0.4.0

0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
No
Cash
BP
Save &
Load
Full
Cash
No
Cash
BP
Save &
Load
Full
Cash
No
Cash
BP
Save &
Load
Full
Cash
全
文
検
索
所
用
時
間
積
算
（
秒
）
10万 20万 30万 50万 70万 100万 150万 200万
98
秒
調査日 2017/7
Redmineの全文検索処理
・非索引型
・索引型（プラグイン導入）
Redmine Full Text Search V0.4.0
計測時のDBキャッシュ状態３種
・No Cash
・BP* Save & Load（実用検索）
・Full Cashed
計測対象
1) /its33/search?q=ATO
2) /its33/search?q=WIP
3) /its33/search?q=sSCOPE
※ 実行条件、回数等は共通

0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
No
Cash
BP
Save &
Load
Full
Cash
No
Cash
BP
Save &
Load
Full
Cash
No
Cash
BP
Save &
Load
Full
Cash
全
文
検
索
所
用
時
間
積
算
（
秒
）
10万 20万 30万 50万 70万 100万 150万 200万
99
秒
調査日 2017/7
Redmine3.0の全文検索処理
【非索引型】
・No Cash： 12,193秒
10万チケット 24秒
・BP Save & Load： 9,415秒
・Full Cashed： 13秒
10万チケット 0.3秒

0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
No
Cash
BP
Save &
Load
Full
Cash
No
Cash
BP
Save &
Load
Full
Cash
No
Cash
BP
Save &
Load
Full
Cash
全
文
検
索
所
用
時
間
積
算
（
秒
）
10万 20万 30万 50万 70万 100万 150万 200万
100
調査日 2017/7
秒
【非索引型】
・No Cash： 555秒
・BP* Save & Load： 421秒

101
FTS 応答性能の計測
調査日 2017/7
【非索引型】
・No Cash： 555秒
・BP Save & Load： 421秒
0
100
200
300
400
500
600
No
Cash
BP Save
& Load
Full
Cash
No
Cash
BP Save
& Load
Full
Cash
Redmine3.3 非索引型 Redmine3.3 索引型
検
索
所
用
時
間
積
算
（
秒
）
10万
20万
30万
50万
70万
100万
150万
200万
秒

0
100
200
300
400
500
600
No
Cash
BP Save
& Load
Full
Cash
No
Cash
BP Save
& Load
Full
Cash
Redmine3.3 非索引型 Redmine3.3 索引型
検
索
所
用
時
間
積
算
（
秒
）
10万
20万
30万
50万
70万
100万
150万
200万
102
調査日 2017/7
【索引型】
・No Cash： 25秒
・BP Save & Load： 19秒
200万チケット 6秒（実用検索）
秒

10万
0.1M
20万
0.2M
30万
0.3M
50万
0.5M
70万
0.7M
100万
1M
150万
1.5M
200万
2M
平均
AVG
Redmine 3.0
非索引型
No Index
No Cash 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524
BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177
Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2
Redmine 3.3
非索引型
No Index
No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70
BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53
Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3
Redmine 3.3
索引型
FTS Indices
No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3
BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2
Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2
103
調査日 2017/7
全文検索所用時間（秒 sec）

10万
0.1M
20万
0.2M
30万
0.3M
50万
0.5M
70万
0.7M
100万
1M
150万
1.5M
200万
2M
平均
AVG
Redmine 3.0
非索引型
No Index
No Cash 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524
BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177
Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2
Redmine 3.3
非索引型
No Index
No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70
BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53
Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3
Redmine 3.3
索引型
FTS Indices
No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3
BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2
Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2
104
調査日 2017/7
非索引型の全文検索は10～20万チケットで性能限界に到達する。

10万
0.1M
20万
0.2M
30万
0.3M
50万
0.5M
70万
0.7M
100万
1M
150万
1.5M
200万
2M
平均
AVG
Redmine 3.0
非索引型
No Index
No Cash 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524
BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177
Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2
Redmine 3.3
非索引型
No Index
No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70
BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53
Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3
Redmine 3.3
索引型
FTS Indices
No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3
BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2
Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2
105
調査日 2017/7
Redmine3.3に索引型の全文検索Pluginを導入すると、実用的な検索
速度は3.0に比べて平均で約490倍速くなり、

10万
0.1M
20万
0.2M
30万
0.3M
50万
0.5M
70万
0.7M
100万
1M
150万
1.5M
200万
2M
平均
AVG
Redmine 3.0
非索引型
No Index
No Cash 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524
BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177
Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2
Redmine 3.3
非索引型
No Index
No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70
BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53
Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3
Redmine 3.3
索引型
FTS Indices
No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3
BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2
Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2
106
調査日 2017/7
Redmine3.3に索引型の全文検索Pluginを導入すると、実用的な検索
速度は3.0に比べて平均で約490倍速くなり、10万チケットを平均0.4
秒、200万チケット（≒15億文字）を平均6秒で検索可能になる。
2 million tickets include approximately 1.5 billion multibyte characters. Indexed FTS takes 6 sec.

ベンチマーク｜計測結果８
107
Redmine3.4は200万チケットでも
“サクサク”なのか？
0
100
200
300
400
500
600
700
800
900
1000
10万 20万 30万 50万 70万 100万 150万 200万
チケット表示（小）
チケット表示（大）
チケット表示（中）
チケット一覧
プロジェクト一覧
ログイン画面
Redmine Top
ms
調査日 2017/7

108
0
100
200
300
400
500
600
700
800
900
1000
10万 20万 30万 50万 70万 100万 150万 200万
チケット一覧
ログイン画面
Redmine Top
ms
チューニングの結果、Redmine3.4の
主要画面8種の平均応答時間は100ms
調査日 2017/7

109
0
100
200
300
400
500
600
700
800
900
1000
10万 20万 30万 50万 70万 100万 150万 200万
チケット一覧
ログイン画面
Redmine Top
ms
①全文検索 20秒
Full_Text_Search Plugin
②DB始動時の暖機運転5分
MySQL5.6, Postgres9.4に対策有り
(BufferPool dump/Restore)
調査日 2017/7
③BufferPool
8GB以上必須

110
0
100
200
300
400
500
600
700
800
900
1000
10万 20万 30万 50万 70万 100万 150万 200万
チケット一覧
ログイン画面
Redmine Top
ms
調査日 2017/7
③BufferPool
8GB以上必須
①全文検索 20秒
Full_Text_Search Plugin
②DB始動時の暖機運転5分
MySQL5.6, Postgres9.4に対策有り
(BufferPool dump/Restore)
3点対策して環境を整備すれば
200万チケットまで大丈夫

目次
111
第５部まとめ
第６部付録 111

目次
112
第５部まとめ
第６部付録 112

性能改善事例集
113
1. 8年間に渡るRedmineの運用におい
て、どのような問題が発生し、どう
やって解消したのか
2. 信頼性と安定性を維持する取組みの
「実際と限界」に焦点
3. 各種設定、チューニング方法、性能計
測方法を全て紹介する

計測 - 定量化手法
｢測定できないものは制御できない｣*
１．テスト実行時間（Redmine Built-in Test Code）
２．負荷ベンチマーク
・httpref http://www.hpl.hp.com/research/linux/httperf/
・wrk https://github.com/wg/wrk
・apache bench http://httpd.apache.org/docs/2.2/programs/ab.html
３．時間計測
・MySQL Slow-query ログ
・Redmineログ（Production.log, Development.log）
４．分析
・SQL実行計画（MySQL Workbench） https://www-jp.mysql.com/products/workbench/
・Chrome開発者ツール https://developer.chrome.com/devtools
・ネットワークスループット調査 iperf https://iperf.fr/ (Win版は× : ブルースクリーン死亡）
114* DeMarco, Tom., 1982, “You can’t control what you can't measure.”

チューニングチェックリスト20 １／２
115
１）Memory搭載・設定 DBMSに十分なキャッシュメモリを付与
２）Disk I/O HDD→ SSD
３）CPUコア数と同時並行処理数
４）OS選択 Linux ／起動プロセスとパッケージは必要最低限に削ぎ落とす。
５）DBMS選択 MySQL, Postgresql を使用して、必ず設定値を変更。
６）通信データ圧縮 Apache等 HTTP/1.1 Compression
７）Rubyバージョン利用可能な最新版を使用
1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 << 2.4
８）Webアプリケーションサーバー選択
WEBrick < < < Thin < < Passenger4 ≒ Passenger5
９）通信経路の狭帯域対策
10M/bps → 1G/bps (ケーブル交換、装置交換)
同一サーバーに置くことで通信帯域を広くする。Local Loopback は最速のNIC
１０）通信装置の性能向上
Normal-HubをSwitching-Hubへ交換しコリジョンによる通信効率低下を回避
１１）Subversionリポジトリの同期トリガを変更

116
１２）Subversionリポジトリの同期対象を指定する
１３）Subversionセッションキャッシュを付与する
１４）Subversion通信圧縮機能を利用する
１５）MySQLメモリチューニング
メモリを十分に付与し、全インデックスや全データをできるだけオンメモリ化
１６）カスタムフィールドの設定
「検索対象」の数が多いと極端に性能が落ちる
１７）DBMSサーバーの「暖機運転」
MySQL 5.6： Buffer-Pool Save & Load
PostgreSQL 9.4： pg_prewarm
１８）メール非同期送信（Async）
１９）Plugin導入数
２0）RubyとGC
・内部処理の大幅改善によりRuby2.4が最速のバージョン
・2位は Ruby2.3＋OOBGC（調査時点 2017/07 ）
チューニングチェックリスト20 １／２

事例１）【性能】全体がひどく遅い
117
【チューニング要素】
・H/W: HDD, Memory, CPU
・S/W: OS, DBMS, Http Server, Ruby, WebAppServer
・N/W: 通信帯域, Switching-Hub
１）Memory搭載・設定
DBMSに十分なキャッシュメモリを付与
２）Disk I/O HDD→ SSD
OS, DBMS, APL（Redmine他）はSSDに格納し、他のデータはHDDへ
３）CPUコア数と同時並行処理数
処理要求が集中した時の待ち行列
CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える。
- Passenger：自動調整（指定可能）
- Unicorn , Thin：起動サーバー数を増減

118
４）OS選択
Windows Bitnamiは５万件まで（制約：Ruby2.0系, DBMS 32bit）
最新のBitnami 3.3、3.4系はRuby2.3に。未調査だが期待。（制約：DBMS 32bit）
10万件扱うなら、Windows スクラッチ構築
15万件以上扱うなら200万件まで確認したLinux 64bitを推奨
５）DBMS選択
MySQL, Postgresql を使用して、必ず設定値を変更。Sqliteは１万チケットまで
６）通信データ圧縮
Apache等 HTTP/1.1 Compression
ネットワーク帯域が狭い時、通信輻輳時に高い効果

119
７）Rubyバージョン
利用可能な最新版を使用 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 << 2.4
８）Webアプリケーションサーバー選択
WEBrick < < < Thin < < Passenger4 ≒ Passenger5
（Unicornは未調査。速いがPassengerに比して扱い難い。上級者向け）
９）通信経路の狭帯域対策
10M/bps → 1G/bps (ケーブル＋Switch機器を交換)
Local Loopback は最速のNIC
１０）通信装置の性能向上
Normal-HubをSwitchへ交換しコリジョンによる通信効率低下を回避

事例２）【性能】リポジトリタブが遅い
120
・S/W: DBMS, Ruby, WebAppServer, Subversion Server
１）Subversionリポジトリの同期トリガを変更
SubversionとRedmine間のリポジトリ同期は、画面上のリポジトリタブをクリッ
クすると実施されるのが既定の動作。リビジョン数が増えてくると表示されるまで
に１分以上待たされる。
Redmine全体管理画面の「コミットを自動取得する」をOFFにして、Subversion
リポジトリ側のPost-Commit-Hookに同期スクリプトを組み込むことで、同期ト
リガが“コミット時”へ変更され、画面上のリポジトリタブは直ちに表示されるよう
になる。
２）Subversionリポジトリの同期対象を指定する
前述のPost-Commit-Hookは全プロジェクトを対象にするため、リポジトリ数が多
い場合5分以上かかる場合がある。ほぼ同時に5人が5回ずつコミットすると同期が
25並列で実行されてしまい、処理輻輳によりRedmineが応答しなくなる。
特定のProjectのみ同期を実施するよう、スクリプトに追記する。

事例２）【性能】リポジトリタブが遅い
121
・S/W: DBMS, Ruby, WebAppServer, Subversion Server
３）Subversionセッションキャッシュ
セッション毎にキャッシュメモリを付与（Subversion 1.7 以上）
４）Subversion通信圧縮機能
通信内容の圧縮レベル指定（Subversion 1.7 以上）
５）同一サーバーに置き、通信帯域を広くする
Local loopback, TCP/UDP/Socket通信は高速
６）MySQL テーブル更新が遅い
DBMSメモリ設定
SSD採用

事例３）【性能】検索が遅い
122
１）MySQLメモリチューニング
・メモリをできるだけ積み込む
・全インデックス、全データをオンメモリにする
２）カスタムフィールドの設定
「検索対象」の数が多いと極端に性能が落ちる
・H/W: Memory, CPU
・S/W: DBMS, Redmine

事例４）【性能】画面応答が遅い
123
１）Rubyのバージョン処理性能
1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 << 2.4
２）MySQLメモリチューニング
全インデックスと主要データをメモリに乗せる
３）初回アクセスが極端に遅い
MySQL 5.6 – Bufferpool save and load
PostgreSQL 9.4 - pg_prewarm
４）CPUコア数と同時並行処理数
処理要求が集中した時の待ち行列
CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える
- Passenger：自動調整（指定も可能）
- Thin：起動サーバー数を増減

事例４）【性能】画面応答が遅い
124
５）メール非同期送信（Async）
通知先が多い／メールサーバー（MTA）が遅い
６）Plugin導入数
導入数が多いと遅くなる。
大量データの応答性能まで考慮されているPluginはそう多くない。
７）通信データの圧縮
HTTP1.1/Compression （最大10倍速）

事例５）【性能】特定プラグインが遅い
125
・H/W: Memory, CPU
・S/W: DBMS, Ruby, WebAppServer
- 多くのプラグインは大量のデータ処理を想定していない。
極端に遅い場合はチューニングを施し、作者にパッチを送付できる。
処理遅延の原因は、SQL／コード実装／データ設計の３系統に大別できる。
SQLとコード実装は何とか対処もできるが、データ設計は大がかりな変更を
伴うので、テストコードが無ければ諦める。
- 例）Work Time 10倍速（画面応答 12秒 → 1秒）
プルリク https://bitbucket.org/tkusukawa/redmine_work_time/pull-request/17
・SQL調査手順
SlowクエリやSQL実行計画の調査方法はDBMS製品毎に異なるが、
類似機能は必ず存在する。
参考資料）Yahoo Japan社内向けDBチューニングセミナー
http://www.slideshare.net/techblogyahoo/mysql-58540246
・アプリコード調査手順（今回は実施せず）
・データ設計調査手順（今回は実施せず）

事例６）【信頼性】不安定で手間がかかる
126
１）3歩遅れの「枯れた技術」
末尾が3になったら導入例）Redmine 3.4.3
２）Windows <<< Linux OS
両方面倒を見てきたが、Ruby, Rails はWindowsで制限が多い（印象）
３）RedmineUpdateの工夫
新旧の環境を並立させて動作を確認し、準備が整ったら切り替える
４）OSS パッチの取込み
（Redmineに限って言えば）性能が改善され、問題は解消している。
Gitの追跡ブランチモードで git cloneしてLocal変更との共存を確保しつつ、
git pull だけでパッチを取りこめる。
例）mkdir /var/lib/its/rm34_its
cd /var/lib/its/rm34_its
git clone https://github.com/redmine/redmine.git .
git checkout -b 3.4-stable-local origin/3.4-stable
・H/W: Memory, CPU

127
５）Exception発生をMail 通知し、不具合を確実に検出
Redmine本体のExceptionは8年間でもほんの僅か
６）Redmine本体やRailsに手を入れない
Redmine本体の品質は極めて高い
テストコードのカバレッジ率がとても高い
http://www.redmine.org/builds/coverage/
７）Pluginは魅力的だが、あまり採用していない
Redmine本体のUpdateの足枷になる
テストコードが無く、DBテーブル構造を壊す例もある
【参考】
MTBF 8,820時間、MTTR 17時間、稼働率 99.8%
・H/W: Memory, CPU

128
８）完全なクローン環境を常設
・ゴミデータ、評価用データを本番に持ち込ませない
・要望を受けてから手動で同期
・誤入力の事故を防止するため、画面の色を変えている
・H/W: Memory, CPU
Dump and Restore

Munin: Average latencyMunin: Average latency
事例７）【性能】電算機のH/W資源不足
129
１）1VMに集約し、狭帯域通信を回避
２）CPU キャッシュの大きなものを複数コア用意
同時接続の処理数に合わせる
３）メモリできるだけ積み込む
４）SSD導入： SSD（OS, DBMS, Redmine）、HDD（その他データ）
↓ SSD切替点↓ SSD切替点
【HDD】突出ピークが無くなった。【SSD】ピークが無くなりI/O waitが小さくなった。
振れ幅が小さく、余力が見てとれる。

事例８）【性能】電算機通信網の帯域不足
130
＜Network＞
１）主要通信経路は1G/bpsに統一
10M/bps, 100M/bps のボトルネックを排除
２）Normal Hub → Switching Hub
コリジョン発生率の低減
３）Local Loopback通信
サーバー統合による通信の高速化

事例９）【性能】起動が遅い
131
＜DBMSの起動・再起動直後、初回アクセスだけが極端に遅い＞
１）DBMSサーバーの起動、再起動時は「暖機運転」が必要
「暖機運転」とは、DBMS再起動後にデータやインデックスを
メモリ上へ読み込む一連の処理。対象となるデータが増えると、
長時間かかるようになる
MySQL5.6系warm up 、Postgresql 9.4系pg_prewarmとして
実装されたBufferPool、Workloadの保存・読込機能によって
待ち時間が大幅に短縮される
MySQL
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup = ON

設定例１）基本S/W
132
OS, File-System
１）OS CentOS 6 / 7
プロセス、パッケージは必要最低限に削ぎ落とす。
（パッチ適用、最少の停止頻度、セキュリティー、メモリ）
２）File-System
Ext4 nobarrier チューン http://goo.gl/LYwfA0
３）Kernel設定
・[SSD] Disk I/O スケジューラーを cfq から deadline へ変更
・[SSD] SWAP抑制 vm.swappiness=1
※ 性能への影響は未確認

設定例２）ミドルウェア
133
DBMS, WebServer, Web Application Server
＜DBMS＞
１）チューニング設定
・MySQL 5.6
２）SSDによるI/O改善
・DBMS設定
MySQL innodb_flush_neighbors = 0
・配置構成
DBデータだけでなく、OS全体をSSDに乗せると効果大
・結果例
200万チケット分のDBデータをダンプ/リストア
HDD → SSDにより33％向上（5分早く終わる）

設定例２）ミドルウェア
134
DBMS, WebServer, Web Application Server
＜WebServer＞
３）通信圧縮 Compress, Gzip, Deflate 圧縮
＜Web Application Server＞
４）選択
WEBLick は性能 ×
運用の容易さは Unicorn < Passenger
５）Phusion Passenger 4 → 5 で 0.6％向上（計測の誤差範囲）
６）Passenger と OOBGC
Passenger4, Ruby2.1, OOBGC(gctools)で安定稼働（実績１年）
Passenger5, Ruby2.2, OOBGC(gctools)で安定稼働（実績6ヶ月）
Passenger5, Ruby2.3, OOBGC(gctools)で安定稼働（実績１年）
７）Passenger Enterprise
Multi Threadモードで○○％向上 (未調査)
利用料金は 5000円／月程度

設定例３）応用S/W
135
Ruby, OOBGC, Redmine, Subversion
＜Ruby＞
・GCの大幅改善によりRuby2.4が最速のバージョン
・2位は Ruby2.3＋OOBGC（調査時点 2017/07 ）
＜OOBGC for Ruby2.1, 2.2, 2.3＞
・Unicorn
GitHubのAman gupta-san(@tmm1)が作ったgctools original.
https://github.com/tmm1/gctools
・Passenger4/5
Ruby2.1は、Shirosaki-san(@shirosaki)のFork版
https://github.com/shirosaki/gctools
Ruby2.1/2.2/2.3は、@akahane92 のFork版
https://github.com/akahane92/gctools
This fork is based on Shirosaki-san(@shirosaki)’s gctools, and patched
Ruby2.2+ modifications from Charlie Somerville(@charliesome)’s pull-request.
https://github.com/tmm1/gctools/pull/14
→ Ruby2.3, 2.4（Normal）が総合的に見て最適選択。
OOBGC有は最大性能への向上を必要とする方向け（ちょいムズ）

136
＜Redmine＞
・カスタムフィールドの設定値「検索条件」の数を減らす。
例「14万チケットだと30種 ○○秒 → 5種〇秒」
（未計測だが効果は絶大）
・メール非同期送信(Async)
config/configuration.yml
production:
email_delivery:
delivery_method: :async_smtp
async_smtp_settings:

137
＜VCS＞
・Subversion Server 1.7以降のセッションキャッシュ付与機能
セッションキャッシュにより、通信応答速度が向上する。
・Subversion Server 1.7以降の通信圧縮機能
セッションデータ通信内容の多くはテキストデータ。
高い圧縮によって通信効率と応答性が向上する。

目次
138
第５部まとめ
第６部付録 138

目次
139
第５部まとめ
第６部付録 139

お話ししたこと
140
１）200万チケットでもサクサク動くRedmineの全レシピ*
２）Redmine2.6 を 3.4 へUpdateすると平均で24.9％速くなる
３）Ruby2.0 を 2.4 へUpdateすると平均で26.9％速くなる
４）HDDをSSDに変更すると平均で18. 5％～25. 7％速くなる
５）非索引型の全文検索は10万チケットで性能限界に到達するが、
FTS-Pluginの導入によって約490倍速くなり、
200万チケットの環境で平均0.4～6秒で全文検索できる
６） Redmineチューニング事例 9種
*全レシピ：設定値の一括ダウンロードはこちら (GitHub Gist)

まとめ｜実際
141
・初期値のままでは、1万チケットまで
・最低限のチューニングで、5万チケットまで（Windows Bitnami）
・最低限のチューニングで、10万チケットまで（Linux,MySQL,Windowsスクラッチ）
・ある程度のチューニングで、200万チケットまで（Linux,MySQL）
・最大限のチューニング（必要としてないので今はやっていない）
処理並行度を上げる、高IOPsのDisk採用、DBMSのI/O最適化
例）Linux, MySQL：
Nginx + Unicorn
ロードバランサ＋ WebAppServerクラスタリング
＋ DBMSクラスタリングと、R/W、R/Oの分離、SSD PCIe

まとめ｜限界
143
RedmineのFTS (非索引型)
（Redmineは悪くないが）10万チケットを超えた時点で検索が遅くなる。例
えばCPU４コアで稼働している時に、全プロジェクト横断の検索が４回ク
リックされ、並行で実行されるとCPUが占有されてRedmineが無応答になっ
てしまう。
→ 今回、 Full Text Search Plugin による対処策が得られた。
十分な性能を確認できたことから、検索に関する懸念要素が払拭さ
れた。
数十億文字を記録・蓄積している。何らかの索引型FTSをRedmine
コアに標準機能として組み込んで欲しい。
検索できなくて困っているのは添付ファイル。先頃、良策がPlanioさ
んから提供された。とても期待している。
( Feature #306 Full Text Search of files )

目次
144
第５部まとめ
第６部付録 144

目次
145
第５部まとめ
第６部付録 145

付録｜性能関連設定の一覧
146
本稿で扱った性能ベンチ－マークは下記設定による。
1. 計測プログラム
2. Apache2.2, 2.4 HTTP/1.1 通信圧縮
3. Passenger
4. MySQL 5.6 Linux, Bitnami
5. Subversion キャッシュ設定, 通信圧縮
6. Redmine Subversion同期 ProjectID指定
7. Redmine OOBGC for Unicorn and Passenger
8. OS File System
設定値の一括ダウンロードはこちら (GitHub Gist)

付録｜計測方法
147
計測プログラム
# bench.rb
# -*- coding: utf-8 -*-
url_list = [
"/its34 ",
"/its34/projects ",
"/its34/login ",
"/its34/projects/sscope ",
"/its34/issues?per_page=200 ",
"/its34/issues/1 ",
"/its34/issues/47548 ",
"/its34/issues/51782 "
]
puts "--- Environment ---"
puts `httpd -version`
puts `ruby -v`
puts `gem list --local passenger`
puts `export RAILS_ENV=production;
/var/lib/its/rm32_its/bin/about`
puts `export RAILS_ENV=production;
/var/lib/its/rm32_its/bin/bundle list`
ti = 5
result = []
url_list.each { |url|
rate_avg = ms_avg = 0
puts "--- #{url} ---"
ti.times {
res = `httperf --hog --server=localhost --port=80 --uri=#{url}
--num-conns 2 --num-calls 10 2> /dev/null | grep 'Request rate:' |
awk '{print$3,$5}' | sed -e 's/(//'`
num = res.split(' ').map{|s| s.to_f}
puts " rate: #{num[0]} req/s #{num[1]} ms/req"
rate_avg += num[0]
ms_avg += num[1]
sleep 0.2
}
rate_avg = (rate_avg/ti).round(1)
ms_avg = (ms_avg/ti).round(1)
result << [rate_avg, ms_avg]
puts " AVG: #{rate_avg} req/s #{ms_avg} ms/req"
}
rate_avg_total = (result.transpose[0].inject(:+)).round(1)
ms_avg_total = (result.transpose[1].inject(:+)).round(1)
puts "-------------------------“
result.size.times { |r|
puts "#{r+1} ¥t #{url_list[r]} ¥t #{result[r][0]} ¥t
#{result[r][1]}“
}
puts "T ¥t Total ¥t #{rate_avg_total} ¥t #{ms_avg_total}“
puts "-------------------------“
result.size.times { |r|
puts " AVG Rate: #{result[r][0]} req/s (#{result[r][1]}
ms/req)“
}

付録｜Apache2.2, 2.4
148
Apache2.4 /etc/httpd/conf.d/defelate.conf
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
DeflateCompressionLevel 1
DeflateMemLevel 8
# LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
# CustomLog /var/log/httpd/deflate_log deflate
<Location />
# MSIE masquerades as Netscape, but it is fine
BrowserMatch ¥bMSIE¥s(7|8) !no-gzip !gzip-only-text/html
FilterDeclare Compression CONTENT_SET
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'text/html'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'text/plain'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'text/css'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'text/javascript'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'text/xml'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/xhtml'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/xml'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/xhtml+xml'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/rss+xml'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/atom+xml'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/javascript'"
FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'image/svg-xml'"
FilterChain Compression
# Don't append Vary heder for specific files
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|t?gz|zip|bz2|sit|rar|lzh|exe)$ dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary Accept-Encoding env=!dont-vary
</Location>
</IfModule>
Apache2.2 /etc/httpd/conf.d/defelate.conf
<IfModule mod_deflate.c>
DeflateCompressionLevel 2
# LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
# CustomLog /var/log/httpd/deflate_log deflate
<Location />
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
FilterDeclare Compression CONTENT_SET
FilterProvider Compression DEFLATE resp=Content-Type $text/html
FilterProvider Compression DEFLATE resp=Content-Type $text/xml
FilterProvider Compression DEFLATE resp=Content-Type $text/css
FilterProvider Compression DEFLATE resp=Content-Type $text/plain
FilterProvider Compression DEFLATE resp=Content-Type $image/svg+xml
FilterProvider Compression DEFLATE resp=Content-Type $application/xhtml+xml
FilterProvider Compression DEFLATE resp=Content-Type $application/xml
FilterProvider Compression DEFLATE resp=Content-Type $application/rdf+xml
FilterProvider Compression DEFLATE resp=Content-Type $application/rss+xml
FilterProvider Compression DEFLATE resp=Content-Type $application/atom+xml
FilterProvider Compression DEFLATE resp=Content-Type $text/javascript
FilterProvider Compression DEFLATE resp=Content-Type $application/javascript
FilterProvider Compression DEFLATE resp=Content-Type $application/x-javascript
FilterProvider Compression DEFLATE resp=Content-Type $application/x-font-ttf
FilterProvider Compression DEFLATE resp=Content-Type $application/x-font-otf
FilterProvider Compression DEFLATE resp=Content-Type $font/truetype
FilterProvider Compression DEFLATE resp=Content-Type $font/opentype
FilterChain Compression
# Don't append Vary heder for specific files
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|t?gz|zip|bz2|sit|rar|lzh|exe)$ dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
Header append Vary Accept-Encoding env=!dont-vary
</Location>
</IfModule>
1. HTTP/1.1 通信圧縮

付録｜Passenger
149
Apache2 /etc/httpd/conf.d/passenger.conf
# Rails environment settings
#
RailsEnv production
# Multiple Redmine Envirnoment with Sub-URI
RailsBaseURI /its
RailsBaseURI /its_practice
# Remove http headers added by Passenger.
#
Header always unset "X-Powered-By"
Header always unset "X-Rack-Cache"
Header always unset "X-Content-Digest"
Header always unset "X-Runtime"
# Tuning Parameters for Passenger.
#
PassengerMaxPoolSize 20
PassengerMaxInstancesPerApp 4
PassengerPoolIdleTime 3600
PassengerHighPerformance on
PassengerStatThrottleRate 10
RailsSpawnMethod smart
RailsAppSpawnerIdleTime 86400
PassengerMaxPreloaderIdleTime 0
# For OOBGC < Experimental >
# PassengerSpawnMethod direct

付録｜MySQL 5.6
150
＜続き＞
default_storage_engine = InnoDB
explicit_defaults_for_timestamp = 1
# For SSD
innodb_flush_neighbors = 0
# MySQL Server System Variables
# http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
join_buffer_size = 128M
sort_buffer_size = 1M
query_cache_type = 1
query_cache_size = 128M
query_cache_limit = 6M
tmp_table_size = 512M
max_heap_table_size = 1G
read_rnd_buffer_size = 16M
key_buffer_size = 32M
max_allowed_packet = 16M
read_buffer_size = 1M
bulk_insert_buffer_size = 64M
max_connections = 100
character-set-server = utf8
skip-external-locking
thread_cache_size = max_connections/3
table_open_cache = 4096
table_open_cache_instances = 64
performance_schema = OFF
open_files_limit = 65500
max_prepared_stmt_count = 65528
MySQL 5.6 my.cnf
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html
[mysqld]
init-connect = SET NAMES utf8
# InnoDB Paramaters
# http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html
innodb_buffer_pool_size = 8G
innodb_log_file_size = 4G
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_log_files_in_group = 2
innodb_thread_concurrency = 16
innodb_concurrency_tickets = 5000
innodb_old_blocks_time = 1000
innodb_open_files = 300
innodb_stats_on_metadata = 0
innodb_checksum_algorithm = crc32
innodb_file_format = Barracuda
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120
innodb_print_all_deadlocks = ON
innodb_data_file_path = ibdata1:10M:autoextend
innodb_autoextend_increment = 64
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_buffer_pool_instances = 8
innodb_rollback_segments = 32
innodb_use_sys_malloc = 1

付録｜MySQL 5.6 for Bitnami
151
MySQL 5.6 my.cnf for Bitnami
# The MySQL server
[mysqld]
# set basedir to your installation path
basedir=C:/Bitnami/REDMIN~1.0-2/mysql
# set datadir to the location of your data directory
datadir=C:/Bitnami/REDMIN~1.0-2/mysql/data
port=3306
character-set-server=UTF8
collation-server=utf8_general_ci
max_allowed_packet=16M
bind-address=127.0.0.1
# The default storage engine that will be used when create new tables when
default-storage-engine=INNODB
#================================================================
# InnoDB Paramaters
# http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html
innodb_buffer_pool_size = 2G
innodb_log_file_size = 512M
innodb_thread_concurrency = 8
innodb_additional_mem_pool_size = 16M
# MySQL Server System Variables
# http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html
join_buffer_size = 128M
sort_buffer_size = 1M
query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 2M
tmp_table_size = 64M
max_heap_table_size = 64M
#================================================================

付録｜Subversion キャッシュ＆通信圧縮
152
Apache2.2, 2.4 /etc/httpd/conf.d/subversion.conf
<IfModule dav_svn_module>
SVNCompressionLevel 1
SVNInMemoryCacheSize 128000
SVNCacheFullTexts on
SVNCacheTextDeltas on
</IfModule>

付録｜ Redmine Subversion同期
153
Subversion Post-Commit-Hook - post-commit
#!/bin/sh
# Redmine のプロジェクト名とSubversionリポジトリ名が一致している条件下でのスクリプト
# 名称不一致の場合、本スクリプト中に名称を指定すればよい。（数が多いと面倒なのでお勧めしません）
export LANG="ja_JP.UTF8"
REPOS="$1"
REV="$2"
# Send E-Mail
${REPOS}/hooks/commit-email.rb "$REPOS" "$REV"
# Sync SVN Repo with ITS
REPOSHOME=`/usr/bin/dirname $REPOS`
APIKEY=`/bin/cat $REPOSHOME/common/APIKEY`
PJNAME=`/bin/basename $REPOS`
URL="http://localhost/its/sys/fetch_changesets?id=$PJNAME&key=$APIKEY"
/usr/bin/wget -q --no-proxy $URL -O /dev/null

付録｜ Redmine OOBGC for Unicorn
154
Unicornへのgctools導入
（参考）
http://tmm1.net/ruby21-oobgc/
http://qiita.com/jemiam/items/5c6e4595f3565f3c5562
Cookpad さんでは2016年1月末からgctoolsの利用を止める模様
http://k0kubun.hatenablog.com/entry/2016/01/23/231213
一方で、GitHub StaffのCharlie Somerville (@chariesome)
は gctoolsのruby2.2+パッチを作ってプルリクを通し、
gctoolsは2016/2/11に0.2.4へアップデートされた。
Aman Gupta @tmm1 gctools for Ruby 2.1 (GitHub)
https://github.com/tmm1/gctools # For Unicorn Ruby2.1, 2.2+

付録｜ Redmine OOBGC for Passenger
155
Passengerへの gctools導入
■About gctools
Aman Gupta @tmm1 gctools for Ruby 2.1 (GitHub)
http://tmm1.net/ruby21-oobgc/
Passenger (Hongli Lai on)
http://old.blog.phusion.nl/2014/01/31/phusion-passenger-now-supports-the-new-ruby-2-1-out-of-band-gc/
■ gctool gemのローカルビルド＆インストール (For Passenger)
cd /usr/local/src
git clone https://github.com/shirosaki/gctools # For Ruby2.1
# または
git clone https://github.com/akahane92/gctools # For Ruby2.1, 2.2, 2.3
gem build gctools.gemspec
gem install gctools-0.2.3.gem
■Passengerとgctools を Gemfile.localに追記
gem 'passenger'
gem "gctools", '0.2.3'

156
■config.ru パッチ
diff --git config.ru config.ru
index 2a89752..e3f49e6 100644
--- config.ru
+++ config.ru
@@ -1,4 +1,28 @@
# This file is used by Rack-based servers to start the application.
require ::File.expand_path('../config/environment', __FILE__)
-run RedmineApp::Application
+
+# ==================================================
+if defined?(PhusionPassenger)
+ require "gctools/oobgc"
+ GC::OOB.setup
+ PhusionPassenger.require_passenger_lib 'rack/out_of_band_gc'
+ use PhusionPassenger::Rack::OutOfBandGc, :strategy => :gctools_oobgc, frequency: 5
+
+ PhusionPassenger.on_event(:oob_work) do
+ # Phusion Passenger has told us that we're ready to perform OOB work.
+ t0 = Time.now
+ GC.start
+ Rails.logger.info "Out-Of-Bound GC finished in #{Time.now - t0} sec"
+ end
+end
+# ==================================================
+
+#if ENV['RAILS_RELATIVE_URL_ROOT']
+# map ENV['RAILS_RELATIVE_URL_ROOT'] do
+# run RedmineApp::Application
+# end
+#else
+ run RedmineApp::Application
+#end

157
Passengerへの gctools導入
■ /etc/httpd/conf.d/passenger.conf にOOBGC用の設定値を指定
# For OOBGC < Experimental >
PassengerSpawnMethod direct

付録｜OS File System
158
■/etc/fstab
/dev/mapper/vg_sms01-lv_root / ext4 defaults,nobarrier,noatime,discard 1 1
UUID=f94716b2-52d4-4e81-9a82-xxxxxxxxxxxx /boot ext4 defaults,discard 1 2
/dev/mapper/vg_sms01ex-lv_opt /opt xfs defaults,nobarrier,noatime 1 2
/dev/mapper/vg_sms01-lv_swap swap swap defaults,nobarrier,discard 0 0
注意：ディスクにアクセスできなくなったり、システム・アプリケーションが正しく動作しなくなる危険性があります。
バックアップを確保したうえで、理解できる方だけ自己責任でチャレンジしてください。
危険性が高いわりに、性能向上は体感しにくいので、専門家以外には推奨しません。

終
Special Thanks to
ブログ等で技術情報を公開して下さったみなさま
西川撒さん
My Family.

Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.

Similar to Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below. (20)

Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.

Editor's Notes