redmine + mysql 応答性能の調査結果と対策

Shimadzu Business Systems

株式会社島津ビジネスシステムズ　赤羽根州晴MySQL勉強会 in 大阪 #5 2013年11月7日

Copyright (c) Shimadzu Business Systems All Rights Reserved.

Redmine + MySQL 応答性能の調査結果と対策～ 200万チケット、画面応答100ms/req

を想定したチューニング～

・赤羽根州晴（＠akahane92）・島津製作所業務系システム子会社　→ 開発技術者　


話者紹介

　 → 障害対策専任　　→ 内部統制　　　→ 基盤技術標準化 (現在)

��2

参加団体・JaSST関西・RxTstudy ・AFFORDD 関西部会・京都アジャイル勉強会・WARAIテスト勉強会


��3

ありがとう。


��4

１）応答性能低下の回避　　　　　　Redmine ＋ MySQL5.6 　　　　　　200万チケット, 100ms/req !

２）暖機運転の時間短縮　　　　　　MySQL5.6 新機能　　　　　　BufferPool 終了時Dump & 起動時Load !

３）その他の対策　　　　　　Ruby2.0, Passenger4 (OOBW-GC) 　　　　　　通信遅延回避

今日お話しすること

[*1]

[*3]

[*2]


��5

Redmine, MySQL運用者は？

教えてください！

遅いと感じている方は？

性能チューニングのご経験者は？

→ Redmine 60％→ MySQL　90％

→ Redmine 20％

→ 70％


��6

背景紹介　(簡単に)


��7

島津製作所グループ !

　（国内外拠点５７カ所）

背景


��8

背景 - 課題管理モデル２

　課題 3 ～課題・要望

問合せ受付

調査と確認

状況報告

方針決定

対処と確認

結果報告

時間　課題 2 ～トラブル

問合せ受付

調査と確認

状況報告

方針決定

対処と確認

結果報告

時間　課題１～タスク

問合せ受付

調査と確認

状況報告

方針決定

対処と確認

結果報告

時間複数

ユーザー複数ユーザー複数の

!国内外支社・販社担当者

複数ユーザー複数ユーザー複数の

!国内外部門・担当者

N　：　N　：　N

l Global Issue Tracking System


��9

背景 - 運営状況

業務システム１０３種

利用者 7000人

案件36000件

改版 (コミット) 20500回

1783 KLOC

開発運用２００人

／年

／年

／年自動生成コード含む


��10

背景 - 運営状況

BUSINESSMAN BURIED IN PAPERWORK --- IMAGE BY © ROYALTY-FREE/CORBIS


��11

背景 - 全てを統合

統合管理全面導入

SVN

Mail

[*5]

チケットを京大式カードの延長線と考えるんや！（想像）

[*4]


��12

背景 - 課題管理システムの全体像

Project　A

問合せ

要望・課題

障害・バグ

タスク

Project　B

問合せ

要望・課題

障害・バグ

タスク

課題管理システム (ITS)

自動化ツールビルドテストリリース

構成管理ツール •Subversion, CVS •版数管理（差分・結合・分派）

（未着手）

■日常業務に浸透 •トータルで負担減少 •状態の掌握が容易 •コミュニケーション促進 !■トレーサビリティー　　　　　　一意性永続的な　　連鎖性　　　　　　履歴追跡性 !■変化への適応　状況変化を記録し　追従する。後々の　参照が容易になる。


��13

（チケット実物）


��14

一意識別 ↓

関連維持 ↓

追跡可能 ↓

信頼可能

個人の利益を動機とする局所最適型行動規範が、(結果として) 経営に資する知識管理システムとして、全体最適型の均衡を得ていた。

!　IT全般統制　ISO 　ITIL 　FDA (Part 11) 　省庁監査

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

【経営要求】

!　現業務を表現可能なTool 　入力コストに見合うTool 　＜ユーザー体験＞　　いつでも　どこでも　　素早く必ず見つかる　　休みやすい

