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

Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved

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

〜200万チケットでもサクサクなRedmineの作り方〜

第14回 RxTstudy 2016年3月5日改版第8回 Redmine.tokyo 2015年5月16日

株式会社島津ビジネスシステムズ基盤技術部赤羽根州晴 [email protected]

2

ありがとう｡Thanks a lot.

Merci beaucoup.


話者紹介

赤羽根州晴（@akahane92）島津製作所業務系システム子会社

・ソフトウェア開発技術者↓障害対策専任↓内部統制・基盤技術標準化 (現在)

3

参加団体・RxTstudy・AFFORDD 関西部会・JaSST関西


お話しすること

4

１）200万チケットでもサクサク動くRedmineの全レシピ*

２）Redmine 2.6 を 3.2 へUpdateすると平均で○○％速くなる

３）Ruby2.0 を 2.2 へUpdateすると平均で○○％速くなる

４）HDDをSSDに変更すると平均で○○％速くなる

５）Redmineチューニング事例 9種

６）全走査型の全文検索は○○万チケットで性能限界に到達する*全レシピ：設定値の一括ダウンロードはこちら (GitHub Gist)

Download: Setting_paramaters_for_Redmine_Performance_Tuning.txthttps://gist.github.com/akahane92/771f9a52d81af9864dd8

https://gist.github.com/akahane92/771f9a52d81af9864dd8


お話ししないこと

5

１）大規模な並列トランザクション

２）DBMSチューニングの秘境探索


ご注意

6

本発表の内容には様々な設定が含まれていますが、

ご利用は自己責任でお願い致します。

参考になさった場合に生じたいかなる損害も補償できません。

あらかじめご了承下さい。


