情報システム部門のタスク管理~ITS応答性能の調査結果と対策 編~ #RxTstudy #6 #Redmine
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

情報システム部門のタスク管理~ITS応答性能の調査結果と対策 編~ #RxTstudy #6 #Redmine

  • 13,373 views
Uploaded on

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

※最新情報を反映したスライドをUploadしました。以下のURLをご参照ください。
http://www.slideshare.net/kakahane/my-sql-osaka5

概要:ITS(Redmine) の全社運用が3年半を経過した。チケット数は61,000を超え、その後も年間24,000超のペースで増加を続けている。Redmine2.x系へのアップデート(予定)に伴う処理遅延が大きいと判明したことから、画面応答性能の改善が喫緊の課題となった。対策として電子計算機環境全域に対するチューニング法を調査・検討した結果、応答性能を落とさずRedmine2.x系へアップデートする組合わせの1例が得られたので、200万件での性能検証結果と併せてコミュニティーにご紹介したい。
 
2012/10/31:@marutosijp さんの情報に基づき、2.0-stableと2.1-stableの比較結果を追記
https://twitter.com/marutosijp/status/261114840720998400

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • mysqltuner.plの結果がいまいちなので調整したいが「メモリが足らない:1.5GB」ので再考したいです。
    といってもmysqlよりrails環境周りのチューニングかもと思う今日このごろ
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
13,373
On Slideshare
5,149
From Embeds
8,224
Number of Embeds
14

Actions

Shares
Downloads
10
Comments
1
Likes
6

Embeds 8,224

