SSSSLIDE

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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved

ありがとう｡
Thanks a lot.
Merci beaucou2p.

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

お話しすること
１）200万チケットでもサクサク動くRedmineの全レシピ*
２）Redmine 2.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
4

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

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

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

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

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

Redmineの環境と構築方法は？
0%
ソース入手（Linux)
4%
6%
Bitnami(Windows)
ソース入手
Bitnami(Linux)
（Linux), 21%
11%
ソース入手（Win)
その他
使用していない,
クラウドサービス
ソース入手
19%
VMイメージ
（Win), 11%
RPM等パッケージ
UNIX Like ：48％
Bitnami(Linux),
ソース入手（MacOS)
Bitnami(Window
ソース入手（JRuby)
11% Windows
：32％
s), 15%
ALMinium
有効回答数 62件、複数回答
その他
：20％
（2017/8/26 Redmine大阪 #17）
10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ベンチマーク
画面応答時間の基準*とは？
100ms
直接操作している一体感
1000ms
遅延を感じつつも軽快
10000ms 集中限界、進捗表示必須
* 参考文献
Jakob Nielsen (1993). Response Times: The 3 Important Limits
http://www.useit.com/papers/responsetime.html
Mil er, R. B. (1968). Response time in man-computer conversational transaction 58
s.
http://theixdlibrar C
y op
. yrig
coht (C
m) S/him
p ad
dzuf B/usines
Mis Sys
lletem
r s
1Cor
9por
6 ation
8 . A
.p ll Rig
dfhts Reserved

ベンチマーク
画面応答時間の基準*とは？
100ms
直接操作している一体感
1000ms
遅延を感じつつも軽快
10000ms 集中限界、進捗表示必須
* 参考文献
Jakob Nielsen (1993). Response Times: The 3 Important Limits
Redmineは文房具
http://www.useit.com/papers/responsetime.html
Mil er, R. B. (1968). Response time in man-computer conversational transaction 59
s.
http://theixdlibrar C
y op
. yrig
coht (C
m) S/him
p ad
dzuf B/usines
Mis Sys
lletem
r s
1Cor
9por
6 ation
8 . A
.p ll Rig
dfhts Reserved

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

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

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

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

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

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

ベンチマーク｜計測方法
組合せ
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を実行させることで応答の遅延を軽減する機能。
環境構成
Redmine 3.4
DBMS
HTTP
VCS
Passenger5.1
Rails4.2
MySQL 5.6
Apache 2.4
Subversion1.9
Ruby 2.4
（BP 8GB）
OS
CentOS7 （64bit）
CPU 4cores
Memory 16GB
SSD/HDD
NIC
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
66

ベンチマーク｜計測方法
調査日 2017/7
① 主要画面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
主要画面７種のURI
Redmine3.4
/its34
14.2
14.3
14.8
13.1
13
12.9
13
12.9
Ruby2.4.1
/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
MySQL5.6
/its34/projects/sscope
89.1
87.6
86.4
87.5
84.4
86.2
84.1
84.3
BufferPool 8G /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
SSD
/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 6790

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

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

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

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

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

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

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

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

調査日 2017/7
12,000 ms
Redmine 3.4
Redmine3.3
10,000
8,000
6,000
4,000
2,000
0
nml
oobgc oobgc oobgc
nml
nml
nml
nml
nml
oobgc
nml
nml
nml
oobgc oobgc
Redmine3.4 性能向上(平均)
Ruby2.0→2.4
26.9%
Ruby2.0→2.3
31.2%
10万
20万
Rub 30万
y2.050万
→ 70
2. 万
3 10
OOB 0
G 万
C
150万
24.5 20
% 0万
10万 20万
Rub 30
y2.万0 50万
→2.70万
3 10
OOB 0万
GC 150 76
万
32. 20
10万
%