Redmine使用状況 (アンケート結果）

7

使用しているRedmine 環境は？

有効回答数 65件、複数回答（2015/5/16 Redmine.Tokyo #8）



8



UNIX Like53%Windows/

Bitnami27%

Mac4%

未回答10%

未使用6% UNIX Like

Windows/Bitnami

Mac

未回答

未使用


UNIX Like53%Windows/

Bitnami27%

Mac4%

未回答10%

未使用6% UNIX Like

Windows/Bitnami

Mac

未回答

未使用


9


UNIX Like ：53％

Windows ：27％




10

Redmineの環境構築方法は？




11


ソースを入手40%

Bitnamiインストーラー

24%

rpm等パッケージ使用7%

ALMinium4%

仮想マシンイメージ3%

クラウドサービス3% 不明

12%

未回答7%

ソースを入手Bitnamiインストーラーrpm等パッケージ使用ALMinium仮想マシンイメージクラウドサービス不明未回答



ソースを入手40%

Bitnamiインストーラー

24%

rpm等パッケージ使用7%

ALMinium4%

仮想マシンイメージ3%

クラウドサービス3% 不明

12%

未回答7%

ソースを入手Bitnamiインストーラーrpm等パッケージ使用ALMinium仮想マシンイメージクラウドサービス不明未回答


12


スクラッチ構築： 40％

事前構築の展開： 38％

クラウド： 3％



教えて下さい

13

Redmine

・遅いと感じている方は？・性能チューニング経験は？・使用しているDBMSは？（Postgresql、MySQL、SQLite、他）

Eric Peacockhttps://www.flickr.com/photos/evilpeacock/6365513881/


目次

14

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

14


目次

15


15


株式会社島津製作所

2015年3月31日現在

1875年

1917年

266億円

創業｜設立｜資本金｜従業員数｜

3,147億円 (2015年3月期)

68社 (国内25社, 海外43社)グループ売上高｜グループ会社｜

社是｜科学技術で社会に貢献する経営理念｜｢人と地球の健康｣への願いを実現する

16

10,879名 (連結)


事業領域

産業機器

航空機器医用機器

分析・計測機器

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回

1700KLOC

開発運用２００人

／年

／年

／年自動生成コード含む７〜２0年超


概要｜問題要約

23

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


概要｜解決策

24

統合管理全面導入

IssueTrackingSystem


概要｜ITS導入の全体像

25

Project A

問合せ

要望･課題

障害･バグ

タスク

Project B

問合せ

要望･課題

障害･バグ

タスク

課題管理システム(ITS)

版数管理ツール

■日常業務に浸透•トータルで負担減少•状態の掌握が容易•コミュニケーション促進

■トレーサビリティー一意性

永続的な連鎖性履歴追跡性

■変化への適応状況変化を記録し追従後々の参照が容易に

SVN


概要｜放置チケット対策の定着

26

週次ミーティングで、積極的にチケット完了

ITSを使った会議


概要

・プロジェクト数、ユーザー数の経年変化

27

0

50

100

150

200

250

300

350

400

450

0

20

40

60

80

100

120

140

160

2010 2011 2012 2013 2014 2015プロジェクト数ユーザー数

ユーザー数

プロジェクト数

Project数 140User数 400


概要｜チケットの発行数と完了率

28

0

10

20

30

40

50

60

70

80

90

100

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

2010 2011 2012 2013 2014 2015

Ticket発行数完了率近似曲線（線形）完了率 87% → 95%

累計 188,000発行ペース 3,500/月


概要｜完了所要日数の分布と平均

0

10

20

30

40

50

60

70

80

90

100

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

2010 2011 2012 2013 2014

6ヶ月以上6ヶ月3ヶ月1ヶ月2週間1週間1日平均完了日数

日

29


概要｜障害･バグチケット数と完了所要日数の平均

300

20

40

60

80

100

120

140

0

500

1000

1500

2000

2500

2010 2011 2012 2013 2014

障害・バグチケット数完了所要日数平均所要日数平均129日 → 59日

No Ticket,No Commit 開始


概要｜｢障害･バグ｣チケット密度

31

0

20

40

60

80

100

0

10000

20000

30000

40000

2010 2011 2012 2013 2014

件／KT(Kilo Ticket)

チケット発行数

障害･バグチケット発行数障害･バグチケット密度障害･バグチケット密度(Spike除去)


概要｜監査手続の定性評価

32

【例示】｢全てのIT統制対象システムにおいて、任意の6ヶ月間に発生した全ての変更事案の中から、設計書とプログラムの両方、或いはいずれかを変更し、かつ、データ強制変更を伴う事案の一覧を提出。ここから25件をサンプリングし承認行為を示す証憑･証跡を提出｣

３時間以内複数人がかりで２〜３日


概要｜まとめ

33

統制実現コスト低減属人性軽減品質, CS向上業績貢献

【経営要求】

【現場要求】現業務を表現可能入力コストに見合ういつでもどこでも素早く見つかる休みやすい

【管理手法】

【統制要求】IT全般統制ISO省庁監査

一意識別↓

関連維持↓

追跡可能↓

信頼可能

現場の利益を動機とする部分最適型の行動規範が、結果として経営要求を満たす統合情報基盤として、全体最適型の均衡を得た


概要｜まとめ

34

１）100種の業務システムを200人が運用する現場

２）IT統制に対応するため高水準の管理品質を維持網羅性は必達（全員が全情報を入力し続ける）

３）文房具：常にサクサクの応答性能と盤石な安定性

４）運営のための余力は皆無。省力化の徹底と、安定性･信頼性の同時成立が不可欠（さもないと帰れない）


目次

35


35


目次

36


36


チューニングの基本

37図引用元： http://ja.wikipedia.org/wiki/ボトルネック概念図.png



38図引用元： http://ja.wikipedia.org/wiki/ボトルネック概念図.png

電子計算機ネットワークシステム

ボトルネックの発見と解消



ボトルネックはどこか？

39

＃対象対策例




40

＃対象対策例

１通信狭帯域を回避 Ethernet




41

＃対象対策例


２情報量圧縮 HTML, Text




42

＃対象対策例



３電子計算再処理を回避多段キャッシュ




43

＃対象対策例




４永続化高速装置へ置換 HDD




44

＃対象対策例




４永続化高速装置へ置換 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

Passenge

r

RAID

OS FS NW

Ruby

Rails

Redmine

DBMS

HTTP

Reverse Proxy

Client

BrowserJavaScript / DOM

OS FS NW


チューニングの基本対策３再処理回避

49

Server

Passenge

r

RAID

OS FS NW

Ruby

Rails

Redmine

DBMS

HTTP

Reverse Proxy

Client

BrowserJavaScript / DOM

OS FS NW

㋖㋖㋖㋖

㋖㋖

㋖㋖

㋖

㋖㋖㋖

・潤沢なメモリ・多段キャッシュ


チューニングの基本対策４永続化

50* 情報の永続化「電源をOFFにしてもデータが消えないようにすること」

Server

Passenge

r

RAID

OS FS NW

Ruby

Rails

Redmine

DBMS

HTTP

Reverse Proxy

情報の永続化*SSDの登場

劇的な速度向上


チューニングの基本対策５算法選択による計算量削減

51

算法の選択による速度向上*

Sort, GC, Index

* 算法の変更によって計算処理量を減らし、より少ない時間で同一の処理を実施する

Server

Passenge

r

RAID

OS FS NW

Ruby

Rails

Redmine

DBMS

HTTP

Reverse Proxy



チューニング要点

52

Passenger5

OS CentOS7 （64bit）

Ruby 2.2

Rails4.2

Redmine 3.2DBMS

MySQL5.6

HTTP

Apache2.4

メモリ 4〜16GBCPU 4〜6コア

VMware （可用性、信頼性）

VCS

Subversion1.8

HTTPReverseProxy

---

：8 Key Points

Network



チューニング要点

53

Passenger5

OS CentOS7 （64bit）

Ruby 2.2

Rails4.2

Redmine 3.2DBMS

MySQL5.6

HTTP

Apache2.4

メモリ 4〜16GBCPU 4〜6コア

VMware （可用性、信頼性）

VCS

Subversion1.8

HTTPReverseProxy

---

：8 Key Points

Network

Redmine本体は変更しない安定、安全、信頼


目次

54


54


目次

55


55


ベンチマーク

56

【背景】・年間36,000チケットを起票・業務の中心にITS（Redmine）・処理遅延や障害停止の回避は必須


ベンチマーク

57


【2012年10月】・ITSの業務活用が急拡大（10万チケット越）・200万チケットまでの動作を先行して確認・問題を洗い出して対策


ベンチマーク

58


【2012年10月】・ITSの業務活用が急拡大（10万チケット越）・200万チケットまでの動作を先行して確認・問題を洗い出して対策

【2015年5月、2016年3月】・2012年の予測値と、今までの実績値を比較・Redmine, Ruby, Rails, H/Wの変化・再度、性能ベンチマークを計測して最適解を選ぶ


ベンチマーク

59

“サクサク”の基準


ベンチマーク

60

画面応答時間の基準*とは？


ベンチマーク

61


100ms 直接操作している一体感

* 参考文献Jakob Nielsen (1993). Response Times: The 3 Important Limits

http://www.useit.com/papers/responsetime.htmlMiller, R. B. (1968). Response time in man-computer conversational transactions.

http://theixdlibrary.com/pdf/Miller1968.pdf

http://www.useit.com/papers/responsetime.html



ベンチマーク

62



1000ms 遅延を感じつつも軽快







ベンチマーク

63




10000ms 集中限界、進捗表示必須







ベンチマーク

64




10000ms 集中限界、進捗表示必須




Redmineは文房具




ベンチマーク

65

実測値


ベンチマーク｜実測値

66

Redmine月間アクセス数*の経年変化

* 6年分のApache アクセスログに記載されたURI - 2015年5月


ベンチマーク｜実測値

67

12,935 35,397

152,142

210,289 221,656

286,943 297,058

0

50,000

100,000

150,000

200,000

250,000

300,000

350,000

2009 2010 2011 2012 2013 2014 2015

Redmine月間アクセス数*の経年変化

* 6年分のApache アクセスログに記載されたURI - 2015年5月

件累計：1216万アクセス


ベンチマーク｜実績値６年間の運用結果*を集計

68* Production.logに記載された処理応答時間 (Redmine～DB) - 2015年5月



69

100ms32%

200ms21%

300ms17%

400ms10%

500ms6%

600ms4%

700ms2%

1000ms超 5%

100ms

200ms

300ms

400ms

500ms

600ms

700ms

・673万回の処理

* Production.logに記載された処理応答時間 (Redmine～DB) - 2015年5月



70

100ms32%

200ms21%

300ms17%

400ms10%

500ms6%

600ms4%

700ms2%

1000ms超 5%

100ms

200ms

300ms

400ms

500ms

600ms

700ms

・673万回の処理・半分が200ms以下・95% が1秒以下




71

100ms32%

200ms21%

300ms17%

400ms10%

500ms6%

600ms4%

700ms2%

1000ms超 5%

100ms

200ms

300ms

400ms

500ms

600ms

700ms

統計要約最小値 : 1第１四分位点 : 67中央値 : 185平均値 : 415第３四分位点 : 339最大値 :3314811

・673万回の処理・半分が200ms以下・95% が1秒以下・中央値185ms



ベンチマーク｜評価対象６年間の運用結果*を集計し、主要画面を決定

72* 6年分のApache アクセスログに記載されたITSのURI - 2015年5月



73* 6年分のApache アクセスログに記載されたITSのURI - 2015年5月

35%

20%6%6%

4%4%

3%2%2%

1% 17% チケット表示チケット一覧WikiページプロジェクトTop添付ダウンロード検索（プロジェクト）ログイン画面マイページRedmineTop添付画像サムネイルその他

・1080万アクセス



74

35%

20%6%6%

4%4%

3%2%2%

1% 17% チケット表示チケット一覧WikiページプロジェクトTop添付ダウンロード検索（プロジェクト）ログイン画面マイページRedmineTop添付画像サムネイルその他


・■チケット表示＋■チケット一覧で55%

・利用頻度、遅延を体感しやすい画面

* 6年分のApache アクセスログに記載されたITSのURI - 2015年5月



75

35%

20%6%

2%チケット表示チケット一覧WikiページプロジェクトTop添付ダウンロード検索（プロジェクト）ログイン画面マイページRedmineTop添付画像サムネイルその他

* 6年分のApache アクセスログに記載されたITSのURI - 2015年5月


・■チケット表示＋■チケット一覧で55%

・利用頻度、遅延を体感しやすい画面

・ベンチマーク対象が全体の63%を網羅


ベンチマーク｜テストデータ*

76

規模

* 実データ10万チケットを複写して製作



77

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関係性

規模


万



78

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関係性

規模


万 200万チケットは3000万レコード

カスタムフィールドは77種に固定



79

200万チケットの内訳種類最大想定チケット数 200万

カスタムField値 1200万

添付ファイル 140万

時間記録 74万

注記欄 363万

Watcher 76万

Ticket関係 27万



ベンチマーク｜計測方法

80

Ruby Out Of Band Garbage Collection*

Passenger Redmine

Ruby 2.0 2016/2/24 EOL － 4 / 5 2.6 / 3.0 / 3.1 / 3.2Ruby 2.1 2017/3/xx EOL Normal / OOBGC 4 / 5 2.6 / 3.0 / 3.1 / 3.2Ruby 2.2 Normal / OOBGC 4 / 5 2.6 / 3.0 / 3.1 / 3.2

Passenger5

OS CentOS7 （64bit）Ruby 2.2

Rails4.2

Redmine 3.2 DBMS

MySQL 5.6（BP 8GB）

HTTP

Apache 2.4

メモリ 16GBCPU 4コア

VMware ESXi 6【CPU】Intel Xeon E5-2650 2.3GHz 10Cores/20Threads, 【Memory】64GB, 【SSD】480GB SATA, 【HDD】6TB 10K RPM SAS RAID6

VCS

Subversion1.8

組み合わせ要素

環境構成

* OOBGC; Out Of Band Garbage Collection Request処理中にRubyがGCを実行すると処理遅延が生じるので、指定処理回数毎に１度、Requestの間隙にGCを実行させる機能。

SSD/HDD NIC

https://www.ruby-lang.org/ja/news/2016/02/24/support-plan-of-ruby-2-0-0-and-2-1/

https://www.ruby-lang.org/ja/news/2016/02/24/support-plan-of-ruby-2-0-0-and-2-1/


ベンチマーク｜計測方法

81

① 主要画面７種に対して（2並列で10回アクセス）を×5回実行した平均応答時間を計測

② 上記①を、DBキャッシュ状態３種を順次切替えて実行する。(a)DBキャッシュ無し、(b)DBキャッシュ保存･復元、(c)Fullメモリキャッシュ

③ 上記②の(c)Fullメモリキャッシュを採用する。④ 上記①～③を10万～200万チケットまで繰り返す。

10万 20万 30万 50万 70万 100万 150万 200万所要時間合計（ミリ秒） 915 848 970 991 1048 1062 1029 1041

Redmine3.2 主要画面７種のURIBufferPool 8G /its32 13.8 12.8 13.1 13 12.7 13 12.5 13.1Ruby2.2.4 /its32/projects 32.5 30.8 32.3 30.6 30.1 31.2 30.6 30.5OOBGC /its32/projects/sscope 92.8 87 87.3 88.1 86.2 86.9 87.4 87.2

/its32/issues?per_page=200 433.9 392.9 395.6 404.5 465.2 458.7 401.9 401.5

/its32/issues/1 91.3 70.3 182.6 184.7 176.7 179.2 180.7 180

/its32/issues/47548 164.5 165.4 170 179.7 191.2 205.9 227.6 239.6/its32/issues/51782 82.7 89.2 88.7 90.8 86.2 87.4 88.3 89


ベンチマーク｜計測結果１

82

Redmine3.2の最速ベンチ



83


0 2000 4000 6000 8000 10000 12000

Ruby2.0_nml

Ruby2.1_nml

Ruby2.1_oobgc

Ruby2.2_nml

Ruby2.2_oobgc

10万 20万 30万 50万 70万 100万 150万 200万 ms



84


0 2000 4000 6000 8000 10000 12000

Ruby2.0_nml

Ruby2.1_nml

Ruby2.1_oobgc

Ruby2.2_nml

Ruby2.2_oobgc

10万 20万 30万 50万 70万 100万 150万 200万 ms



85


0 2000 4000 6000 8000 10000 12000

Ruby2.0_nml

Ruby2.1_nml

Ruby2.1_oobgc

Ruby2.2_nml

Ruby2.2_oobgc

10万 20万 30万 50万 70万 100万 150万 200万最も遅い Ruby2.0 に比して、最も速い Ruby2.2 + OOBGCは 31.2% 速い ms


ベンチマーク｜計測結果２

86

Redmine3.2は速いのか


0

2000

4000

6000

8000

10000

12000

Redmine2.6 Redmine3.0 Redmine3.1 Redmine3.2

10万 20万 30万 50万 70万 100万 150万 200万


87

Redmine3.2は速いのかms


0

2000

4000

6000

8000

10000

12000


10万 20万 30万 50万 70万 100万 150万 200万


88


・性能向上（平均）2.6 → 3.0 8.9%

2.6 → 3.1 7.4%

2.6 → 3.2 6.7%

・原因推測＋ Multi Thread対応＋ Rails4.2の内部改善－機能増加


0

2000

4000

6000

8000

10000

12000


10万 20万 30万 50万 70万 100万 150万 200万


89


・性能向上（平均）2.6 → 3.0 8.9%

2.6 → 3.1 7.4%

2.6 → 3.2 6.7%

・原因推測＋ Multi Thread対応＋ Rails4.2の内部改善－機能増加Redmine2.6から3.2へアップデートすると、

平均6.7％の性能向上が得られる


ベンチマーク｜計測結果３

90

Rubyバージョン変更の効果


0

2000

4000

6000

8000

10000

12000

14000

rb20_nml rb21_nml rb22_nml rb21_oobgc rb22_oobgc

10万 20万 30万 50万 70万 100万 150万 200万

0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万


91

Rubyバージョン変更の効果ms ms

Redmine3.2 Redmine2.6


0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万

0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万


92


Redmine3.2 性能向上(平均)Ruby2.0→2.2 31.2%

Ruby2.0→2.2OOBGC 38.3%

Redmine2.6



Redmine3.2


0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万

0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万


93




Redmine2.6



Redmine3.2

Redmine3.2において、Ruby2.0から2.2+OOBGCへUpdateすると平均38.3％の性能向上が得られる


0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万

0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万


94

OOBGCの効果ms ms

Redmine2.6Redmine3.2


0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万

0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万


95

OOBGCの効果ms ms

Redmine3.2 性能向上(平均)OOBGC効果Ruby2.2→2.2OOBGC 10.2%




0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万

0

2000

4000

6000

8000

10000

12000

14000


10万 20万 30万 50万 70万 100万 150万 200万


96

OOBGCの効果ms ms




Redmine3.2において、Ruby2.2にOOBGCを適用すると平均10.2％の性能向上が得られる


ベンチマーク｜計測結果４

97

過去のRedmineと比較

Redmine自体は速くなった？遅くなった？


0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

Redmine2.3 最速

Redmine2.6 最速

Redmine3.0 最速

Redmine3.1 最速

Redmine3.2 最速

10万 20万 30万 50万 70万 100万 150万 200万


98

過去のRedmineと比較ms


0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

Redmine2.3 最速

Redmine2.6 最速

Redmine3.0 最速

Redmine3.1 最速

Redmine3.2 最速

10万 20万 30万 50万 70万 100万 150万 200万


99


最速ベンチマークを比較すると、

2.3 → 2.6 －32%

2.3 → 3.2 －27%

性能が低下している。


0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

Redmine2.3 最速

Redmine2.6 最速

Redmine3.0 最速

Redmine3.1 最速

Redmine3.2 最速

10万 20万 30万 50万 70万 100万 150万 200万


100


性能変化の原因推測＋ Redmine内部改善＋ Multi Thread対応＋ Rails4.2の内部改善＋ Ruby高速化＋ OOBGC－機能増加

※ Redmine2.3の計測は2013年当時の計算機とRuby2.0によるもの。現在は電算機の能力が向上しており比較精度は完全でない。性能低下はより大きいと予想。


0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

Redmine2.3 最速

Redmine2.6 最速

Redmine3.0 最速

Redmine3.1 最速

Redmine3.2 最速

10万 20万 30万 50万 70万 100万 150万 200万


101


機能増加Redmine

2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 3.2 Spent time

2013-03 ～ 2015-12Includes

192 Features294 Patches406 Defects repaired

Still so fast and reliable!


0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

Redmine2.3 最速

Redmine2.6 最速

Redmine3.0 最速

Redmine3.1 最速

Redmine3.2 最速

10万 20万 30万 50万 70万 100万 150万 200万


102


機能増加Redmine

2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 3.2 Spent time

2013-03 ～ 2015-12Includes

192 Features294 Patches406 Defects repaired

Still so fast and reliable!

・Redmine2.3を3.2へUpdateすると27%の性能低下となる

・多数の有益な機能追加により性能は低下したが、技術進歩により影響は低く抑えられた



103

他のボトルネックを解消するしかない…



104

他のボトルネックを解消するしかない…

そこで「永続化」HDDをSSDへ置換

（廉価になったので）


0

2000

4000

6000

8000

10000

12000

Redmine2.3 HDD Redmine2.6 HDD Redmine3.2 HDD Redmine3.2 SSD

10万 20万 30万 50万 70万 100万 150万 200万

ベンチマーク｜計測結果５

105

HDDをSSDに置換する効果ms


0

2000

4000

6000

8000

10000

12000


10万 20万 30万 50万 70万 100万 150万 200万


106


Redmine3.2HDD → SSD平均10.9%の性能向上性能低下を挽回


0

2000

4000

6000

8000

10000

12000


10万 20万 30万 50万 70万 100万 150万 200万


107



【参考】2015年5月の調査平均25.7%の性能向上

（今回の調査でSSDの性能を生かし切れていない可能性）


0

2000

4000

6000

8000

10000

12000


10万 20万 30万 50万 70万 100万 150万 200万


108



【参考】2015年5月の調査平均25.7%の性能向上

（今回の調査でSSDの性能を生かし切れていない可能性）

HDDをSSDに交換すると、環境によって平均10.9％～25.7％の性能向上が得られる


ベンチマーク｜計測結果６

109

複数プラグイン導入の性能への影響

Redmineの性能に、プラグインがどの程度の影響を与えるのか？



110

複数プラグイン導入の性能への影響Redmine Pluginの多くはHookによって各処理に割り込みをかけている。性能が十分に考慮されていないコードが呼び出された場合、応答性能に影響する。

選出した16種のうち8種はRedmine3.0に未対応だった。

プラグインを追加して応答時間を計測した結果、平均4%の性能低下が計測された。

0

2000

4000

6000

8000

10000

12000

Redmine3.0 Redmine3.0 - WithPlugins

10万 20万 30万 50万 70万 100万 150万 200万

ms



111

複数プラグイン導入の性能への影響

0

2000

4000

6000

8000

10000

12000

Redmine3.0 Redmine3.0 - WithPlugins

10万 20万 30万 50万 70万 100万 150万 200万

ms

Redmine Pluginの多くはHookによって各処理に割り込みをかけている。性能が十分に考慮されていないコードが呼び出された場合、応答性能に影響する。

選出した16種のうち8種はRedmine3.0に未対応だった。

プラグインを追加して応答時間を計測した結果、平均4%の性能低下が計測された。不要なPluginを除去することで、

応答性能が平均4%向上するケースがある


0

200

400

600

800

1000

1200

1400

No Cash BP Save &Load

Full Cash(Almost onmemory)

10万 20万 30万 50万 70万 100万 150万 200万

ベンチマーク｜計測結果７

112

FTS* 応答性能の計測

* FTS; Full Text Search全文検索（索引型／非索引型）

秒


0

200

400

600

800

1000

1200

1400



10万 20万 30万 50万 70万 100万 150万 200万


113

FTS* 応答性能の計測秒・Redmine3.0の全文検索は、

全走査（非索引型）の検索処理・No BP* Cash

10万チケット 24秒100万チケット 207秒（3分27秒）200万チケット 6204秒（103分24秒）

・BP* Save & Load10万チケット 17秒100万チケット 162秒（2分42秒）200万チケット 3601秒（60分1秒）

* BP; データベースのBuffer Pool メモリ一度読込んだらメモリ上に貯蔵してDisk I/Oを削減

* FTS; Full Text Search全文検索（索引型／非索引型）


0

200

400

600

800

1000

1200

1400



10万 20万 30万 50万 70万 100万 150万 200万


114

FTS* 応答性能の計測秒１）SSDにしても効果があまり無かった

２）対策走査対象の全データをメモリ上に乗せる

３）Redmineのチューニング限界点「FTS Click Attack によるDDoS」には耐えられない。過去に数回発生。（200人のブラウザが真っ白でWaiting。F5攻撃が始まる）

４）希望の光JPLがPoC* を終えているという超高速の索引型FTS。皆さんはどのような技法だと思いますか？

* PoC; Proof of Concept. 概念実証* FTS; Full Text Search全文検索（索引型／非索引型）


ベンチマーク｜計測結果８

115

Redmine3.2は200万チケットでも“サクサク”なのか？


0

200

400

600

800

1000

1200

10万 20万 30万 50万 70万 100万 150万 200万

チケット表示（小）チケット表示（大）チケット表示（中）チケット一覧プロジェクトTopプロジェクト一覧Redmine Top


116


ms


0

200

400

600

800

1000

1200

10万 20万 30万 50万 70万 100万 150万 200万



117


ms

チューニングの結果、Redmine3.2の主要画面７種の平均応答時間は141ms


0

200

400

600

800

1000

1200

10万 20万 30万 50万 70万 100万 150万 200万



118


ms 全文検索 20秒対策必須

DB始動時の暖機運転5分MySQL5.6, Postgres9.4に対策有り(BufferPool dump/Restore)

BufferPool8GB以上必須


0

100

200

300

400

500

600

700

800

900

10万 20万 30万 50万 70万 100万 150万 200万

チケット表示（小）チケット表示（大）チケット表示（中）チケット一覧プロジェクトTopプロジェクト一覧RedmineTop


119


ms 全文検索 20秒対策必須 DB始動時の暖機運転5分

MySQL5.6, Postgres9.4に対策有り(BufferPool dump/Restore)

BufferPool8GB以上必須

200万件まで大丈夫全文検索の対策が必要*

200万件まで大丈夫全文検索の対策が必要*

* Redmineに限った話ではなく、非索引型FTSのアプリケーションはみな同じ対策が必要


目次

120


120


目次

121


121


性能改善事例集

122

1. 6年間に渡るRedmineの運用において、どのような問題が発生し、どうやって解消したのか

2. 信頼性と安定性を維持する取組みの「実際と限界」に焦点

3. 各種設定、チューニング方法、性能計測方法を全て紹介する


計測 - 定量化手法｢測定できないものは制御できない｣*

123* DeMarco, Tom., 1982, “You can’t control what you can't measure.”


計測 - 定量化手法｢測定できないものは制御できない｣*

１．テスト実行時間（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版は× : ブルースクリーン死亡）

124* DeMarco, Tom., 1982, “You can’t control what you can't measure.”

http://www.hpl.hp.com/research/linux/httperf/

https://github.com/wg/wrk

http://httpd.apache.org/docs/2.2/programs/ab.html

https://www-jp.mysql.com/products/workbench/

https://developer.chrome.com/devtools

https://iperf.fr/


事例１）【性能】全体がひどく遅い

125

【チューニング要素】・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer・N/W: 通信帯域, Switching-Hub



126


１）Memory搭載・設定DBMSに十分なキャッシュメモリを付与

２）Disk I/O HDD→ SSDOS, DBMS, APL（Redmine他）はSSDに格納し、他のデータはHDDへ

３）CPUコア数と同時並行処理数処理要求が集中した時の待ち行列（例：昼時の有名ラーメン店の行列）CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える。

- Passenger：自動調整（指定可能）- Unicorn , Thin：起動サーバー数を増減



127


４）OS選択Windows Bitnamiは５万件まで（制約：Ruby2.0系, DBMS 32bit）最新のBitnami 2.6, 3.2系はRuby2.1に。未調査だが期待。（制約：DBMS 32bit）10万件扱うなら、Windows スクラッチ構築15万件以上扱うなら200万件まで確認したLinux 64bitを推奨

５）DBMS選択MySQL, Postgresql を使用して、必ず設定値を変更。Sqliteは数千チケットまで

６）通信データ圧縮Apache等 HTTP/1.1 Compressionネットワーク帯域が狭い時、通信輻輳時に高い効果



128


７）Rubyバージョン利用可能な最新版を使用 1.9 < 2.0 < < < 2.1 < 2.2

８）Webアプリケーションサーバー選択WEBrick < < < Thin < < Passenger4 ≒ Passenger5 （Unicornは未調査。速いがPassengerに比して扱い難い。上級者向け）

９）通信経路の狭帯域対策10M/bps → 1G/bps (ケーブル＋Switch機器を交換)Local Loopback は最速のNIC

１０）通信装置の性能向上Normal-HubをSwitchへ交換しコリジョンによる通信効率低下を回避


事例２）【性能】リポジトリタブが遅い

129

【チューニング要素】・H/W: HDD, Memory, CPU ・S/W: DBMS, Ruby, WebAppServer, Subversion Server・N/W: 通信帯域, Switching-Hub

１）Subversionリポジトリの同期トリガを変更SubversionとRedmine間のリポジトリ同期は、画面上のリポジトリタブをクリックすると実施されるのが既定の動作。リビジョン数が増えてくると表示されるまでに１分以上待たされる。Redmine全体管理画面の「コミットを自動取得する」をOFFにして、Subversionリポジトリ側のPost-Commit-Hookに同期スクリプトを組み込むことで、同期トリガが“コミット時”へ変更され、画面上のリポジトリタブは直ちに表示されるようになる。

２）Subversionリポジトリの同期対象を指定する前述のPost-Commit-Hookは全プロジェクトを対象にするため、リポジトリ数が多い場合5分以上かかる場合がある。ほぼ同時に5人が5回ずつコミットすると同期が25並列で実行されてしまい、処理輻輳によりRedmineが応答しなくなる。特定のProjectのみ同期を実施するよう、スクリプトに追記する。


事例２）【性能】リポジトリタブが遅い

130

【チューニング要素】・H/W: HDD, Memory, CPU ・S/W: DBMS, Ruby, WebAppServer, Subversion Server・N/W: 通信帯域, Switching-Hub

３）Subversionセッションキャッシュセッション毎にキャッシュメモリを付与（Subversion 1.7 以上）

４）Subversion通信圧縮機能通信内容の圧縮レベル指定（Subversion 1.7 以上）

５）同一サーバーに置き、通信帯域を広くするLocal loopback, TCP/UDP/Socket通信は高速

６）MySQL テーブル更新が遅いDBMSメモリ設定SSD採用


事例３）【性能】検索が遅い

131

１）MySQLメモリチューニング・メモリをできるだけ積み込む・全インデックス、全データをオンメモリにする

２）カスタムフィールドの設定「検索対象」の数が多いと極端に性能が落ちる

【チューニング要素】・H/W: Memory, CPU ・S/W: DBMS, Redmine


事例４）【性能】画面応答が遅い

132

１）Rubyのバージョン処理性能1.8 < 1.9 << 2.0 <<< 2.1 << 2.2

２）MySQLメモリチューニング全インデックスと主要データをメモリに乗せる

３）初回アクセスが極端に遅いMySQL 5.6 – Bufferpool save and loadPostgreSQL 9.4 - pg_prewarm

４）CPUコア数と同時並行処理数処理要求が集中した時の待ち行列（例：昼時の有名ラーメン店の行列）CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える

- Passenger：自動調整（指定も可能）- Thin：起動サーバー数を増減



事例４）【性能】画面応答が遅い

133

５）メール非同期送信（Async）通知先が多い／メールサーバー（MTA）が遅い

６）Plugin導入数導入数が多いと遅くなる。大量データの応答性能まで考慮されているPluginはそう多くない。

７）通信データの圧縮HTTP1.1/Compression （最大10倍速）



事例５）【性能】特定プラグインが遅い

134

【チューニング要素】・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

・アプリコード調査手順（今回は実施せず）・データ設計調査手順（今回は実施せず）

https://bitbucket.org/tkusukawa/redmine_work_time/pull-request/17

http://www.slideshare.net/techblogyahoo/mysql-58540246


事例６）【信頼性】不安定で手間がかかる

135

１）3歩遅れの「枯れた技術」末尾が3になったら導入例）Redmine 3.0.3

２）Windows <<< Linux OS両方面倒を見てきたが、Ruby, Rails はWindowsで制限が多い（印象）

３）RedmineUpdateの工夫新旧の環境を並立させて動作を確認し、準備が整ったら切り替える

４）OSS パッチの取込み（Redmineに限って言えば）性能が改善され、問題は解消している。Gitの追跡ブランチモードで git cloneしてLocal変更との共存を確保しつつ、git pull だけでパッチを取りこめる。

例）mkdir /var/lib/its/rm32_itscd /var/lib/its/rm32_itsgit clone https://github.com/redmine/redmine.git .git checkout -b 3.2-stable-local origin/3.2-stable




136

５）Exception発生をMail 通知し、不具合を確実に検出Redmine本体のExceptionは6年間でもほんの僅か

６）Redmine本体やRailsに手を入れないRedmine本体の品質は極めて高いテストコードのカバレッジ率がとても高いhttp://www.redmine.org/builds/coverage/

７）Pluginは魅力的だが、あまり採用していないRedmine本体のUpdateの足枷になるテストコードが無く、DBテーブル構造を壊す例もある

【参考】MTBF 7,000時間、MTTR 17時間、稼働率 99.8%


http://www.redmine.org/builds/coverage/



137

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


Dump and Restore


Munin: Average latencyMunin: Average latency

事例７）【性能】電算機のH/W資源不足

138

１）1VMに集約し、狭帯域通信を回避２）CPU キャッシュの大きなものを複数コア用意

同時接続の処理数に合わせる３）メモリできるだけ積み込む４）SSD導入： SSD（OS, DBMS, Redmine）、HDD（その他データ）

↓ SSD切替点↓ SSD切替点

【HDD】突出ピークが無くなった。【SSD】ピークが無くなりI/O waitが小さくなった。振れ幅が小さく、余力が見てとれる。


事例８）【性能】電算機通信網の帯域不足

139

＜Network＞

１）主要通信経路は1G/bpsに統一10M/bps, 100M/bps のボトルネックを排除

２）Normal Hub → Switching Hubコリジョン発生率の低減

３）Local Loopback通信サーバー統合による通信の高速化


事例９）【性能】起動が遅い

140

＜DBMSの起動・再起動直後、初回アクセスだけが極端に遅い＞

１）DBMSサーバーの起動、再起動時は「暖機運転」が必要「暖機運転」とは、DBMS再起動後にデータやインデックスをメモリ上へ読み込む一連の処理。対象となるデータが増えると、長時間かかるようになる

MySQL5.6系warm up 、Postgresql 9.4系pg_prewarmとして実装されたBufferPool、Workloadの保存・読込機能によって待ち時間が大幅に短縮される

MySQLinnodb_buffer_pool_dump_at_shutdown = ONinnodb_buffer_pool_load_at_startup = ON


設定例１）基本S/W

141

OS, File-System

１）OS CentOS 6 / 7プロセス、パッケージは必要最低限に削ぎ落とす。（パッチ適用、最少の停止頻度、セキュリティー、メモリ）

２）File-SystemExt4 nobarrier チューン http://goo.gl/LYwfA0

３）Kernel設定・[SSD] Disk I/O スケジューラーを cfq から deadline へ変更・[SSD] SWAP抑制 vm.swappiness=1※ 性能への影響は未確認

http://goo.gl/LYwfA0


設定例２）ミドルウェア

142

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分早く終わる）


設定例２）ミドルウェア

143

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)で安定稼働（実績３ヶ月）