【現場の要求】!　【管理手法】


詳細（ご参考）

��15

http://www.slideshare.net/kakahane/it-13718690

・IT全般統制・ITS全社適用・Excel脱却・全体最適化・10ルール・主要画面応答　100ms以下

http://www.slideshare.net/kakahane/rx-tstudy6http://www.slideshare.net/kakahane/3-d1-ja-sst13-kansai

[*6]


http://livepage.apple.com/


http://www.slideshare.net/kakahane/rx-tstudy6

http://www.slideshare.net/kakahane/3-d1-ja-sst13-kansai

http://www.rxtstudy.net/


詳細（ご参考）

��16


・IT全般統制・ITS全社適用・Excel脱却・全体最適化・10ルール・主要画面応答　100ms以下

http://www.slideshare.net/kakahane/rx-tstudy6http://www.slideshare.net/kakahane/3-d1-ja-sst13-kansai

ユーザーコミュニティー !

２０１３年１１月３０日 RxTstudy #９

ATND: http://atnd.org/events/45152




http://atnd.org/events/45152


��17

現状


0

70

140

0

50000

100000

全チケット数プロジェクト数ITS現状ｰ計測

20112010 2012

98,000 Tickets 130 Projects 350 Users

��18

20132013年11月7日時点


ITS現状ｰ計測

0

50

100

0

50000

100000

2010 後 2011 前 2011 後 2012 前 2013前 2013後

全チケット数１日平均発行数完了率

��19

Closed 92%

3000 Tickets/Month

20112010 2012 20132013年11月7日時点


1. 応答性能低下の回避

��20


��21


・ITSの業務活用が急拡大 !

・チケット200万件まで確認 !

・問題を洗い出した


��22

基　準


��23


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

参考文献　　#1 Jakob Nielsen (1993). Response Times: The 3 Important Limits 　　　　http://www.useit.com/papers/responsetime.html 　　#2 Miller, R. B. (1968). Response time in man-computer conversational transactions. 　　　　http://theixdlibrary.com/pdf/Miller1968.pdf

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

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

10000ms 集中限界、進捗表示必須[*7]

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

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


��24


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

参考文献　　#1 Jakob Nielsen (1993). Response Times: The 3 Important Limits 　　　　http://www.useit.com/papers/responsetime.html 　　#2 Miller, R. B. (1968). Response time in man-computer conversational transactions. 　　　　http://theixdlibrary.com/pdf/Miller1968.pdf

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

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

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

ITSは「文房具」[*7]




��25


チューニング対象 !

　Rails, Redmineを除く、　電子計算機全域が対象


��26

対　策


��27

1. 応答性能低下の回避　対策３種 !!!!!!!＃対象対策例

① 通　信狭帯域を回避 Ether Net

② 情報量圧　縮 HTML JS

③ 電算処理再処理を回避 CPU FileSystem DBMS


��28

1. 応答性能低下の回避　対策① 狭帯域通信を避ける

Auth

ClientAPL

DB MS

SVN

WebEthernet等低速通信


��29

1. 応答性能低下の回避　対策① 狭帯域通信を避ける

Web

DB MS

Auth

Client

APL

SVN

少数Serverへ集約

狭帯域６→３


��30

1. 応答性能低下の回避　対策② 情報量の圧縮

Web

DB MS

Auth

Client

APL

SVN

Http/1.1 Compress ↓

最大10倍速


��31

1. 応答性能低下の回避　対策③ 再処理回避

Server

Passenge

r

RAID

OS　　　FS　　　NW

Ruby

Rails

Redmine

DBMS

HTTP

Reverse Proxy

Client


Browser !

JavaScript　/　DOM


��32

1. 応答性能低下の回避　対策③ 再処理回避

Server

Passenge

r

RAID


Ruby

Rails

Redmine

DBMS

HTTP

Reverse Proxy

Client


Browser !

JavaScript　/　DOM

㋖㋖㋖㋖

㋖㋖

㋖㋖

㋖

㋖