調査日 2017/7
12,000 ms
Redmine 3.4
Redmine3.3
10,000
8,000
6,000
4,000
2,000
0
nml
oobgc oobgc oobgc
nml
nml
nml
nml
nml
oobgc
nml
nml
nml
oobgc oobgc
R R
e edmi
dmine3.4
ne3. 性能向上
4
(平均)
において、Ru Red
by m
2. in
0 e3.3
から性能向上
2.4へ (平均)
Ruby2.0→2.4
26.9%
Ruby2.0→2.3
31.2%
Updateすると平均26.9％の性能向上が得られる
10万
20万
Rub 30万
y2.050万
→ 70
2. 万
3 10
OOB 0
G 万
C
150万
24.5 20
% 0万
10万 20万
Rub 30
y2.万0 50万
→2.70万
3 10
OOB 0万
GC 150 77
万
32. 20
10万
%

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

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

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

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

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

調査日 2017/7
9,000 ms
8,000
7,000
6,000
5,000
4,000
3,000
2,000
1,000
0
R
R
R
R
R
R
R
R
R
R
edm
edm
edm
edm
edm
edm
edm
edm
edm
edm
in
i
i
i
i
i
i
i
i
i
e1
ne2
ne2
ne2
ne2
ne3
ne3
ne3
ne3
ne3
.4
.
.
.
.
.
.
.
.
.

0
1
3
6
0
1
2
3
4
最速
最速
最速
最速
最速
最速
最速
最速
最速
最速
10万
20万
30万
50万
70万
100万
150万
200万
83

調査日 2017/7
9,000 ms
8,000
7,000
最速ベンチマークを
6,000
比較すると、
5,000
4,000
2.3 → 2.6 - 30%
3,000
2,000
2.3 → 3.4 - 5.9%
1,000
0
R
R
R
R
R
R
R
R
R
R
edm
edm
edm
edm
edm
edm
edm
edm
edm
edm
性能が低下してい
in
i
i
i
i
i
i
i
i
i
e1
ne2
ne2
ne2
ne2
ne3
ne3
ne3
ne3
ne3
る。
.4
.
.
.
.
.
.
.
.
.

0
1
3
6
0
1
2
3
4
最速
最速
最速
最速
最速
最速
最速
最速
最速
最速
10万
20万
30万
50万
70万
100万
150万
200万
84

調査日 2017/7
9,000 ms
8,000
性能変化の原因推測
7,000
6,000
＋ Redmine内部改善
5,000
＋ Ruby高速化
4,000
＋ Multi Thread対応
＋ Rails4.2の内部改善
3,000
2,000
－機能増加
1,000
※ Redmine2.3以前の計測は当時の
0
R
R
R
R
R
R
R
R
R
R
edm
edm
edm
edm
edm
edm
edm
edm
edm
edm
計算機とRuby1.8, 1.9, 2.0による
もの。現在は電算機の能力が向上し
in
i
i
i
i
i
i
i
i
i
e1
ne2
ne2
ne2
ne2
ne3
ne3
ne3
ne3
ne3
ており比較精度は完全でない。よっ
.4
.
.
.
.
.
.
.
.
.

0
1
3
6
0
1
2
3
4
て参考値とする。
最速
最速
最速
最速
最速
最速
最速
最速
最速
最速
10万
20万
30万
50万
70万
100万
150万
200万
85

調査日 2017/7
9,000 ms
8,000
機能増加
7,000
6,000
Redmine
5,000
2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 3.2, 3.3, 3,4
4,000
Spent time
3,000
2013-03 ～ 2017-07
2,000
Includes
1,000
306 Features implemented
0
R
R
R
R
R
R
R
R
R
R
edm
edm
edm
edm
edm
edm
edm
edm
edm
edm
495 Patches applied
in
i
i
i
i
i
i
i
i
i
e1
ne2
ne2
ne2
ne2
ne3
ne3
ne3
ne3
ne3
561 Defects fixed
.4
.
.
.
.
.
.
.
.
.

0
1
3
6
0
1
2
3
4
最速
最速
最速
最速
最速
最速
最速
最速
最速
最速
Still very fast and
reliable!
10万
20万
30万
50万
70万
100万
150万
200万
86