７）Passenger EnterpriseMulti Threadモードで○○％向上 (未調査) 利用料金は 5000円／月程度


設定例３）応用S/W

144

Ruby, OOBGC, Redmine, Subversion＜Ruby＞

・GCの大幅改善によりRuby2.2が最速のバージョン・ベンチ最速は Ruby2.2＋OOBGC（調査時点 2016/03 ）

＜OOBGC for Ruby2.1, 2.2＞・Unicorn

GitHubのAman gupta-san(@tmm1)が作ったgctools original.https://github.com/tmm1/gctools

・Passenger4/5Ruby2.1は、Shirosaki-san(@shirosaki)のFork版

https://github.com/shirosaki/gctoolsRuby2.1/2.2は、@akahane92 のFork版

https://github.com/akahane92/gctoolsThis 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.2（OOBGC無）が総合的に見て最適選択。OOBGC有は「10.2%」の性能向上を必要とする方向け（ちょいムズ）

https://github.com/tmm1/gctools

https://github.com/shirosaki/gctools

https://github.com/akahane92/gctools

https://github.com/tmm1/gctools/pull/14



145

Ruby, OOBGC, Redmine, Subversion＜Redmine＞

・カスタムフィールドの設定値「検索条件」の数を減らす。例「14万チケットだと30種 ○○秒 → 5種〇秒」

