情報システム部門の タスク管理

～ ITS応答性能の調査結果と対策 編～

Shimadzu Business Systems

2012/10/20　ITS事務局 赤羽根© 島津ビジネスシステムズ

※最新情報を反映したスライドをUploadしました。以下のURLをご参照ください。

Redmine + MySQL 応答性能の調査結果と対策http://www.slideshare.net/kakahane/my-sql-osaka5

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

Shimadzu Business Systems

話者紹介

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

3

参加コミュニティー ・京都アジャイル勉強会 ・RxTstudy ・Waraiテスト勉強会 ・TABOK勉強会 　ほか

Shimadzu Business Systems

2012年7月21日 RxTstudy #5 発表

4

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

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

Shimadzu Business Systems

0

55

110

0

35000

70000

全チケット数プロジェクト数ITS導入 ｰ 計測

20112010 2012

62000 Tickets (+6000) 110 Projects (+8) 330 Users (+30)

5

Shimadzu Business Systems

ITS導入 ｰ 計測

0

50

100

0

35000

70000

2010 後 2011 前 2011 後 2012 前

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

20112010 20126

完了率 91%（＋2）

2200/月 (＋200)

Shimadzu Business Systems

今日お話しする事　１／２

7

・ITS運用 3年半

・チケット6万件、年3万件増加

・Redmine 1.4→2.x系 　性能低下を回避する方法

1. 応答性能低下の回避

※性能低下原因→巻末注記2-3

Shimadzu Business Systems

今日お話しする事　2／２

8

・ITSの業務活用が急拡大 　使い続けても大丈夫なのか

・チケット ２００万件まで確認

・問題点を洗い出した

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

Redmine 　　　　使用者は？

Shimadzu Business Systems

教えてください！

9

遅いなぁ と感じている方は？性能チューニング したことある方は？

→60%

→25%

→5%

Shimadzu Business Systems

1. 応答性能低下の回避

10

Shimadzu Business Systems

1. 応答性能低下の回避

11

・9/16 Redmine.org News

・2.0.4 is Last Release of 2.0.x ・1.4.x メンテは2012末迄

早めのUpdateを行いたい。 事前に評価したら… 遅い…

http://www.redmine.org/news/70

Shimadzu Business Systems

1. 応答性能低下の回避

12

0 ms

100 ms

200 ms

300 ms

400 ms

500 ms

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

1.42.02.0 Tuned

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

Shimadzu Business Systems

1. 応答性能低下の回避

13

0 ms

100 ms

200 ms

300 ms

400 ms

500 ms

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

1.42.02.0 Tuned

チケット１枚表示 300ms　

Shimadzu Business Systems

1. 応答性能低下の回避

14

0 ms

100 ms

200 ms

300 ms

400 ms

500 ms

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

1.42.02.0 Tuned

1.4レベルに復活　

Shimadzu Business Systems

1. 応答性能低下の回避

15

0 ms

100 ms

200 ms

300 ms

400 ms

500 ms

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

1.42.0 Tuned

1.4レベルに復活　

Shimadzu Business Systems

1. 応答性能低下の回避

16

0 ms

100 ms

200 ms

300 ms

400 ms

500 ms

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

1.42.0 Tuned2.1 Tuned

2.1 is Faster than 2.0　

Shimadzu Business Systems

1. 応答性能低下の回避

17

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

参考文献　　#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 集中限界、進捗表示必須

Shimadzu Business Systems

1. 応答性能低下の回避

18

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

参考文献　　#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は「文房具」

Shimadzu Business Systems

1. 応答性能低下の回避

19

・Redmine には手を入れない 　　1) アップデートに追従 　　2) プラグインの安定動作

・Rails, Redmineを除く、電子計算機 　全域をチューニング対象 ・追加投資・高度技術の運用費を抑えたい

できるだけ平易な手法を選択

Shimadzu Business Systems

1. 応答性能低下の回避

20

・処理性能向上に資する主要対策

要約：遅い媒体、再処理を回避

＃ 対象 対策 例

① 通信 通信させない EtherNet

② 情報量 削減・圧縮 HTMLJS

③ キャッシュ 処理させない CPUDBMS

Shimadzu Business Systems

1. 応答性能低下の回避

21

対策① 通信させない　例）6→３Auth

ClientAPL

DBMS

SVN

WebEthernet等低速通信

Web

DBMS

Shimadzu Business Systems

