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

1. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmineチューニングの実際と限界〜200万チケットでもサクサクなRedmineの作り方〜第8回 Redmine.tokyo 2015年5月16 日株式会社島津ビジネスシステムズ基盤技術部赤羽根州晴 kakahane@sbs.shimadzu.co.jp

2. 2 ありがとう｡ Thanksalot. Mercibeaucoup.

6. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話しすること 6 １）200万チケットでもサクサク動くRedmineの全レシピ２）Redmine2.6を3.0へUpdateすると平均で○○％速くなる３）Ruby2.0を2.2へUpdateすると平均で○○％速くなる４）HDDをSSDに変更すると平均で○○％速くなる５）Redmineチューニング事例10種６）全走査型の全文検索は○○万チケットで性能限界に到達する

9. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 9 使用しているRedmine 環境は？有効回答数 65件、複数回答 UNIX Like 53% Windows/Bit nami 27% Mac 4% 未回答 10% 未使用 6% UNIX Like Windows/Bitna mi Mac 未回答未使用

10. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 10 使用しているRedmine 環境は？有効回答数 65件、複数回答 UNIX Like 53% Windows/Bit nami 27% Mac 4% 未回答 10% 未使用 6% UNIX Like Windows/Bitna mi Mac 未回答未使用 UNIX Like ：53％ Windows ：27％

12. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 12 Redmineの環境構築方法は？有効回答数 65件、複数回答ソースを入手 40% Bitnamiインストーラー 24% rpm等パッケージ使用 7% ALMinium 4% 仮想マシンイメージ 3% クラウドサービス 3% 不明 12% 未回答 7% ソースを入手 Bitnamiインストーラー rpm等パッケージ使用 ALMinium 仮想マシンイメージクラウドサービス不明未回答

13. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 13 Redmineの環境構築方法は？有効回答数 65件、複数回答ソースを入手 40% Bitnamiインストーラー 24% rpm等パッケージ使用 7% ALMinium 4% 仮想マシンイメージ 3% クラウドサービス 3% 不明 12% 未回答 7% ソースを入手 Bitnamiインストーラー rpm等パッケージ使用 ALMinium 仮想マシンイメージクラウドサービス不明未回答スクラッチ構築： 40％事前構築の展開： 38％クラウド： 3％

14. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 教えて下さい 14 Redmine ・遅いと感じている方は？・性能チューニング経験は？・使用しているDBMSは？（Postgresql、MySQL、SQLite、他） Eric Peacock https://www.flickr.com/photos/evilpeacock/6365513881/

17. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 株式会社島津製作所 2014年3月31日現在 1875年 1917年 266億円創業｜設立｜資本金｜従業員数｜ 3,075億円 (2014年3月期) 69社 (国内25社, 海外44社) グループ売上高｜グループ会社｜社是｜科学技術で社会に貢献する経営理念｜｢人と地球の健康｣への願いを実現する 17 10,612名 (連結)

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

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

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

28. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要・プロジェクト数、ユーザー数の経年変化 28 0 50 100 150 200 250 300 350 0 20 40 60 80 100 120 140 160 2010 2011 2012 2013 2014 プロジェクト数ユーザー数ユーザー数プロジェクト数 Project数 130 User数 350

29. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜チケットの発行数と完了率 29 0 10 20 30 40 50 60 70 80 90 100 0 5000 10000 15000 20000 25000 30000 35000 40000 2010 2011 2012 2013 2014 Ticket発行数完了率近似曲線（線形）完了率 87% → 93% 累計 130,000 3,000/月

30. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜完了所要日数の分布と平均 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日平均完了日数日 30

31. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜障害･バグチケット数と完了所要日数の平均 31 0 20 40 60 80 100 120 140 0 500 1000 1500 2000 2500 2010 2011 2012 2013 2014 障害チケット数完了所要日数平均所要日数平均 129日 → 59日 No Ticket, No Commit

32. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜｢障害･バグ｣チケット密度 32 0 20 40 60 80 100 0 10000 20000 30000 40000 2010 2011 2012 2013 2014 件／KT (Kilo Ticket) チケット発行数障害･バグチケット発行数障害･バグチケット密度障害･バグチケット密度(Spike除去)

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

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

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

45. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  ボトルネックはどこか？ 45 ＃対象対策例１通信狭帯域を回避 Ethernet ２情報量圧縮 HTML, Text ３電子計算再処理を回避多段キャッシュ４永続化高速装置へ交換 HDD ５アルゴリズム算法選択による計算量削減 Sort, GC, Crypt

49. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策３再処理回避 49 Server Pas sen ger RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy Client OS FS NW Browser JavaScript / DOM

50. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策３再処理回避 50 Server Pas sen ger RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy Client OS FS NW Browser JavaScript / DOM ㋖㋖㋖㋖㋖㋖㋖㋖㋖㋖㋖㋖・潤沢なメモリ・多段キャッシュ

52. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策５算法選択による計算量削減 52 Server Pas sen ger RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy 算法の選択による速度向上 Sort, GC, Crypt

53. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  チューニング要点 53 Passenger5 OS CentOS6 （64bit） Ruby 2.2 Rails4.2 Redmine 3.0 DBMS MySQL 5.6 HTTP Apache 2.2 メモリ 4〜16GBCPU 2〜4コア VMware （可用性、信頼性） VCS Subversion 1.7 HTTP Reverse Proxy --- ：8KeyPoint Network

54. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  チューニング要点 54 Passenger5 OS CentOS6 （64bit） Ruby 2.2 Rails4.2 Redmine 3.0 DBMS MySQL 5.6 HTTP Apache 2.2 メモリ 4〜16GBCPU 2〜4コア VMware （可用性、信頼性） VCS Subversion 1.7 HTTP Reverse Proxy --- ：8KeyPoint Network Redmineは変更しない

59. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 59 【背景】・年間３万６千チケット起票・業務の中心にITS（Redmine）・処理遅延や障害停止は回避必須【2012年10月】・ITSの業務活用が急拡大・200万チケットまで確認・問題を洗い出した【2015年5月】・予測と実績・Redmine, Ruby, Rails, H/Wの変化・再度、性能ベンチマークを計測して最適解を選ぶ

62. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 62 画面応答時間の基準*とは？ 100ms 直接操作している一体感 * 参考文献 Jakob Nielsen (1993). Response Times: The 3 Important Limits http://www.useit.com/papers/responsetime.html Miller, R. B. (1968). Response time in man-computer conversational transactions. http://theixdlibrary.com/pdf/Miller1968.pdf

63. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 63 画面応答時間の基準*とは？ 100ms 直接操作している一体感 1000ms 遅延を感じつつも軽快 * 参考文献 Jakob Nielsen (1993). Response Times: The 3 Important Limits http://www.useit.com/papers/responsetime.html Miller, R. B. (1968). Response time in man-computer conversational transactions. http://theixdlibrary.com/pdf/Miller1968.pdf

64. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 64 画面応答時間の基準*とは？ 100ms 直接操作している一体感 1000ms 遅延を感じつつも軽快 10000ms 集中限界、進捗表示必須 * 参考文献 Jakob Nielsen (1993). Response Times: The 3 Important Limits http://www.useit.com/papers/responsetime.html Miller, R. B. (1968). Response time in man-computer conversational transactions. http://theixdlibrary.com/pdf/Miller1968.pdf

65. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 65 画面応答時間の基準*とは？ 100ms 直接操作している一体感 1000ms 遅延を感じつつも軽快 10000ms 集中限界、進捗表示必須 * 参考文献 Jakob Nielsen (1993). Response Times: The 3 Important Limits http://www.useit.com/papers/responsetime.html Miller, R. B. (1968). Response time in man-computer conversational transactions. http://theixdlibrary.com/pdf/Miller1968.pdf Redmineは文房具

68. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜実測値 68 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 累計1216万アクセス 3ヶ月で前年越えRedmineアクセス数*の経年変化 * 6年分のApache アクセスログに記載されたURI 件

70. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜実績値６年間の運用結果*を集計 70* Production.logに記載された処理応答時間 (Redmine～DB) ・673万回の処理 100ms 32% 200ms 21% 300ms 17% 400ms 10% 500ms 6% 600ms 4% 700ms 2% 1000ms超 5% 100ms 200ms 300ms 400ms 500ms 600ms 700ms 800ms 900ms 1000ms 1000ms超

71. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜実績値６年間の運用結果*を集計 71* Production.logに記載された処理応答時間 (Redmine～DB) ・673万回の処理・半分が200ms以下・95%が1秒以下 100ms 32% 200ms 21% 300ms 17% 400ms 10% 500ms 6% 600ms 4% 700ms 2% 1000ms超 5% 100ms 200ms 300ms 400ms 500ms 600ms 700ms 800ms 900ms 1000ms 1000ms超

72. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜実績値６年間の運用結果*を集計 72 統計要約最小値 : 1 第１四分位点 : 67 中央値 : 185 平均値 : 415 第３四分位点 : 339 最大値 :3314811 * Production.logに記載された処理応答時間 (Redmine～DB) ・673万回の処理・半分が200ms以下・95%が1秒以下・中央値185ms 100ms 32% 200ms 21% 300ms 17% 400ms 10% 500ms 6% 600ms 4% 700ms 2% 1000ms超 5% 100ms 200ms 300ms 400ms 500ms 600ms 700ms 800ms 900ms 1000ms 1000ms超

74. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜評価対象６年間の運用結果*を集計し、主要画面を決定 74* 6年分のApache アクセスログに記載されたURI 35% 20%6% 6% 4% 4% 3% 2% 2% 1% 17% チケット表示チケット一覧 WikiページプロジェクトTop 添付ダウンロード検索（プロジェクト）ログイン画面マイページ RedmineTop 添付画像サムネイルその他・1080万アクセス

75. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜評価対象６年間の運用結果*を集計し、主要画面を決定 75 35% 20%6% 6% 4% 4% 3% 2% 2% 1% 17% チケット表示チケット一覧 WikiページプロジェクトTop 添付ダウンロード検索（プロジェクト）ログイン画面マイページ RedmineTop 添付画像サムネイルその他 * 6年分のApache アクセスログに記載されたURI ・1080万アクセス・チケット一覧＋単票表示で55% ・利用頻度、遅延を体感しやすい画面

76. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜評価対象６年間の運用結果*を集計し、主要画面を決定 76 35% 20% 6% 2% チケット表示チケット一覧 WikiページプロジェクトTop 添付ダウンロード検索（プロジェクト）ログイン画面マイページ RedmineTop 添付画像サムネイルその他・1080万アクセス・チケット一覧＋単票表示で55% ・利用頻度、遅延を体感しやすい画面・ベンチマーク対象が全体の62%を網羅 * 6年分のApache アクセスログに記載されたURI

78. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜テストデータ 78 0 5,000,000 10,000,000 15,000,000 20,000,000 25,000,000 30,000,000 10万件 20万件 30万件 50万件 70万件 100万件 150万件 200万件データレコード数チケット数チケット数 Custom Field（種類） Custom Field（記録）添付ファイル時間記録注記欄リポジトリ変更リポジトリ変更セットウォッチャー Ticket関係性規模

79. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜テストデータ 79 0 5,000,000 10,000,000 15,000,000 20,000,000 25,000,000 30,000,000 10万件 20万件 30万件 50万件 70万件 100万件 150万件 200万件データレコード数チケット数チケット数 Custom Field（種類） Custom Field（記録）添付ファイル時間記録注記欄リポジトリ変更リポジトリ変更セットウォッチャー Ticket関係性規模 200万チケットは 3000万レコードカスタムフィールドは 77種に固定

82. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測方法 82 a) 主要画面７種に対して（2並列で25回アクセス）を×10回実行した平均応答時間を計測 b) 上記a)をDBキャッシュ状態３種を順次切替えて実行する。(1)DBキャッシュ無し、(2)DBキャッシュ保存･復元、(3)Fullメモリキャッシュ c) 上記の(3)Fullメモリキャッシュを採用する。 d) 上記のa)～c) を10万～200万まで繰り返す。メモリ、Ruby、 OOBGCの有無 10万 20万 30万 50万 70万 100万 150万 200万 8G_Ruby1.9.3 所要時間合計（ミリ秒） 1231 1206 1376 1405 1513 1515 1470 1495 主要画面７種のURI /its30 26.3 26.1 23.2 25.7 22.3 23.7 25.6 22.6 /its30/projects 51.4 51.4 56.6 54.6 56.1 56.9 52.6 56.3 /its30/projects/sscope 118.1 116.2 120.3 114.5 116.9 112.1 120.6 122.5 /its30/issues?per_page=200 536 512.3 521.2 554.2 614.4 600.5 542.8 525.4 /its30/issues/1 126.5 111 251.4 246.4 253.6 246 257 264.4 /its30/issues/47548 226.8 222.6 238.8 251 282.3 309.2 305.5 338.7 /its30/issues/51782 146.1 166.4 164.3 158.5 167.7 166.9 166.2 164.7

83. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測方法 83 計測プログラム # bench.rb # -*- coding: utf-8 -*- url_list = [ "/its30 ", "/its30/projects ", "/its30/projects/sscope ", "/its30/issues?per_page=200 ", "/its30/issues/1 ", "/its30/issues/47548 ", "/its30/issues/51782 " ] puts "--- Environment ---" puts `httpd -version` puts `ruby -v` puts `gem list --local passenger` puts `export RAILS_ENV=production; /var/lib/its/rm30_its/bin/about` puts `export RAILS_ENV=production; /var/lib/its/rm30_its/bin/bundle list` ti = 10 result = [] url_list.each { |url| rate_avg = ms_avg = 0 puts "--- #{url} ---" ti.times { res = `httperf --hog --server=localhost --port=80 --uri=#{url} --num-conns 2 -- num-calls 25 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" } puts "-------------------------" result.size.times { |r| puts "#{r+1} t #{url_list[r]} t #{result[r][0]} t #{result[r][1]}" } puts "-------------------------" result.size.times { |r| puts " AVG Rate: #{result[r][0]} req/s (#{result[r][1]} ms/req)" }

84. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果１ 84 0 2000 4000 6000 8000 10000 12000 14000 8G_Ruby2.2.2 8G_Ruby2.1.6_OOBGC 8G_Ruby2.1.6 8G_Ruby2.0.0_OOBW 8G_Ruby2.0.0 8G_Ruby1.9.3 Redmine3.0の最速ベンチ 10万 20万 30万 50万 70万 100万 150万 200万 ms

85. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果１ 85 0 2000 4000 6000 8000 10000 12000 14000 8G_Ruby2.2.2 8G_Ruby2.1.6_OOBGC 8G_Ruby2.1.6 8G_Ruby2.0.0_OOBW 8G_Ruby2.0.0 8G_Ruby1.9.3 Redmine3.0の最速ベンチ 10万 20万 30万 50万 70万 100万 150万 200万 ms

86. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果１ 86 0 2000 4000 6000 8000 10000 12000 14000 8G_Ruby2.2.2 8G_Ruby2.1.6_OOBGC 8G_Ruby2.1.6 8G_Ruby2.0.0_OOBW 8G_Ruby2.0.0 8G_Ruby1.9.3 Redmine3.0の最速ベンチ 10万 20万 30万 50万 70万 100万 150万 200万最も遅い Ruby2.0 に比して、最速のRuby2.1.6+OOGBCは 25.4% 速い

88. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果２ 88 0 2000 4000 6000 8000 10000 12000 Redmine3.0 Redmine2.6 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.0は速いのか ms

89. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果２ 89 0 2000 4000 6000 8000 10000 12000 Redmine3.0 Redmine2.6 10万 20万 30万 50万 70万 100万 150万 200万・Redmine 2.6 から 3.0 へのアップデートにより、平均で7.4 %の性能向上が得られる・Rails4.2への変更に伴うMultiThread ・Rails4.2の内部改善 Redmine3.0は速いのか ms

90. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果３ 90 RedmineのRubyバージョン変更の効果 0 2000 4000 6000 8000 10000 12000 14000 8G_Ruby2.2.2 8G_Ruby2.1.6_OOBGC 8G_Ruby2.0.0 Redmine3.0 10万 20万 30万 50万 70万 100万 150万 200万 0 2000 4000 6000 8000 10000 12000 14000 8G_Ruby2.1.6_OOBGC 8G_Ruby2.0.0 Redmine2.6 10万 20万 30万 50万 70万 100万 150万 200万 ms ms

91. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果３ 91 RedmineのRubyバージョン変更の効果 0 2000 4000 6000 8000 10000 12000 14000 8G_Ruby2.2.2 8G_Ruby2.1.6_OOBGC 8G_Ruby2.0.0 Redmine3.0 10万 20万 30万 50万 70万 100万 150万 200万 0 2000 4000 6000 8000 10000 12000 14000 8G_Ruby2.1.6_OOBGC 8G_Ruby2.0.0 Redmine2.6 10万 20万 30万 50万 70万 100万 150万 200万・Redmine3.0は、Ruby2.0か Ruby2.2へアップデートすると平均で 20.8% 性能が向上する ms ms

92. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果３ 92 RedmineのRubyバージョン変更の効果 0 2000 4000 6000 8000 10000 12000 14000 8G_Ruby2.2.2 8G_Ruby2.1.6_OOBGC 8G_Ruby2.0.0 Redmine3.0 10万 20万 30万 50万 70万 100万 150万 200万 0 2000 4000 6000 8000 10000 12000 14000 8G_Ruby2.1.6_OOBGC 8G_Ruby2.0.0 Redmine2.6 10万 20万 30万 50万 70万 100万 150万 200万・Redmine3.0は、Ruby2.0か Ruby2.2へアップデートすると平均で 20.8% 性能が向上する・Redmine2.6は、Ruby2.0か Ruby2.1へアップデートすると平均で 24.8% 性能が向上する ms ms

94. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果４ 94 過去のRedmineと比較最速ベンチマークを比較してみると、 Redmine2.3に比較して、 →3.0は 29.2% →2.6は 33.4% 性能が低下している。 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 200万 150万 100万 70万 50万 30万 20万 10万 ms

95. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果４ 95 過去のRedmineと比較 Redmineの機能増加が、Rails･Redmine MultiThread化･Ruby- GCによる性能向上分を消費し、不足したものと推測電子計算機の能力向上が生じているため、比較精度は完全ではない。性能低下はさらに大きいと予想される 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 200万 150万 100万 70万 50万 30万 20万 10万 ms

98. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果５ 98 HDDをSSDに変換する効果・Redmine3.0においてHDDをSSDに交換すると、平均で 25.7 % 性能が向上する・性能低下が軽減 HDD 38.6%減 ↓ SSDで16.7%減 0 2000 4000 6000 8000 10000 12000 10万 20万 30万 50万 70万 100万 150万 200万 ms

99. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果６ 99 複数プラグイン導入の性能への影響結果だけ記載（グラフは後ほど） Redmine Pluginの多くはHookによって画面処理に割り込みをかけている。多数のHook処理の中に、性能考慮が十分でないコードが繰り返し呼び出された場合、応答性能への影響が懸念される。実際に計測してみた結果、平均4%の性能低下が計測された。不要なPluginを除去することで、応答性能が4パーセント程度向上する。

100. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000000 4000000 6000000 8000000 10000000 12000000 14000000 No Cash BP Save & Load 200万 150万 100万 70万 50万 30万 20万 10万ベンチマーク｜計測結果７ 100 FTS応答性能の計測・Redmineの全文検索は、全走査（非索引型）の検索処理によって実現されている。・No BP Cash 10万チケット 24秒 100万チケット 207秒（3分27秒） 200万チケット 6204秒（103分24秒）・BP Save & Load 10万チケット 17秒 100万チケット 162秒（２分42秒） 200万チケット 3601秒（60分1秒）秒

101. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000000 4000000 6000000 8000000 10000000 12000000 14000000 No Cash BP Save & Load 200万 150万 100万 70万 50万 30万 20万 10万ベンチマーク｜計測結果７ 101 FTS応答性能の計測１）SSDにしても効果があまり無かった２）対策全走査対象データを全てメモリ上に乗せる３）Redmineのチューニング限界点「FTSClickAttackによるDDoS」には耐えられない。実際に数回発生。（200人のブラウザが真っ白でWaiting。F5攻撃が始まる。思い出しても冷や汗がでる）４）希望の光 JPLがPoCを終えているという超高速索引型FTS。皆さんは、どのような技法だと思いますか？秒秒

103. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 103 Redmine3.0は200万チケットで“サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 10万 20万 30万 50万 70万 100万 150万 200万チケット表示（小）チケット表示（大）チケット表示（中）チケット一覧プロジェクトTop プロジェクト一覧 RedmineTop ms

104. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 104 Redmine3.0は200万チケットで“サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 10万 20万 30万 50万 70万 100万 150万 200万チケット表示（小）チケット表示（大）チケット表示（中）チケット一覧プロジェクトTop プロジェクト一覧 RedmineTop ms チューニングの結果、Redmine3.0の主要画面７種の平均応答時間は106ms

105. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 105 Redmine3.0は200万チケットで“サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 10万 20万 30万 50万 70万 100万 150万 200万チケット表示（小）チケット表示（大）チケット表示（中）チケット一覧プロジェクトTop プロジェクト一覧 RedmineTop ms 全文検索 20秒対策必須 MySQL 5.6, Postgres9.4に対策有り(BufferPool Dump/Restore) DB始動時の暖機運転5分 BufferPool 8GB必須

109. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 計測 - 定量化手法｢測定できないものは制御できない｣* １．テスト実行時間（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）・Chrome開発者ツール https://developer.chrome.com/devtools 109* DeMarco, Tom., 1982, “You can’t control what you can't measure.”

110. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１）【性能】全体がひどく遅い 110 【チューニング要素】・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub

111. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１）【性能】全体がひどく遅い 111 【チューニング要素】・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub １）Memory できるだけ多く２）Disk I/O HDD→ SSD ３）CPU はコア数＝同時接続数４）OSは５万件までWindowsでも可。早めの引越を推奨 Linuxでは200万件まで確認済５）DBMSは MySQL, Postgresql を使用し、必ず設定値を変更。 Sqliteは× ６）Apache等の通信データ圧縮を行う。ネットワーク帯域が狭い時やトラフィック輻輳の時に高い効果が得られる。

112. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１）【性能】全体がひどく遅い 112 【チューニング要素】・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub ７）Rubyは利用可能な最新版を使用 1.9 < 2.0 <<< 2.1 < 2.2 ８）WEBrick <<< Thin < Passenger4 < Passenger5 （Unicornは未調査。速い。しかし扱い易さの点で不採用）９）ネットワーク通信経路上の狭帯域を無くす。 10M/bps → 1G/bps (ケーブル＋Switch機器を交換) 10）ネットワーク通信経路上の低速パケットスイッチングを無くす。（Normal-HubをSwitchへ交換）

113. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１）【性能】全体がひどく遅い 113 【チューニング要素】・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub １１）Windows Bitnami ボトルネックは a)Ruby2.0系 → Updateを待つ b)MySQLの32bit、 → メモリ制限。Updateは期待薄設定値を２ヶ所書き換えれば、３万件までサクサク c)Thin 2スレッド → CPUコア数に空きがあれば設定可能１２）Windows スクラッチボトルネックは、Ruby、Thin。それ以外は何とかなる。（何かと制約が多く、手間が掛かって辛い)

114. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例２）【性能】リポジトリタブが遅い 114 【チューニング要素】・H/W: HDD, Memory, CPU ・S/W: DBMS, Ruby, WebAppServer, Subversion Server ・N/W: 通信帯域, Switching-Hub １）Post-CommitでプロジェクトID指定 Subversion ServerとRedmineの同期を、特定のProjectのみ実施２）Subversion をVersion Upし、セッションキャッシュメモリを付与する。（Subversion 1.7 以降）３）Subversion をVersion Upし、通信内容の圧縮機能を使用する

115. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例２）【性能】リポジトリタブが遅い 115 【チューニング要素】・H/W: HDD, Memory, CPU ・S/W: DBMS, Ruby, WebAppServer, Subversion Server ・N/W: 通信帯域, Switching-Hub ４）リビジョン数が多い時や、バイナリファイル(Excel, Word)の履歴が多い場合、Subversion ServerをLinuxで構築する。（できればSSDを使用する）５）通信帯域を広くする。６）Redmine側 MySQL テーブル更新が遅い７）DBMSメモリチューニングを行う。

116. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例３）【性能】検索が遅い 116 １）MySQLメモリチューニング全インデックス、全データをオンメモリにする。２）カスタムフィールドの設定「フィルタとして使う」の数が多いと極端に性能が落ちる３）FTS (Full Text Search) ・RedmineはWYSIWYGデザイン。・全プロジェクト横断検索は全走査型の検索方式なので、処理負荷は線形増加（Redmineコアが抱える性能上の課題）【チューニング要素】・H/W: Memory, CPU ・S/W: DBMS、

117. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例４）【性能】画面応答が遅い 117 - Rubyのバージョン処理性能は 2.2 > 2.1 >>> 2.0 >> 1.9 > 1.8 - MySQLメモリチューニング（全インデックスと主要データをオンメモリ化） - 初回アクセスが極端に遅い, MySQL 5.6のBP Save and Load. - 同時並行処理イス取りゲーム. bitnami はイス２つしかない。 - マルチスレッド対応 (Redmineは3.0からMT対応。並列処理性能が ○○％向上) - メール送信（Async） - Pluginは割り込み処理。多ければその分遅くなる。応答性能まで考慮されているPluginはそう多くない。 - Network (通信圧縮 10分の1) 【チューニング要素】・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub

118. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例５）【性能】特定プラグインが遅い 118 【チューニング要素】・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer - 多くのプラグインは大量のデータ処理を想定していない。極端に遅い場合はチューニングを施し、作者にパッチを送付できる。処理遅延の原因は、SQL／コード実装／データ設計の３系統にを大別できる。 SQLとコード実装は何とか対処もできるが、データ設計は大がかりな変更を伴うので、テストコードが無ければ諦める。 - 例）Work Time 10倍速（１画面 10秒 → 1秒）以下にご紹介する方法は、一般的なWebアプリケーションのデバッグ手法に過ぎない。 SQL実行計画の調査方法はDBMS製品毎に異なるが、類似機能は必ず存在する。 https://bitbucket.org/tkusukawa/redmine_work_time/pull-request/17 【SQL調査手順】【アプリコード調査手順】（今回は実施せず）【データ設計調査手順】（今回は実施せず）

119. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例６）【安定性】不安定で手間がかかる 119 - 3歩遅れ - 枯れた技術 - Linux OS >>> Windows (両方面倒を見てきたが、Ruby, Rails はWindowsで制限が多い印象) - 環境を並立させて、差替える - OSS パッチの取込み：多くの場合、性能が改善されている。 Git 追跡ブランチモードで、Local変更との共存【チューニング要素】・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer

120. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例７）【信頼性】エラー、事故が多い 120 - Exception Redirect mail 通知による、不具合検出 - Redmine本体、Railsにはほぼ手を入れない。 - Pluginは殆ど採用していない。管理用のみ。RedmineコアのUpdate負担に。 - 完全なクローン環境を常設（ゴミデータ、評価用データを本番に持ち込ませない）

121. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例８）【性能】電算機のH/W資源不足 121 - 1VMに集約し、狭帯域通信を回避 - CPU キャッシュの大きなものを複数コア。SBSは 4コア。同時接続数に合わせる。 - メモリできるだけ積み込む。 SBSは8GB - SSDで稼働（Muninのグラフ変化） http://172.29.224.129/munin/disk-year.html

123. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１０）【性能】起動が遅い 123 ＜DBMSの起動・再起動直後、初回アクセスだけが極端に遅い＞ - DBMSサーバーの起動、再起動時は「暖機運転」が必要 - 「暖機運転」とは、DBMS再起動後にデータやインデックスをメモリ上へ読み込む一連の処理。対象となるデータが増えると、長時間かかるようになる。 - MySQL5.6系warm up 、Postgresql 9.4系pg_prewarmとして実装されたBufferPool、Workloadの保存・読込機能によって待ち時間が大幅に短縮される。

124. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例１）基本S/W 124 OS, FileSystem ＜OS＞ CentOS 6 プロセス、パッケージは必要最低限に削ぎ落とす。（パッチ適用、最少の停止頻度、セキュリティー、メモリ）＜FS＞ Ext4 nobarrier チューン http://goo.gl/LYwfA0 /dev/mapper/vg_sms01-lv_root / ext4 defaults,nobarrier 1 1 UUID=f94716b2-52d4-4e81-9a82-3c4b13608671 /boot ext4 defaults 1 2 /dev/mapper/vg_sms01ex-lv_opt /opt ext4 defaults,nobarrier 1 2 /dev/mapper/vg_sms01-lv_swap swap swap defaults,nobarrier,discard 0 0

125. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例２）ミドルウェア 125 DBMS, WebServer, Web Application Server ＜DBMS＞メモリチューニング（MySQL 5.5, 5.6用、Postgresql） SSDによるI/O改善 200万チケットのDBダンプリストア。SSDが33％向上（5 分速く終わる）＜WebServer＞ - 通信圧縮 Compress, Gzip, Deflate 圧縮＜Web Application Server＞ - weblick は性能 × - 運用の容易さは Unicorn <<<< Passenger 。決定的な違い。 - Phusion Passenger 3 → 4 → 5 で○○％向上 - Passenger 5 で OOGBC を動作させられなかった。Exceptionが出る。 → 現状、Passenger4, Ruby2.1, OOGBC(gctools)が最速・安定 - Enterprise の MTモードで○○％向上(?) Licenseは 5000円／月程度

126. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例３）応用S/W 126 Ruby, OOBGC, Redmine, VCS ＜Ruby＞ - GCの大幅改善により、2.2系が最速と思われがちだが、次点。 2.1系＋OOBGCが最速。（調査時点 2015/05/07 ） - OOBW-GC、OOBGC の問題が付いてくる。Ruby2.2が総合的に見て最適。＜Rails＞ - Rails4の性能向上効果（ホントに向上している？）＜Redmine＞ - カスタムフィールドの設定値「フィルタとして使う」の数を減らす。「14万チケットだと、フィルタ30種 ○○秒 → フィルタ 5種〇秒」 - メール非同期送信(Async) ＜VCS＞ - Subversion 1.7のセッションキャッシュ付与機能 - Subversion 1.xの通信圧縮機能

129. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話ししたこと 129 １）200万チケットでもサクサク動くRedmineの全レシピ →詳細設定は後日、Slideshareで公開します２）Redmine2.6 を 3.0 へUpdateすると平均で7.4％速くなる３）Redmine3.0で、Ruby2.0 を 2.2 へUpdateすると平均で20.8％速くなる

130. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話ししたこと 130 １）200万チケットでもサクサク動くRedmineの全レシピ →詳細設定は後日、Slideshareで公開します２）Redmine2.6 を 3.0 へUpdateすると平均で7.4％速くなる３）Redmine3.0で、Ruby2.0 を 2.2 へUpdateすると平均で20.8％速くなる４）HDDをSSDに変更すると平均で25.7％速くなる５）Redmineチューニング事例 10種６）全走査型の全文検索は10万チケットで性能限界に到達する

131. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved まとめ｜実際 131 （難易度又は、データ規模順で解説します）・初期値のままでは1万件で使い物にならなくなる。・最低限のチューニングで 5万件まで使える。（Windows Bitnami）・最低限のチューニングで10万件まで使える。（Linux,MySQLorPostgresql）・目一杯のチューニングで 200万件まで使える。（Linux,MySQLorPostgresql）・最大限のチューニングは忙しいのでやっていない。（Linux, MySQL or Postgresql：ロードバランサ＋WebAppServerクラスタリング＋ DBMS- R/W、R/O分離＋ SSD PCIe ）

132. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved まとめ｜限界 132 1. Redmineの機能強化 → CPU, SSD, Ruby, Railsによる性能向上分を消費した。有効な策はRedmineコアの内部 2. RedmineのFTS → 10万件の時点で極めて遅く、同時並行検索（コア数＝並行数）だけでRedmineはフリーズする。制限をかける方法は無い。抜本対策が無ければ、 Redmineを使い続ける事が難しくなってしまう。 3. JPLが Proof of Conceptを終えているという爆速検索（数ms）が頼みの綱。恐らく、Postgresql 9.3の Materialized View を使用し、act_as_searchable を数十行書き換えることで実現するアイデアと思われる。

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

Kuniharu AKAHANE

Transcript