（未計測だが効果は絶大）・メール非同期送信(Async)

config/configuration.ymlproduction:email_delivery:delivery_method: :async_smtpasync_smtp_settings:



146

Ruby, OOBGC, Redmine, Subversion＜VCS＞

・Subversion Server 1.7以降のセッションキャッシュ付与機能セッションキャッシュにより、通信応答速度が向上する。

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


目次

147


147


目次

148


148


お話ししたこと

149

１）200万チケットでもサクサク動くRedmineの全レシピ２）Redmine 2.6 を 3.2 へUpdateすると平均で6.7％速くなる３）Redmine3.2で、Ruby2.0 を 2.2 へUpdateすると平均で31.2％速くなり、OOBGCを使用すると平均で38.3％速くなる


お話ししたこと

150

１）200万チケットでもサクサク動くRedmineの全レシピ２）Redmine 2.6 を 3.2 へUpdateすると平均で6.7％速くなる３）Redmine3.2で、Ruby2.0 を 2.2 へUpdateすると平均で31.2％速くなり、OOBGCを使用すると平均で38.3％速くなる４）HDDをSSDに変更すると平均で10.9%〜25.7％速くなる５）Redmineチューニング事例 9種６）全走査型の全文検索は10万チケットで性能限界に到達する


まとめ｜実際