潤沢なメモリキャッシュ


��33

1. 応答性能低下の回避　サーバー構成：対象領域

Passenger4 !

OOBW GC

RAID5　　 +20GB

OS　　CentOS6 （64bit）

Ruby 2.0.0

Rails3.2

Redmine2.3!

DBMS !

MySQL !

5.6

!HTTP

!Apache

!2.2

メモリ 4～16GBCPU 2～4コア

VMware （運用円滑化）

!VCS !

Subversion !

1.7

!HTTP

Reverse Proxy !

---

：5 Key Point


��34

1. 応答性能低下の回避　サーバー構成：対象領域

Passenger4 !

OOBW GC

RAID5　　 +20GB

OS　　CentOS6 （64bit）

Ruby 2.0.0

Rails3.2

Redmine2.3!

DBMS !

MySQL !

5.6

!HTTP

!Apache

!2.2

メモリ 4～16GBCPU 2～4コア

VMware （運用円滑化）

!VCS !

Subversion !

1.7

!HTTP

Reverse Proxy !

---

：5 Key Pointcv詳説


��35

1. 応答性能低下の回避　MySQL　5.6.14

・初期値のままでは直ぐに１秒/req越　・MyNA発表資料「MySQL5.6パラ　メータ検討会」がとても参考になった。　　http://d.hatena.ne.jp/sh2/20130806 　・DBMS設定のチューニングは難しい。　(制限付きだが) 13項目に絞って計測。

[*8]

http://d.hatena.ne.jp/sh2/20130806


��36

1. 応答性能低下の回避　MySQL　5.6.14注意！　・変更前の my.cnf を確保　　　　・データベースのバックアップ確保　　　　・DBが起動しなくなる場合があります。　　　　　実施は自己責任でお願いします。 !検証時の制限：　・Redmine, DBMS専用仮想サーバー　・4コア　・メモリ 16GB 　・MySQL 5.6.8以上　・同時接続、処理数＝コア数　・クラスタ分散無し


1. 応答性能低下の回避[mysqld] !# InnoDB Paramaters # http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html innodb_buffer_pool_size = 8G innodb_log_file_size = 2G innodb_thread_concurrency = 8 innodb_additional_mem_pool_size = 16M innodb_buffer_pool_dump_at_shutdown = ON innodb_buffer_pool_load_at_startup = ON !# 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

��37

　（参考値）

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



１）innodb_buffer_pool_size = 1G ~ 8G 　　　→サーバー主メモリの40%~70%を設定 !２）innodb_log_file_size = 512M ~ 4G !　　　→上記１）の値の25%（~50%）を設定。　　　　大きくしすぎるとリカバリに時間が　　　　かかる。また、この値を書き換える時　　　　は要注意。

��38

　（参考値）　変化する値は２種に固定


ITSの耐用検証（応答基準）

��39


��40

このまま使い続けて大丈夫なのか？

0

250,000

500,000

750,000

1,000,000

2013 2015 2020 2025 2030

チケット数

10万件の実データを複写し、実際に２００万件まで動作を確認した。



��41

現在最大想定チケット数 6万 200万カスタムField値 63万 1200万添付ファイル 3万 140万時間記録 2万 74万注記欄 14万 363万Watcher 3万 76万

Ticket関係 1万 27万



2012年10月時点のベンチマークと課題

��42



��43

0 ms

300 ms

600 ms

900 ms

1,200 ms

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

Issue CIssue BIssue ATicket ListPJ TopPJ ListITS Top

※計測諸条件→巻末注記１

BP:4G LogFile:1G



��44

0 ms

300 ms

600 ms

900 ms

1,200 ms

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


全文検索 20秒対策必須

DB始動時の暖機運転5分

2012年末リリースの MySQL 5.6に対策有り

(巻末注記2-1) (BufferPool Dump/Restore)

BufferPool 4GBでの結果 → 8GB必須



201３年1０月時点のベンチマークと課題

��45



��46

0 ms

300 ms

600 ms