1. 応答性能低下の回避

22

対策① 通信させない　例）6→３Auth

Client

APL

SVN

要約：少数Serverへ集約

Web

DBMS

Shimadzu Business Systems

1. 応答性能低下の回避

23

対策② 情報量を減らす。例)圧縮・展開

Auth

Client

APL

SVN

Http/1.1 Compress ↓

最大10倍速

Server

Shimadzu Business Systems

1. 応答性能低下の回避

24

対策③ キャッシュ → 再処理させない

Unico rn

RAID

OS　　　FS　　　NW

Ruby

Rails

Redmine

DBMS

HTTP

Reverse Proxy

Client

OS　　　FS　　　NW

Browser

JavaScript　/　DOM

Server

Shimadzu Business Systems

1. 応答性能低下の回避

25

対策③ キャッシュ　＝　㋖

Unico rn

RAID

OS　　　FS　　　NW

Ruby

Rails

Redmine

DBMS

HTTP

Reverse Proxy

Client

OS　　　FS　　　NW

Browser

JavaScript　/　DOM

㋖㋖㋖㋖

㋖㋖

㋖㋖

㋖

㋖

潤沢なメモリキャッシュ

Shimadzu Business Systems

1. 応答性能低下の回避

26

サーバー構成 - 対象領域

Unicorn

GC.disable

RAID5　　 +20GB

OS　　CentOS6 （64bit）

Ruby 1.9.3

Rails3

Redmine2 DBMS

MySQL

5.1 (5.5)

HTTP

Apache

2.2

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

VMware （運用円滑化）

VCS

Subversion

1.7

HTTP Reverse Proxy

---

5 Key Point

Shimadzu Business Systems

1. 応答性能低下の回避

27

サーバー構成 - 対象領域

Unicorn

GC.disable

RAID5　　 +20GB

OS　　CentOS6 （64bit）

Ruby 1.9.3

Rails3

Redmine2 DBMS

MySQL

5.1 (5.5)

HTTP

Apache

2.2

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

VMware （運用円滑化）

VCS

Subversion

1.7

HTTP Reverse Proxy

---

5 Key Point詳説詳説

Shimadzu Business Systems

1. 応答性能低下の回避

28

アプリケーションサーバーApache ＋ Passenger

Apache ＋ Unicorn

Apache ＋ Unicorn

GC.disable

1.0

1.1~1.2

1.2~2.0

安定・高負荷耐性のPassenger 高速・メモリ喰いのUnicorn

※なぜApache2？ →巻末注記2-4

Shimadzu Business Systems

1. 応答性能低下の回避

29

アプリケーションサーバーUnicorn の GC.disable とは？

Rubyのガベージコレクタを止めておき、5Req毎に1回実施する。

の成田一生さんがWEB+DB 70号の記事にされています。購入を推奨します。

@secondlife さんのブログにも書いてあります。http://d.hatena.ne.jp/secondlife/20111006/1317893282https://speakerdeck.com/u/hotchpotch/p/liao-li-wozhi-eruji-shu-2012

Shimadzu Business Systems

1. 応答性能低下の回避

30

アプリケーションサーバーUnicorn 設定 （参考）

１）Redmine Root / configu.ru　　require ‘unicorn/oob_gc’　　use Unicorn::OobGC, 5 # 5回に1度GC

２）Redmine Root / config / unicorn.conf.rb　　after_fork do | server, worker |　　 defined? .....　　 GC.disable ＃GC停止

Shimadzu Business Systems

1. 応答性能低下の回避

31

MySQL

DBMSのチューニングは難しい。MySQLと共にInstallされる、設定テンプレートを土台として３カ所だけ変更する方法をご紹介。

土台となる設定： my-innodb-heavy-4G.cnf

Shimadzu Business Systems

1. 応答性能低下の回避

32

MySQL（参考）注意！ 　・変更前の my.cnf を確保　・データベースのバックアップ確保　・DBが起動しなくなる場合がありま　　す。実施は自己責任でお願いします。

１）my-innodb-heavy-4G.cnf を my.cnf がある場所へCopy。２）my-innodb-heavy-4G.cnf をmy.cnf へRename。

Shimadzu Business Systems

1. 応答性能低下の回避

33