151

・初期値のままでは、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


まとめ｜限界

152

1. Redmineの機能強化CPU, SSD, Ruby, Railsによる性能向上分を消費した。有効な対策はRedmineの内部に踏み込むしかない。

2. RedmineのFTS (全走査型)（Redmineは悪くないが）10万チケットの時点で検索が非常に遅くなる。CPU４コアで稼働している時に、全プロジェクトの横断検索が４回クリックされるとCPUの処理が占有されてRedmineが無応答になってしまう。歯止めをかける方法が今のところ無い。今後、抜本対策（索引型のFTS）が無い場合はRedmineを使い続ける事が難しくなってしまう。

3. JPLが Proof of Conceptを終えているという爆速の索引型FTS（数ms）が頼みの綱。 http://www.redmine.org/issues/15781#note-6【推測】Postgresql 9.3のMaterialized View を使用してlib/plugins/acts_as_searchable を数十行書きかえることで索引検索が可能となる。（未検証）

http://www.redmine.org/issues/15781#note-6


目次

153


153


目次

154


154


付録｜性能関連設定の一覧

155

本稿で扱った性能ベンチ－マークは下記設定による。

1. 計測プログラム2. Apache2.2, 2.4 HTTP/1.1 通信圧縮3. Passenger4. MySQL 5.6 Linux, Bitnami5. Subversion キャッシュ設定, 通信圧縮6. Redmine Subversion同期 ProjectID指定7. Redmine OOBGC for Unicorn and Passenger8. OS File System