調査日 2017/7
9,000 ms
8,000
機能増加
7,000
6,000
Redmine
5,000
2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 3.2, 3.3, 3,4
4,000
Spent time
3,000
2013-03 ～ 2017-07
・Redmine2.3を3.4へUpdateすると5.9
2,000
%性能が
Includes
1,000
低下する
192 Features
0
R
R
R
R
R
R
R
R
R
R
edm
edm
edm
edm
edm
edm
edm
edm
・多くの有益な機能が追 edm edm
加され 294 Pat
ている ch
。 es
in
i
i
i
i
i
i
i
i
i
e1
ne2
ne2
ne2
ne2
ne3
ne3
ne3
n
コア開発チームの努力 e3 ne3
と技術 406 D
の進歩efects rep
によりaired
、
.4
.
.
.
.
.
.
.
.
.

0
1
3
6
0
1
2
3
4
最速
最速
最速
最速
最速
最速
最速
最速
最速
最速
応答性能の低下は最小限にと Still so
どまっfast a
た。 nd reliable!
10万
20万
30万
50万
70万
100万
150万
200万
87

ベンチマーク｜小まとめ
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 al 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#al owed_to_condition performance
88

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

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

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

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

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

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

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

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

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

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

調査日 2017/7
14,000
10万
20万
30万
50万
70万
100万
150万
200万
秒
全文検索
Redmine3.0の全文検索処理
12,000
【非索引型】
10,000
・No Cash：
12,193
所用時間
秒
10万チケット
24秒
8,000
100万チケット 207秒
6,000
積算（秒）
・BP Save & Load： 9,415秒
4,000
10万チケット
17秒
2,000
0
No
BP
Full
No
BP
Full
No
BP
Full
・Ful Cashed：
13秒
10万チケット
0.3秒
Load
Load
Load
100万チケット 2.2秒
200万チケット 2.7秒
非索引型
索引型
99
Cop
モリ上 ) Shimadz
に貯蔵u Busin
して ess
Di Ssysktem
I/ s C
O orporation

調査日 2017/7
14,000
10万
20万
30万
50万
70万
100万
150万
200万
秒
全文検索
12,000
【非索引型】
10,000
・No Cash：
555秒
所用時間
10万チケット
2秒
8,000
100万チケット
12秒
6,000
積算（秒）
・BP* Save & Load： 421秒
4,000
10万チケット
1秒
2,000
100万チケット
12秒
0
No
BP
Full
No
BP
Full
No
BP
Full
・Ful Cashed：
26秒
10万チケット
0.5秒
Load
Load
Load
100万チケット
5秒
200万チケット
8秒
非索引型
索引型
100
Cop
モリ上 ) Shimadz
に貯蔵u Busin
して ess
Di Ssysktem
I/ s C
O orporation

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

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

調査日 2017/7
10万 20万 30万 50万 70万 100万 150万 200万
平均
全文検索所用時間（秒 sec） 0.1M 0.2M 0.3M 0.5M 0.7M 1M
1.5M
2M
AVG
No Cash
23.5 39.6
61.4 100.4 143.2
206.9 5,415.2 6,203.4
1,524
Redmine 3.0
非索引型
No Index 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
No Cash
1.6
3.0
4.6
7.5
8.1
11.9
224.0
295.7
70
Redmine 3.3
非索引型
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
No Cash
0.5
0.9
1.2
2.0
2.7
3.8
6.0
8.0
3
Redmine 3.3
索引型
FTS Indices 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
10万 20万 30万 50万 70万 100万 150万 200万
平均
1.5M
2M
AVG
No Cash
23.5 39.6
61.4 100.4 143.2
206.9 5,415.2 6,203.4
1,524
Redmine 3.0
非索引型
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
No Cash
1.6
3.0
4.6
7.5
8.1
11.9
224.0
295.7
70
Redmine 3.3
非索引型
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
No Cash
0.5
0.9
1.2
2.0
2.7
3.8
6.0
8.0
3
Redmine 3.3
索引型
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
非索引型の全文検索は10〜20万チケットで性能限界に到達する。
104