MySQL（参考）１）innodb_buffer_pool_size = 2G ~ 4G　　　→サーバー主メモリの40%~70%を設定２）innodb_log_file_size = 512M ~ 2G　　　→上記１）の値の25%~100%を設定。大きく　　　　　しすぎるとリカバリに時間がかかる。　　　　　また、この値を書き換える時は要注意。　　　　　必ず後述の手順で実施。３）thread_concurrency = 8 ~ 16　　　→コア数 × 2~4

※更なるTuning例→巻末注記2-2

Shimadzu Business Systems

1. 応答性能低下の回避

34

MySQL（参考） innodb_log_file_size の安全な変更手順① SET GLOBAL innodb_fast_shutdown = 0;　 これをmysql コマンドから実行② MySQL Serverを停止③ my.cnf の innodb_log_file_size を変更④ ログファイル２種(ib_logfile0, ib_logfile1)をRename

⑤ MySQL Serverを起動⑥ 問題なければ④でRenameしたログファイルを削除

Shimadzu Business Systems

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

35

Shimadzu Business Systems

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

36

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

0

200,000

400,000

600,000

800,000

2012 2015 2020 2025 2030

チケット数

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

Shimadzu Business Systems

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

37

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

Ticket関係 1万 27万

Shimadzu Business Systems

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

38

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

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

Shimadzu Business Systems

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

39

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

全文検索 20秒 対策必須

DB始動時の 暖機運転5分

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

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

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

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

Shimadzu Business Systems

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

40

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

まとめ

Shimadzu Business Systems

41

■応答時間の計測条件（詳細）　１）評価サーバー　　　計算機環境 VM 1台 (CPU Xeon 3GHz x4 Cores, Memory 8GB, Storage iSCSI-1G 150GB) on VMware ESXi　　　　※ 評価用サーバーを単独使用。よって外部からの影響要素は無視できる。　２）Redmine1.4の応答性能を維持したままRedmine2系へ移行するためのチューニング例 　　（Redmine本体には改変無し、Plug-in無し）　　　・1.4.4： CentOS6(x64), Apache2, REE1.8.7, Passenger, Rails2, MySQL5.1 + 軽度MemoryTune, 　　　・2.0.4： CentOS6(x64), Apache2, Ruby1.9.3, Unicorn+GC.disable, Rails3, MySQL5.1 + 拡充MemoryTune　３）評価対象　７画面　　　(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

巻末注記１

Shimadzu Business Systems

42

■MySQL

　１）DBサーバー再起動時の暖機運転が不要になる（Version 5.6）　　暖機運転とは、DBMS再起動後にデータやインデックスをメモリ上へ読み込ませる一連の処理。　　対象となるデータやインデックスが増えると、５分以上かかることもある。　　　　→ MySQL大阪勉強会(2012/10/22)でOracleの中の人に聞いてみた「MySQL5.6RCの新機能 BufferPool

　　　　Dump/Restoreにより、DB再スタート直後の性能低下を防ぐ。BufferPoolのメモリ内容を全てファイルへダンプし、それらを

　　　　再起動時に全Restoreすることで暖気運転が不要となり、本来性能を即座に引き出せる」　　　　 https://twitter.com/search/realtime?q=%23mysql_osaka&src=hash　２）更なるチューニング例 （ @kazeburo さん ）　　https://github.com/kazeburo/mysetup/tree/master/mysql　　http://blog.nomadscafe.jp/2012/10/mysql-mycnf-github.html■Redmine1.4 → 2.x アップデートによる処理遅延原因の推測　３） http://www.slideshare.net/slideshow/embed_code/13718690?rel=0&startSlide=51　　A) RoR3のStack増によるGC問題( http://bibwild.wordpress.com/2011/07/12/more-thoughts-on-unbearably-slow-rails3/ ) 　　B) RedmineのRoR3への最適化対応が手付かずな点(@marutosijp, 38:50, 品川Redmine USTream )が原因　　　だろうか。■HTTP Server：なぜ、NginxではなくApacheなのか。　４）NginxとUnicornの組み合わせが速いとの報告がありますが、当方環境の都合でApach2にしました。　　　なぜならば、Subversionをはじめとする複数のサービスがApacheに依存しているからです。

巻末注記２

協　力

島津ビジネスシステムズ

43Thanks to 西川 撤 / @mirakui / @Secondlife / Kyoto.rb / @beco_ippei

MySQL大阪勉強会 / Oracle / @kazeburo

Shimadzu Business Systems

島津製作所のご紹介

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

44

Shimadzu Business Systems

45

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