設定値の一括ダウンロードはこちら (GitHub Gist)Download: Setting_paramaters_for_Redmine_Performance_Tuning.txthttps://gist.github.com/akahane92/771f9a52d81af9864dd8

https://gist.github.com/akahane92/771f9a52d81af9864dd8


付録｜計測方法

156

計測プログラム# bench.rb# -*- coding: utf-8 -*-

url_list = ["/its32 ","/its32/projects ","/its32/projects/sscope ","/its32/issues?per_page=200 ","/its32/issues/1 ","/its32/issues/47548 ","/its32/issues/51782 "

]

puts "--- Environment ---"puts `httpd -version`puts `ruby -v`puts `gem list --local passenger`puts èxport RAILS_ENV=production; /var/lib/its/rm32_its/bin/about`puts èxport RAILS_ENV=production; /var/lib/its/rm32_its/bin/bundle list`

ti = 5 result = []url_list.each { |url|rate_avg = ms_avg = 0puts "--- #{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

157

Apache2.4 /etc/httpd/conf.d/defelate.conf

<IfModule mod_deflate.c>SetOutputFilter DEFLATEDeflateCompressionLevel 1DeflateMemLevel 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 fineBrowserMatch ¥bMSIE¥s(7|8) !no-gzip !gzip-only-text/html

FilterDeclare Compression CONTENT_SETFilterProvider 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 filesSetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|t?gz|zip|bz2|sit|rar|lzh|exe)$ dont-vary