調査日 2017/7
10万 20万 30万 50万 70万 100万 150万 200万
平均
1.5M
2M
AVG
No Cash
23.5 39.6
61.4 100.4 143.2
206.9 5,415.2 6,203.4
1,524
Redmine 3.0
非索引型
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
No Cash
1.6
3.0
4.6
7.5
8.1
11.9
224.0
295.7
70
Redmine 3.3
非索引型
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
No Cash
0.5
0.9
1.2
2.0
2.7
3.8
6.0
8.0
3
Redmine 3.3
索引型
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
Redmine3.3に索引型の全文検索Pluginを導入すると、実用的な検索
速度は3.0に比べて平均で約490倍速くなり、
105

調査日 2017/7
10万 20万 30万 50万 70万 100万 150万 200万
平均
1.5M
2M
AVG
No Cash
23.5 39.6
61.4 100.4 143.2
206.9 5,415.2 6,203.4
1,524
Redmine 3.0
非索引型
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
No Cash
1.6
3.0
4.6
7.5
8.1
11.9
224.0
295.7
70
Redmine 3.3
非索引型
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
No Cash
0.5
0.9
1.2
2.0
2.7
3.8
6.0
8.0
3
Redmine 3.3
索引型
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
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.
106

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

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

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

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

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

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

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

計測 - 定量化手法
｢測定できないものは制御できない｣*
１．テスト実行時間（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版は× : ブルースクリーン死亡）
* DeMarco, Tom., 1982, “You can’t control what you can't measure.”
114

チューニングチェックリスト20 １／２
１）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リポジトリの同期トリガを変更
115

チューニングチェックリスト20 １／２
１２）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 ）
116

事例１）【性能】全体がひどく遅い
【チューニング要素】
・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：起動サーバー数を増減
117

４）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
ネットワーク帯域が狭い時、通信輻輳時に高い効果
118

７）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へ交換しコリジョンによる通信効率低下を回避
119

事例２）【性能】リポジトリタブが遅い
・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のみ同期を実施するよう、スクリプトに追記する。
120

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

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

事例４）【性能】画面応答が遅い
１）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：起動サーバー数を増減
123

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

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

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

・H/W: Memory, CPU
５）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%
127

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

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

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

事例９）【性能】起動が遅い
＜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
131

設定例１）基本S/W
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
※ 性能への影響は未確認
132

設定例２）ミドルウェア
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分早く終わる）
133

設定例２）ミドルウェア
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円／月程度
134

設定例３）応用S/W
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 Somervil e(@charliesome)’s pull-request.
https://github.com/tmm1/gctools/pull/14
→ Ruby2.3, 2.4（Normal）が総合的に見て最適選択。
OOBGC有は最大性能への向上を必要とする方向け（ちょいムズ）
135

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

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

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

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

お話ししたこと
１）200万チケットでもサクサク動くRedmineの全レシピ*
２）Redmine 2.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)
140

まとめ｜実際
・初期値のままでは、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
141

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

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

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

付録｜性能関連設定の一覧
本稿で扱った性能ベンチ－マークは下記設定による。
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)
146

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

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

付録｜Passenger
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
149

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

付録｜MySQL 5.6 for Bitnami
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
#================================================================
151

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

付録｜ Redmine Subversion同期
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
153

付録｜ Redmine OOBGC for Unicorn
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+
154

付録｜ Redmine OOBGC for Passenger
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'
155

■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
156
+#end

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

付録｜OS File System
■/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
注意：ディスクにアクセスできなくなったり、システム・アプリケーションが正しく動作しなくなる危険性があります。
バックアップを確保したうえで、理解できる方だけ自己責任でチャレンジしてください。
危険性が高いわりに、性能向上は体感しにくいので、専門家以外には推奨しません。
158

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

SSSSLIDE

Redmineチューニングの実際と限界 - Redmine performance tuning

Kuniharu AKAHANE さんの他のスライド

関連するスライド

このスライドの内容

関連するタグ

SSSSLIDE