http://forza.cocolog-nifty.com 6,968
http://slides.redmine.jp 768
http://app.m-cocolog.jp 320
https://twitter.com 87
http://localhost 20
http://asakusa-satellite.org 17
http://webcache.googleusercontent.com 15
https://si0.twimg.com 14
http://t.co 6
http://app.cocolog-nifty.com 3
http://s.deeeki.com 3
http://cache.yahoofs.jp 1
http://search.biglobe.ne.jp 1
http://news.google.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Shimadzu Business Systems 情報システム部門の タスク管理∼ ITS応答性能の調査結果と対策 編∼© 島津ビジネスシステムズ 2012/10/20 ITS事務局 赤羽根
  • 2. Shimadzu Business Systems話者紹介・赤羽根(@akahane92)・島津製作所 業務系システム子会社・開発技術者 参加コミュニティー ・京都アジャイル勉強会  → 障害対策専任  ・RxTstudy ・Waraiテスト勉強会 ・TABOK勉強会  ほか  → 内部統制   → 基盤技術標準化 (いまここ) 2
  • 3. Shimadzu Business Systems2012年7月21日 RxTstudy #5 発表 ・IT全般統制 ・ITS全社適用 ・Excel脱却 ・全体最適化 ・10ルール ・主要画面  応答100ms以下http://www.slideshare.net/kakahane/it-13718690 3
  • 4. Shimadzu Business Systems 全チケット数ITS導入 ー 計測 プロジェクト数70000 62000 Tickets (+6000) 110 110 Projects (+8) 330 Users (+30)35000 55 0 0 2010 2011 2012 4
  • 5. Shimadzu Business Systems 全チケット数ITS導入 ー 計測 平均発行数 完了率 完了率 91%(+2)70000 100 2200/月 (+200)35000 50 0 0 2010 後 2011 前 2011 後 2012 前 2010 2011 2012 5
  • 6. Shimadzu Business Systems今日お話しする事 1/21. 応答性能低下の回避・ITS運用 3年半・チケット6万件、年3万件増加・Redmine 1.4→2.x系 性能低下を回避する方法 6 ※性能低下原因→巻末注記2-3
  • 7. Shimadzu Business Systems今日お話しする事 2/22. ITSの耐用検証(応答基準) ・ITSの業務活用が急拡大  使い続けても大丈夫なのか ・チケット 200万件まで確認 ・問題点を洗い出した 7
  • 8. Shimadzu Business Systems教えてください! Redmine     使用者は? →60% 遅いなぁ と感じている方は? →25% 性能チューニング したことある方は? 8 →5%
  • 9. Shimadzu Business Systems1. 応答性能低下の回避 9
  • 10. Shimadzu Business Systems1. 応答性能低下の回避・9/16 Redmine.org News http://www.redmine.org/news/70・2.0.4 is Last Release of 2.0.x・1.4.x メンテは2012末 早めのUpdateを行いたい。 事前に評価したら… 遅い… 10
  • 11. Shimadzu Business Systems 1. 応答性能低下の回避500 ms 1.4 2.0400 ms 2.0 Tuned300 ms200 ms100 ms 0 ms ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C 11 ※計測諸条件→巻末注記1
  • 12. Shimadzu Business Systems 1. 応答性能低下の回避500 ms 1.4 2.0400 ms 2.0 Tuned300 ms200 ms100 ms 0 ms ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C 12 チケット1枚表示 300ms 
  • 13. Shimadzu Business Systems 1. 応答性能低下の回避500 ms 1.4 2.0400 ms 2.0 Tuned300 ms200 ms100 ms 0 ms ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C 13 1.4レベルに復活 
  • 14. Shimadzu Business Systems 1. 応答性能低下の回避500 ms 1.4 2.0 Tuned400 ms300 ms200 ms100 ms 0 ms ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C 14 1.4レベルに復活 
  • 15. Shimadzu Business Systems 1. 応答性能低下の回避500 ms 1.4 2.0 Tuned400 ms 2.1 Tuned300 ms200 ms100 ms 0 ms ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C 15 2.1 is Faster than 2.0 
  • 16. Shimadzu Business Systems1. 応答性能低下の回避 ・画面応答時間の基準とは? 100ms 直接操作している一体感 1000ms 遅延を感じつつも軽快 10000ms 集中限界、進 表示必須参考文献  #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 16
  • 17. Shimadzu Business Systems1. 応答性能低下の回避 ・画面応答時間の基準とは? 100ms 直接操作している一体感 1000ms 遅延を感じつつも軽快 10000ms 集中限界、進 表示必須参考文献 ITSは「文房具」  #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 17
  • 18. Shimadzu Business Systems1. 応答性能低下の回避・Redmine には手を入れない  1) アップデートに追従  2) プラグインの安定動作・Rails, Redmineを除く、電子計算機 全域をチューニング対象・追加投資・高度技術の運用費を抑えたいできるだけ平易な手法を選択 18
  • 19. Shimadzu Business Systems1. 応答性能低下の回避・処理性能向上に資する主要対策 # 対象 対策 例 ① 通信 通信させない EtherNet HTML ② 情報量 削減・圧縮 JS CPU ③ キャッシュ 処理させない DBMS要約:遅い媒体、再処理を回避 19
  • 20. Shimadzu Business Systems1. 応答性能低下の回避対策① 通信させない 例)6→3 DB Auth MSEthernet等低速通信 APL Web Client SVN 20
  • 21. Shimadzu Business Systems1. 応答性能低下の回避対策① 通信させない 例)6→3 DB Auth MS APL Web SVN Client 要約:少数Serverへ集約 21
  • 22. Shimadzu Business Systems1. 応答性能低下の回避対策② 情報量を減らす。例)圧縮・展開 DB Auth MS Http/1.1 Compress APL Web ↓ 最大10倍速 SVN Client 22
  • 23. Shimadzu Business Systems1. 応答性能低下の回避対策③ キャッシュ → 再処理させないServer ClientRedmine Reverse Uni Proxy co Browser Rails rn HTTP JavaScript / DOM Ruby DBMS OS   FS   NW OS   FS   NW RAID 23
  • 24. Shimadzu Business Systems1. 応答性能低下の回避対策③ キャッシュ = ㋖Server Client ReverseRedmine Uni ㋖ Proxy㋖ co rn ㋖ Browser Rails ㋖HTTP JavaScript / DOM Ruby㋖DBMS ㋖ ㋖㋖OS   FS   NW 潤沢なメモリ OS   FS   NW ㋖ ㋖ RAID キャッシュ 24
  • 25. Shimadzu Business Systems1. 応答性能低下の回避サーバー構成 - 対象領域 5 Key Point Redmine2 Unicorn DBMS HTTP VCS HTTP Reverse Rails3 GC.disable MySQL Apache Subversi Proxy on 5.1 2.2 --- Ruby 1.9.3 (5.5) 1.7 OS  CentOS6 (64bit)VMware (運用円滑化) RAID5   CPU 2∼4コア メモリ 4∼8GB +20GB 25
  • 26. Shimadzu Business Systems1. 応答性能低下の回避サーバー構成 - 対象領域 詳説 5 Key Point Redmine2 Unicorn DBMS HTTP VCS HTTP Reverse Rails3 GC.disable MySQL Apache Subversi Proxy on 5.1 2.2 --- Ruby 1.9.3 (5.5) 1.7 OS  CentOS6 (64bit)VMware (運用円滑化) RAID5   CPU 2∼4コア メモリ 4∼8GB +20GB 26
  • 27. Shimadzu Business Systems1. 応答性能低下の回避アプリケーションサーバー ※なぜApache2? →巻末注記2-4 Apache + Passenger 1.0 Apache + Unicorn 1.1~1.2 Apache + Unicorn 1.2~2.0 GC.disable安定・高負荷耐性のPassenger 高速・メモリ いのUnicorn27
  • 28. Shimadzu Business Systems1. 応答性能低下の回避アプリケーションサーバー Unicorn の GC.disable とは?Rubyのガベージコレクタを止めておき、5Req毎に1回実施する。 の成田一生さんがWEB+DB 70号の記事にされています。 購入を推奨します。 @secondlife さんのブログにも書いてあります。 http://d.hatena.ne.jp/secondlife/20111006/1317893282 https://speakerdeck.com/u/hotchpotch/p/liao-li-wozhi-eruji- shu-2012 28
  • 29. Shimadzu Business Systems1. 応答性能低下の回避アプリケーションサーバー Unicorn 設定 (参考) 1)Redmine Root / configu.ru   require ‘unicorn/oob_gc’   use Unicorn::OobGC, 5 # 5回に1度GC 2)Redmine Root / config / unicorn.conf.rb   after_fork do | server, worker |    defined? .....    GC.disable #GC停止 29
  • 30. Shimadzu Business Systems1. 応答性能低下の回避MySQL DBMSのチューニングは難しい。 MySQLと共にInstallされる、 設定テンプレートを土台として 3カ所だけ変更する方法をご紹介。土台となる設定: my-innodb-heavy-4G.cnf 30
  • 31. Shimadzu Business Systems1. 応答性能低下の回避MySQL(参考) 注意!  ・変更前の my.cnf を確保  ・データベースのバックアップ確保  ・DBが起動しなくなる場合がありま   す。実施は自己責任でお願いします。1)my-innodb-heavy-4G.cnf を my.cnf がある場所へCopy。2)my-innodb-heavy-4G.cnf をmy.cnf へRename。 31
  • 32. Shimadzu Business Systems1. 応答性能低下の回避MySQL(参考) 1)innodb_buffer_pool_size = 2G ~ 4G    →サーバー主メモリの40%~70%を設定 2)innodb_log_file_size = 512M ~ 2G    →上記1)の値の25%~100%を設定。大きく      しすぎるとリカバリに時間がかかる。      また、この値を書き換える時は要注意。      必ず後述の手順で実施。 3)thread_concurrency = 8 ~ 16    →コア数 × 2~4 32 ※更なるTuning例→巻末注記2-2
  • 33. Shimadzu Business Systems1. 応答性能低下の回避MySQL(参考)innodb_log_file_size の安全な変更手順 ① SET GLOBAL innodb_fast_shutdown = 0;   これをmysql コマンドから実行 ② MySQL Serverを停止 ③ my.cnf の innodb_log_file_size を変更 ④ ログファイル2種(ib_logfile0, ib_logfile1)をRename ⑤ MySQL Serverを起動 ⑥ 問題なければ④でRenameしたログファイルを削除 33
  • 34. Shimadzu Business Systems2. ITSの耐用検証(応答基準) 34
  • 35. Shimadzu Business Systems 2. ITSの耐用検証(応答基準) このまま使い続けて大丈夫なのか? チケット数800,000 6万件の実データを複写600,000 し、実際に200万件ま で動作を確認した。400,000200,000 0 2012 2015 2020 2025 2030 35
  • 36. Shimadzu Business Systems2. ITSの耐用検証(応答基準) 現在 最大想定チケット数 6万 200万カスタムField値 63万 1200万添付ファイル 3万 140万 時間記録 2万 74万 注記欄 14万 363万 Watcher 3万 76万 Ticket関係 1万 27万 36
  • 37. Shimadzu Business Systems 2. ITSの耐用検証(応答基準)1,200 ms ITS Top PJ List PJ Top Ticket List Issue A 900 ms Issue B Issue C 600 ms 300 ms 0 ms 6万 10万 20万 30万 50万 70万 100万 150万 200万 37 ※計測諸条件→巻末注記1
  • 38. Shimadzu Business Systems 2. ITSの耐用検証(応答基準) 2012年末リリースの1,200 ms ITS Top MySQL 5.6に対策有り BufferPool PJ List (巻末注記2-1) 4GBでの結果 PJ Top (BufferPool Dump/Restore) → 8GB必須 Ticket List Issue A DB始動時の 900 ms Issue B 暖機運転5分 Issue C 全文検索 20秒 対策必須 600 ms 300 ms 0 ms 6万 10万 20万 30万 50万 70万 100万 150万 200万 38 ※計測諸条件→巻末注記1
  • 39. Shimadzu Business Systems2. ITSの耐用検証(応答基準)まとめITSと連動した全文検索の解決策と、16GBのメモリがあれば200万チケットの運用に於いても日常的に使用する画面・機能において100ms前後の応答性能をRedmine2.0系, 2.1系で期待できる。 39
  • 40. Shimadzu Business Systems 巻末注記1■応答時間の計測条件(詳細) 1)評価サーバー   計算機環境 VM 1台 (CPU Xeon 3GHz x4 Cores, Memory 8GB, Storage iSCSI-1G 150GB) on VMware ESXi    ※ 評価用サーバーを単独使用。よって外部からの影響要素は無視できる。 2)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 3)評価対象 7画面   (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件表示) 4)評価方法  httperf http://www.hpl.hp.com/research/linux/httperf/ (下記コマンドをサーバー上で3回実行し、平均する) 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 40
  • 41. Shimadzu Business Systems 巻末注記2■MySQL 1)DBサーバー再起動時の暖機運転が不要になる(Version 5.6)  暖機運転とは、DBMS再起動後にデータやインデックスをメモリ上へ読み込ませる一連の処理。  対象となるデータやインデックスが増えると、5分以上かかることもある。    → MySQL大阪勉強会(2012/10/22)でOracleの中の人に聞いてみた「MySQL5.6RCの新機能 BufferPool    Dump/Restoreにより、DB再スタート直後の性能低下を防ぐ。BufferPoolのメモリ内容を全てファイルへダンプし、それらを    再起動時に全Restoreすることで暖気運転が不要となり、本来性能を即座に引き出せる」     https://twitter.com/search/realtime?q=%23mysql_osaka&src=hash 2)更なるチューニング例 ( @kazeburo さん )  https://github.com/kazeburo/mysetup/tree/master/mysql  http://blog.nomadscafe.jp/2012/10/mysql-mycnf-github.html■Redmine1.4 → 2.x アップデートによる処理遅延原因の推測 3) 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なのか。 4)NginxとUnicornの組み合わせが速いとの報告がありますが、当方環境の都合でApach2にしました。   なぜならば、Subversionをはじめとする複数のサービスがApacheに依存しているからです。 41
  • 42. 協 力島津ビジネスシステムズThanks to 西川 撤 / @mirakui / @Secondlife / Kyoto.rb / @beco_ippei 42 MySQL大阪勉強会 / Oracle / @kazeburo
  • 43. Shimadzu Business Systems島津製作所のご紹介  島津製作所グループ  事業領域   ・分析計測   ・医用機器   ・航空機器   ・半導体機器   ・油圧, 光学 43
  • 44. Shimadzu Business Systems ご清聴 ありがとうございました 44