# Make sure proxies don't deliver the wrong contentHeader 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 problemsBrowserMatch ^Mozilla/4.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fineBrowserMatch bMSIE !no-gzip !gzip-only-text/html

FilterDeclare Compression CONTENT_SETFilterProvider Compression DEFLATE resp=Content-Type $text/htmlFilterProvider Compression DEFLATE resp=Content-Type $text/xmlFilterProvider Compression DEFLATE resp=Content-Type $text/cssFilterProvider Compression DEFLATE resp=Content-Type $text/plainFilterProvider Compression DEFLATE resp=Content-Type $image/svg+xmlFilterProvider Compression DEFLATE resp=Content-Type $application/xhtml+xmlFilterProvider Compression DEFLATE resp=Content-Type $application/xmlFilterProvider Compression DEFLATE resp=Content-Type $application/rdf+xmlFilterProvider Compression DEFLATE resp=Content-Type $application/rss+xmlFilterProvider Compression DEFLATE resp=Content-Type $application/atom+xmlFilterProvider Compression DEFLATE resp=Content-Type $text/javascriptFilterProvider Compression DEFLATE resp=Content-Type $application/javascriptFilterProvider Compression DEFLATE resp=Content-Type $application/x-javascriptFilterProvider Compression DEFLATE resp=Content-Type $application/x-font-ttfFilterProvider Compression DEFLATE resp=Content-Type $application/x-font-otfFilterProvider Compression DEFLATE resp=Content-Type $font/truetypeFilterProvider Compression DEFLATE resp=Content-Type $font/opentypeFilterChain Compression