900 ms

1,200 ms

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



BP:8G LogFile:2G



��47

0 ms

300 ms

600 ms

900 ms

1,200 ms

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



全文検索 20秒対策必須

DB始動時の暖機運転1~3分


２. 暖機運転の時間短縮

��48


【口頭解説】 DBMSサーバーの再起動時の暖機運転が軽減される（Version 5.6） !暖機運転とは、DBMS再起動後にデータやインデックスをメモリ上へ読み込ませる一連の処理。対象となるデータが増えると、長時間かかることもある。　　

��49



201３年1０月時点　BP:8G 　LogFile:２G !

暖機運転に代わる BufferPool Dump&Load の効果

��50




��51

0 ms

1,250 ms

2,500 ms

3,750 ms

5,000 ms

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



起動直後 BP Load：無



��52

0 ms

1,250 ms

2,500 ms

3,750 ms

5,000 ms

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



起動直後 BP Load：有



��53

0 ms

1,250 ms

2,500 ms

3,750 ms

5,000 ms

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



起動直後 BP Load：有

２. 暖機運転の時間短縮 !

200万チケットの時は暖機運転にかなりの時間が必要だった。 !

MySQL5.6のBufferPool Dump&Load機能により、有効なページキャッシュが短時間で回復していると確認できた。



��54

BufferPool Dump&Load機能と、メモリ割当て量の関係


201３年1０月時点　BP:1 ～ 8G 　LogFile:512M～２G !

暖機運転に代わる BP Dump&Load の効果 → BPサイズを変化させる

��55



��56



��57

２. 暖機運転の時間短縮２. 暖機運転の時間短縮 !!

BufferPoolメモリを十分に積み込めば新機能が効果を発揮し、暖機運転の時間が短縮される。 !

しかしBufferPoolメモリが不十分だと効果が薄れると確認。


３．その他対策

��58



!

!

・Ruby　2.0.0／1.9.3 !

・Passenger4 OOBW-GC 　有／無 !

!

・(参考)Redmine バージョン間の比較

��59



!【口頭解説】 !RailsアプリケーションサーバーであるPassenger4は、遅延を軽減するOOBW（Out-of-Band Work）- GC(Garbage Collection)機能を実装実現している。 !Request処理中にRubyがGCすると処理遅延が生じるので「５回に１度だけ、Requestの間隙にGC」させる機能。

��60


��61

0

60

120

180

240

300

ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C

Ruby1.9.3Ruby2.0.0 OOBW-GC




��62

0

60

120

180

240

300


Ruby1.9.3Ruby2.0.0 OOBW-GC


３．その他対策今回の計測環境 200万チケット、主要画面７種 !

結果 Ruby2.0.0 + Passenger4 OOBW-GCは、Ruby1.9.3 + Passenger4に対し、画面６種において平均8.5%の応答速度向上を確認した。



!

!

(参考) 　Redmine バージョン間の比較

��63


��64

0

100

200

300

400

500


Redmine 1.4Redmine 2.0 TunedRedmine 2.1 TunedRedmine 2.3 Tuned


10万チケット Redmine 各バージョンの比較



��65

ITSと連動した全文検索の解決策と、16GBのメモリがあれば200万チケットの運用に於いても日常的に使用する画面・機能において100ms前後の応答性能をRedmine2.3系で期待できる。

まとめ１


��66

MySQL5.6 の改善・Redmine2.0→2.3の機能追加を吸収しつつも性能の劣化が少ない。・十分なメモリを与えれば、暖機運転も妥当な運用レベルに収束すると確認できた。

まとめ２


��67

Ruby2.0, Passenger4 OOBW-GCによる改善 !

・平均8.5％の応答時間向上

まとめ３


��68