# Don't append Vary heder for specific filesSetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|t?gz|zip|bz2|sit|rar|lzh|exe)$ dont-vary

# Make sure proxies don't deliver the wrong contentHeader append Vary User-Agent env=!dont-varyHeader append Vary Accept-Encoding env=!dont-vary</Location>

</IfModule>

1. HTTP/1.1 通信圧縮


付録｜Passenger

158

Apache2 /etc/httpd/conf.d/passenger.conf# Rails environment settings# RailsEnv production

# Multiple Redmine Envirnoment with Sub-URI RailsBaseURI /itsRailsBaseURI /its_import

# 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 20PassengerMaxInstancesPerApp 4PassengerPoolIdleTime 3600PassengerHighPerformance onPassengerStatThrottleRate 10RailsSpawnMethod smartRailsAppSpawnerIdleTime 86400PassengerMaxPreloaderIdleTime 0# For OOBGC < Experimental ># PassengerSpawnMethod direct


付録｜MySQL 5.6

159

＜続き＞

default_storage_engine = InnoDBexplicit_defaults_for_timestamp = 1

# For SSDinnodb_flush_neighbors = 0

# MySQL Server System Variables# http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.htmlsql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLESjoin_buffer_size = 128Msort_buffer_size = 1Mquery_cache_type = 1query_cache_size = 128Mquery_cache_limit = 6Mtmp_table_size = 512Mmax_heap_table_size = 1G

read_rnd_buffer_size = 16Mkey_buffer_size = 32Mmax_allowed_packet = 16Mread_buffer_size = 1Mbulk_insert_buffer_size = 64M

max_connections = 100character-set-server = utf8skip-external-lockingthread_cache_size = max_connections/3table_open_cache = 4096table_open_cache_instances = 64performance_schema = OFF

open_files_limit = 65500max_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.htmlinnodb_buffer_pool_dump_at_shutdown = ONinnodb_buffer_pool_load_at_startup = ON

innodb_buffer_pool_size = 8Ginnodb_log_file_size = 4Ginnodb_log_buffer_size = 8Minnodb_flush_log_at_trx_commit = 1innodb_log_files_in_group = 2

innodb_thread_concurrency = 16innodb_concurrency_tickets = 5000innodb_old_blocks_time = 1000innodb_open_files = 300innodb_stats_on_metadata = 0innodb_checksum_algorithm = crc32innodb_file_format = Barracudainnodb_max_dirty_pages_pct = 90innodb_lock_wait_timeout = 120innodb_print_all_deadlocks = ONinnodb_data_file_path = ibdata1:10M:autoextendinnodb_autoextend_increment = 64innodb_flush_method = O_DIRECTinnodb_read_io_threads = 8innodb_write_io_threads = 8innodb_buffer_pool_instances = 8innodb_rollback_segments = 32innodb_use_sys_malloc = 1


付録｜MySQL 5.6 for Bitnami

160

MySQL 5.6 my.cnf for Bitnami

# The MySQL server[mysqld]# set basedir to your installation pathbasedir=C:/Bitnami/REDMIN~1.0-2/mysql# set datadir to the location of your data directorydatadir=C:/Bitnami/REDMIN~1.0-2/mysql/dataport=3306character-set-server=UTF8collation-server=utf8_general_cimax_allowed_packet=16Mbind-address=127.0.0.1# The default storage engine that will be used when create new tables whendefault-storage-engine=INNODB#================================================================# InnoDB Paramaters# http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.htmlinnodb_buffer_pool_size = 2Ginnodb_log_file_size = 512Minnodb_thread_concurrency = 8innodb_additional_mem_pool_size = 16Minnodb_buffer_pool_dump_at_shutdown = ONinnodb_buffer_pool_load_at_startup = ON

# MySQL Server System Variables# http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.htmljoin_buffer_size = 128Msort_buffer_size = 1Mquery_cache_type = 1query_cache_size = 64Mquery_cache_limit = 2Mtmp_table_size = 64Mmax_heap_table_size = 64M#================================================================


付録｜Subversion キャッシュ＆通信圧縮

161

Apache2.2, 2.4 /etc/httpd/conf.d/subversion.conf

<IfModule dav_svn_module>SVNCompressionLevel 1SVNInMemoryCacheSize 128000SVNCacheFullTexts onSVNCacheTextDeltas on

</IfModule>


付録｜ Redmine Subversion同期

162

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 ITSREPOSHOME=`/usr/bin/dirname $REPOSÀPIKEY=`/bin/cat $REPOSHOME/common/APIKEY`PJNAME=`/bin/basename $REPOSÙRL="http://localhost/its/sys/fetch_changesets?id=$PJNAME&key=$APIKEY"/usr/bin/wget -q --no-proxy $URL -O /dev/null


付録｜ Redmine OOBGC for Unicorn

163

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+

http://tmm1.net/ruby21-oobgc/

http://qiita.com/jemiam/items/5c6e4595f3565f3c5562

http://k0kubun.hatenablog.com/entry/2016/01/23/231213



付録｜ Redmine OOBGC for Passenger

164

Passengerへの gctools導入

■About gctoolsAman 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/srcgit clone https://github.com/shirosaki/gctools # For Ruby2.1# またはgit clone https://github.com/akahane92/gctools # For Ruby2.1, 2.2

gem build gctools.gemspecgem install gctools-0.2.3.gem

■Passengerとgctools を Gemfile.localに追記gem 'passenger'gem "gctools", '0.2.3'

http://tmm1.net/ruby21-oobgc/

http://old.blog.phusion.nl/2014/01/31/phusion-passenger-now-supports-the-new-ruby-2-1-out-of-band-gc/





165

■config.ru パッチdiff --git config.ru config.ruindex 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



166

Passengerへの gctools導入

■ /etc/httpd/conf.d/passenger.conf にOOBGC用の設定値を指定

# For OOBGC < Experimental >PassengerSpawnMethod direct


付録｜OS File System

167

■/etc/fstab

/dev/mapper/vg_sms01-lv_root / ext4 defaults,nobarrier,noatime,discard 1 1UUID=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.

Technology

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