■応答時間の計測条件（詳細）!　１）評価サーバー!　　　計算機環境 VM 1台 (CPU Xeon 3GHz x4 Cores, Memory 8GB, Storage iSCSI-1G 150GB) on VMware ESXi!　　　　※ 評価用サーバーを単独使用。よって外部からの影響要素は無視できる。!　２）ソフトウェア構成!　　　Redmine 2.3.3 本体改変無し、Plug-in無し!　　　・CentOS6.4(x64), Apache2, Ruby1.9.3, Passenger4, Rails3.2, MySQL5.6.14 +（設定値 13種）!　　　・CentOS6.4(x64), Apache2, Ruby2.0.0, Passenger4, Rails3.2, MySQL5.6.14 +（設定値 13種）!　３）評価対象　７画面!　　　(1) Redmine Top 画面 (5) Issue A - Light!　　　(2) Project 一覧画面 (6) Issue B - Heavy!　　　(3) Project Top 画面（150Users） (7) Issue C - Regular!　　　(4) Ticket List （200件 / 10000件表示）!　４）評価方法!　　httperf http://www.hpl.hp.com/research/linux/httperf/ (下記コマンドをサーバー上で１０回実行し、平均する)! httperf --hog --server=localhost --port=80 --uri=/its --num-conns 2 --num-calls 25! httperf --hog --server=localhost --port=80 --uri=/its/projects --num-conns 2 --num-calls 25! httperf --hog --server=localhost --port=80 --uri=/its/projects/sscope --num-conns 2 --num-calls 25! httperf --hog --server=localhost --port=80 --uri=/its/issues?per_page=200 --num-conns 2 --num-calls 25! httperf --hog --server=localhost --port=80 --uri=/its/issues/1 --num-conns 2 --num-calls 25! httperf --hog --server=localhost --port=80 --uri=/its/issues/47548 --num-conns 2 --num-calls 25! httperf --hog --server=localhost --port=80 --uri=/its/issues/51782 --num-conns 2 --num-calls 25

巻末注記１

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


��69

参考文献1.Redmine / OpenSource Software / Jean-Philippe Lang 　 http://www.redmine.org/ 2.MySQL 5.6 BufferPool Dump and Load 　http://dev.mysql.com/doc/refman/5.6/en/innodb-performance.html 　14.2.13.2.8. Faster Restart by Preloading the InnoDB Buffer Pool 3.Passenger OOBW-GC http://blog.phusion.nl/2013/01/22/phusion-passenger-4-technology-preview-out-of-band-work/ 4.知的生産の技術 / 岩波新書 / 梅棹忠夫, 1969 5.Redmineによるタスクマネジメント技法 / 翔泳社 / 小川明彦, 阪井誠, 2010 6.過去の発表資料　・情報システム部門のタスク管理とIT全般統制～ Excel管理からの脱却～ (ITS Redmine #RxTstudy #5) 　http://www.slideshare.net/kakahane/it-13718690

　・情報システム部門のタスク管理~ITS応答性能の調査結果と対策編~ 　http://www.slideshare.net/kakahane/rx-tstudy6

　・ソフトウェアの品質向上に資する、開発・運用現場の情報管理 http://www.slideshare.net/kakahane/3-d1-ja-sst13-kansai

7. #1 Jakob Nielsen (1993). Response Times: The 3 Important Limits 　　http://www.useit.com/papers/responsetime.html #2 Miller, R. B. (1968). Response time in man-computer conversational transactions.

　　http://theixdlibrary.com/pdf/Miller1968.pdf 8. MyNA発表資料「MySQL5.6パラメータ検討会」 http://d.hatena.ne.jp/sh2/20130806

http://www.redmine.org

http://dev.mysql.com/doc/refman/5.6/en/innodb-performance.html


http://www.slideshare.net/kakahane/rx-tstudy6




http://d.hatena.ne.jp/sh2/20130806


ご清聴ありがとうございました

!

協　力

島津ビジネスシステムズ

��71


島津製作所のご紹介!

!

　　島津製作所グループ　　事業領域　　　・分析計測　　　・医用機器　　　・航空機器　　　・半導体機器　　　・油圧, 光学

��72

redmine + mysql 応答性能の調査結果と対策

Technology