Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Download:
* Setting_paramaters_for_Redmine_Performance_Tuning.txt
https://gist.github.com/akahane92/771f9a52d81af9864dd8
* Slide PDF
https://goo.gl/EWLRkW

More Decks by Kuniharu, AKAHANE (赤羽根/州晴)

Other Decks in Technology

Transcript

  1. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    Redmineチューニングの
    実際と限界
    〜200万チケットでもサクサクなRedmineの作り方〜
    第1版 2015年5月16日 第 8回 Redmine.Tokyo
    第2版 2016年3月 5日 第14回 RxTstudy
    第3版 2017年8月26日 第17回 Redmine大阪
    第4版 2019年3月 9日 第19回 Redmine大阪
    株式会社島津ビジネスシステムズ
    赤羽根 州晴 [email protected]

    View full-size slide

  2. ありがとう。
    Thanks a lot.
    Danke schön.
    Merci beaucoup.
    2

    View full-size slide

  3. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    話者紹介
    赤羽根 州晴(@akahane92)
    島津製作所 業務系システム子会社
    ・ソフトウェア開発技術者
    ・内部統制
    ・基盤技術標準化
    ・装置開発支援 (現在)
    3
    社外活動 (運営に関与)
    ・Redmine大阪
    社外発表
    ・2013 JaSST関西 経験発表
    ・2014 SQiP 経験論文(査読付)
    ・2016 IPA/SEC 事例論文(査読付)
    書籍
    ・2015 Redmine実践ガイド(寄稿著者)

    View full-size slide

  4. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ソフトウェア品質シンポジウム 2014 経験論文
    4
    このシンポジウムは35年の歴史を持ち、
    ソフトウェア品質に関しては国内最長
    https://www.juse.jp/sqip/symposium/archive
    /2014/day2/files/ronbun_A3-4.pdf

    View full-size slide

  5. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    IPA/SEC 先進的設計・検証技術 2016 事例論文
    5
    独立行政法人情報処理推進機構
    ソフトウェア高信頼化センター
    「先進的な設計・検証技術の適用事例報告
    書 2016年度版」に採録公開(予定)
    ~IoT時代を見据えたソフトウェア開発の
    信頼性確保を実現したベストプラクティス
    の事例を紹介~
    2016年度 公開資料
    https://www.ipa.go.jp/sec/reports/201
    70302.html

    View full-size slide

  6. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    お話しすること
    6
    1)200万チケットでもサクサク動くRedmineの全レシピ*
    2)Redmine 2.6 を 4.0 へUpdateすると平均で○○%
    速くなる
    3)Ruby2.2 を 2.5, 2.6 へUpdateすると平均で○○%
    速くなる
    4)HDDをSSDにすると環境により平均で○○%
    速くなる
    5)非索引型の全文検索は○○~○○万チケットで性能限界に到達
    するが、Fulltext-Search-Plugin の導入によって○○倍速くなり、
    200万チケットの環境では平均○○秒で全文検索できる
    6)Redmine全文検索の機能の追加開発とオープンソース化
    7) Redmineチューニング事例 9種
    *全レシピ: 設定値の一括ダウンロードはこちら (GitHub Gist)
    Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt
    https://gist.github.com/akahane92/771f9a52d81af9864dd8

    View full-size slide

  7. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    お話ししないこと
    7
    1)大規模な並列トランザクション
    2)DBMSチューニングの秘境探索

    View full-size slide

  8. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ご注意
    8
    本発表の内容には様々な設定が含まれていますが、
    ご利用は自己責任でお願い致します。
    参考になさった場合に生じたいかなる損害も補償できません。
    あらかじめご了承下さい。

    View full-size slide

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

    View full-size slide

  10. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    目次
    10
    第1部 背景と要求
    第2部 チューニングの基本
    第3部 ベンチマーク
    第4部 全文検索機能の拡張
    第5部 性能改善事例集
    第6部 まとめ
    10

    View full-size slide

  11. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    株式会社 島津製作所
    2018年3月31日現在
    創 業|
    設 立|
    資 本 金|
    従 業 員 数 |
    3,765億円 (2018年3月期)
    グループ売上高|
    社 是|科学技術で社会に貢献する
    経営理念|「人と地球の健康」への願いを実現する
    11
    11,954名 (連結)
    明治8(1875)年
    大正6(1917)年
    約266億円

    View full-size slide

  12. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事業領域
    産業機器
    航空機器
    医用機器
    分析・計測機器
    12

    View full-size slide

  13. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    課題管理システム(ITS; Issue Tracking System)
    1. 研究開発型の製造業における製品・システムの開発・保守の現場では、大
    量の情報と知識を多人数で共有し、長期間にわたって扱っていかなければ
    ならない。しかし、その実現と維持は容易でなく「忘却、変容、誤認、抜け
    漏れ」が生じて効率と品質が低下する原因の一つとなっている。
    2. 数多くの人が円滑に協業するには、大量の情報と知識をうまく扱うた
    めの専用の仕組みが必要となる。どのように情報と知識を扱えば人間
    の有限能力を補完・支援して効率を向上させ、本来なすべき「思考と
    創発」に専念できるのか。
    3. 島津製作所と島津ビジネスシステムズでは、課題管理システム(ITS)と
    改版・構成管理システム(VCS)を中心とした製品開発関連情報の知識基
    盤を現場に定着させることで問題を軽減すべく、関連部門に広く導入
    して利用している。
    13
    事例要約

    View full-size slide

  14. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    【問題】装置、ソフトウェアといった製品開発と保守の現場で
    は、製品数の増加や特注品・顧客別派生品といった保守対象の
    累積や、第三者検証への対応工数の増加に悩まされている。
    【原因】製品種類と関係者数の増加、保守対象規模の拡大に対
    して、組織内情報流通の導線設計、及び開発関連情報の知識基
    盤整備が追いついていない。
    【対策】製品開発に関連する情報の知識基盤を整備し、組織内
    情報流通の導線設計を実現するOSSツールセットを2009年に
    導入した。
    【結果】製品開発・保守業務の効率と品質の向上、第三者検証
    に役立つ追跡可能性の水準向上といった改善効果を得た。
    14
    事例要点

    View full-size slide

  15. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例
    15
    島津製作所グループ
    業務システム
    情報系
    子会社
    委託
    IT全般統制
    ISO
    内部統制
    省庁監査

    View full-size slide

  16. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例
    16
    島津製作所グループ
    業務システム
    情報系
    子会社
    委託
    IT全般統制
    ISO
    内部統制
    省庁監査
    複数の統制・認証に対応
    大量の記録が必要

    View full-size slide

  17. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|背景モデル
    17
    要 件 結 果
    業務用ITシステムの全般的な管理記録は
    内部統制や各種認証(ISO, ISMS, 省庁監査)の
    要求に答えなければならない
    •記録と整合
    •精査と承認
    •追跡可能性
    •目的合理性
    •品質管理
    •セキュリティー

    View full-size slide

  18. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|背景モデル
    18
    課題 3 課題・要望
    問合せ受付
    調査と確認
    状況報告
    方針決定
    対処と確認
    結果報告


    課題 2 変更
    問合せ受付
    調査と確認
    状況報告
    方針決定
    対処と確認
    結果報告


    課題 1 トラブル
    問合せ受付
    調査と確認
    状況報告
    方針決定
    対処と確認
    結果報告


    複数
    ユーザー
    複数
    ユーザー
    複数
    ユーザー
    複数
    ユーザー
    複数
    ユーザー
    複数
    担当者
    C事業部
    B事業部
    A事業部 X System
    Y System
    Z System
    関係者増加 / 事案多様化/システム増加・分散
    m : n : i

    View full-size slide

  19. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|業務システムの運営状況
    19
    業務システム
    100種
    利用者
    7000人
    事案
    56000件
    改版(コミット)
    20000回
    1700
    KLOC
    開発運用
    200人
    /年
    /年
    /年
    自動生成コード含む
    7~20年超

    View full-size slide

  20. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|現象と問題の要約(8種)
    20
    # 現象 問題
    1 人の記憶が頼り「生き字引き」 記憶は不確かで、容易に消滅
    2 開発作業単位ごとの管理で情報が「お蔵入り」 再利用が難しく作業コストが回収困難
    3 詳細な経緯や背景は担当者のMail-Boxに埋没 検索できず、異動や離職で消滅
    4 製品構成や、組織の壁が情報流通を阻害 情報の共有不足で不具合、障害が増加
    5 外部委託契約の長期化。担当者間の引継ぎ不足 実装・変更の経緯が不明
    後任の保守効率が低下
    6 記録の分散により、情報の横断検索が困難 仕様変更のインパクト分析が困難
    過去経緯の不明が品質低下の温床
    7 Excelなどの汎用媒体だけでは業務を表現できない 情報の欠落、業務効率の低下
    8 製品を取り巻く規制の強化によって統制・
    監査・査察の対応負担の増大が予想される
    業務効率の低下、コストの上昇
    製品・システム開発保守の現場は、さまざまな問題に悩まされている

    View full-size slide

  21. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|解決策
    21
    統合管理
    全面導入
    Issue
    Tracking
    System

    View full-size slide

  22. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|知識基盤 (情報容器=チケット)
    22
    作成者
    担当者
    関係者
    経緯
    意志決定
    履歴
    資料
    成果物
    チケット
    1チケット ≒ 1クリアフォルダ

    View full-size slide

  23. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|事案関係モデル
    5.6万件/年
    2万コミット/年
    /年
    関係性
    23
    記憶の消滅
    ×
    二次元 Excel 表現できる…何か

    View full-size slide

  24. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|事案関係モデル
    5.6万件/年
    2万コミット/年
    /年
    関係性
    24
    記憶の消滅
    二次元 Excel ITS
    ×

    View full-size slide

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

    View full-size slide

  26. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|放置チケット対策の定着
    26
    週次ミーティングで、
    積極的にチケット完了
    ITSを使った会議

    View full-size slide

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












    Project数 200
    User数 488
    調査日 2019/1
    0
    50
    100
    150
    200
    250
    300
    350
    400
    450
    500
    0
    50
    100
    150
    200
    250
    2010 2011 2012 2013 2014 2015 2016 2017 2018
    プロジェクト数 ITSユーザー数
    事例|プロジェクト、ユーザー数の経年変化

    View full-size slide

  28. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    10
    20
    30
    40
    50
    60
    70
    80
    90
    100
    0
    10,000
    20,000
    30,000
    40,000
    50,000
    60,000
    2010 2011 2012 2013 2014 2015 2016 2017 2018
    Ticket発行数 完了率 近似曲線(線形)
    事例|チケットの発行数と完了率
    28
    調査日 2019/1
    完了率 87%
    → 93%
    累計 34万件 55,800/年 4,600/月











    View full-size slide

  29. 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 2015 2016 2017 2018


















    6ヶ月以上
    6ヶ月
    3ヶ月
    1ヶ月
    2週間
    1週間
    1日
    平均完了日数
    事例|完了所要日数の分布と平均
    調査日 2019/1

    2012年 84日
    2015年 51日
    2018年 24日

    View full-size slide

  30. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    100
    200
    300
    400
    500
    600
    700
    800
    900
    1,000
    0
    10,000
    20,000
    30,000
    40,000
    50,000
    60,000
    2010 2011 2012 2013 2014 2015 2016 2017 2018
    チケット発行数 説明欄文字数(平均) 近似曲線(線形)
    事例|チケット説明欄の文字数変化
    30
    2011年
    529文字
    2018年
    725文字
    調査日 2019/1
    累計 2016年 2億7千万文字
    2018年 3億6千万文字
    文字


















    View full-size slide

  31. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    0.2
    0.4
    0.6
    0.8
    1
    1.2
    1.4
    0
    10,000
    20,000
    30,000
    40,000
    50,000
    60,000
    70,000
    2010 2011 2012 2013 2014 2015 2016 2017 2018
    チケット発行数 添付ファイル数
    事例|添付ファイル数の経年変化
    31
    ファイル
    調査日 2019/1
    累積 2017年 26万3千 ファイル
    2018年 35万8千 ファイル チ



























    View full-size slide

  32. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|チケット関係性の経年変化
    32
    関係性カウント
    線をカウントする
    例)3カウント
    Ticket
    Ticket
    Ticket
    Ticket
    関係記録数
    2011年 11%
    2018年 23%
    調査日 2019/1
    0%
    5%
    10%
    15%
    20%
    25%
    30%
    0
    5
    10
    15
    20
    25
    30
    35
    40
    2010 2011 2012 2013 2014 2015 2016 2017 2018
























    チケット発行数累計 関係数累計 関係保持割合 線形 (関係保持割合)

    View full-size slide

  33. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    20
    40
    60
    80
    100
    120
    140
    160
    180
    200
    0
    500
    1,000
    1,500
    2,000
    2,500
    3,000
    3,500
    4,000
    4,500
    2010 2011 2012 2013 2014 2015 2016 2017 2018


















    障害・バグチケット数
    完了所要日数平均
    事例|障害・バグチケット数と完了所要日数の平均
    33
    調査日 2019/1

    所要日数平均
    2011年
    172日
    2015年
    86日
    2018年
    27日
    2011年
    No Ticket,
    No Commit
    開始

    View full-size slide

  34. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    20
    40
    60
    80
    100
    120
    140
    0
    10,000
    20,000
    30,000
    40,000
    50,000
    60,000
    2011 2012 2013 2014 2015 2016 2017 2018


















    チケット発行数
    障害・バグチケット発行数
    障害・バグチケット密度
    障害・バグチケット密度
    (Spike除去)
    線形 (障害・バグチケット密度
    (Spike除去))
    事例|「障害・バグ」チケット密度
    34
    2012年
    94件/KT
    2018年
    44件/KT
    調査日 2019/1
    件/KT
    (Kilo Ticket)

    View full-size slide

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

    View full-size slide

  36. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|まとめ
    36
    統制実現
    コスト低減
    属人性軽減
    品質, CS向上
    業績貢献
    【経営要求】
    【現場要求】
    現業務を表現可能
    入力コストに見合う
    いつでもどこでも
    素早く見つかる
    休みやすい
    【管理手法】
    【統制要求】
    IT全般統制
    ISO
    省庁監査
    一意識別

    関連維持

    追跡可能

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

    View full-size slide

  37. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例|まとめ
    37
    1)100種の業務システムを200人が運用する現場
    2)IT統制に対応するため高水準の管理品質を維持
    網羅性は必達(全員が全情報を入力し続ける)
    3)文房具:常にサクサクの応答性能と盤石な安定性
    4)運営のための余力は皆無。省力化の徹底と、
    安定性・信頼性の同時成立が不可欠

    View full-size slide

  38. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    目次
    38
    第1部 背景と要求
    第2部 チューニングの基本
    第3部 ベンチマーク
    第4部 全文検索機能の拡張
    第5部 性能改善事例集
    第6部 まとめ
    38

    View full-size slide

  39. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    チューニングの基本
    39
    図引用元: http://ja.wikipedia.org/wiki/ボトルネック概念図.png
    電子計算機
    ネットワークシステム
    ボトルネックの
    発見と解消

    View full-size slide

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

    View full-size slide

  41. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    チューニングの基本
     対策1 狭帯域通信を避ける
    41
    Ethernet等の
    低速通信
    2M
    , 10M
    , 100Mbit / 秒
    経路上の最も狭い帯域

    View full-size slide

  42. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    Local Loopback adapter
    同一OS内のTCP/ UDP/ Socket 通信
    チューニングの基本
     対策1 狭帯域通信を避ける
    42
    狭帯域
    6→3

    View full-size slide

  43. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    チューニングの基本
     対策2 情報量の圧縮
    43
    HTTP/1.1 Compression
    情報量 1/4 ~ 1/10
    最大10倍速

    View full-size slide

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

    View full-size slide

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










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

    View full-size slide

  46. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    チューニングの基本
     対策4 永続化
    46
    * 情報の永続化 「電源をOFFにしてもデータが消えないようにすること」
    Server
    Pass
    enge
    r
    RAID
    OS FS NW
    Ruby
    Rails
    Redmine
    DBMS
    HTTP
    Reverse
    Proxy
    情報の永続化*
    SSDの登場
    劇的な速度向上

    View full-size slide

  47. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    チューニングの基本
     対策5 算法選択による計算量削減
    47
    算法の選択による
    速度向上*
    Sort, GC, Index
    * 算法の変更によって計算処理量を減らし、より少ない時間で同一の処理を実施する
    Server
    Pass
    enge
    r
    RAID
    OS FS NW
    Ruby
    Rails
    Redmine
    DBMS
    HTTP
    Reverse
    Proxy

    View full-size slide

  48. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    チューニングの基本
     チューニング要点
    48
    Passenger6.0
    OS CentOS7 (64bit)
    Ruby 2.6
    Rails5.2
    Redmine 4.0
    DBMS
    MySQL
    5.7
    HTTP
    Apache
    2.4
    Memory 4〜16GB
    CPU 4〜6 Cores
    VMware (可用性、信頼性)
    VCS
    Subversion
    1.9
    HTTP
    Reverse
    Proxy
    ---
    :8 Key Points
    Network

    View full-size slide

  49. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    チューニングの基本
     チューニング要点
    49
    Passenger6.0
    OS CentOS7 (64bit)
    Ruby 2.6
    Rails5.2
    Redmine 4.0
    DBMS
    MySQL
    5.7
    HTTP
    Apache
    2.4
    Memory 4〜16GB
    CPU 4〜6 Cores
    VMware (可用性、信頼性)
    VCS
    Subversion
    1.9
    HTTP
    Reverse
    Proxy
    ---
    :8 Key Points
    Network
    Redmine本体は変更しない
    安定、安全、信頼

    View full-size slide

  50. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    目次
    50
    第1部 背景と要求
    第2部 チューニングの基本
    第3部 ベンチマーク
    第4部 全文検索機能の拡張
    第5部 性能改善事例集
    第6部 まとめ
    50

    View full-size slide

  51. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク
    51
    【背景】
    ・年間50,000チケット以上を起票
    ・業務の中心にITS(Redmine)
    ・処理遅延や障害停止の回避は必須要件
    【2012年10月】
    ・ITSの業務活用が急拡大(10万チケット越)
    ・200万チケットまでの動作を先行して確認
    ・問題を洗い出して対策
    【2015年5月、2016年3月、2017年8月、 2019年1月】
    ・2012年の予測値と、最新の実績値を比較
    ・Redmine, Ruby, Rails, H/Wの変化
    ・再度、性能ベンチマークを計測して最適解を選ぶ

    View full-size slide

  52. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク
    52
    “サクサク”の
    基準

    View full-size slide

  53. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク
    53
    画面応答時間の基準*とは?
    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

    View full-size slide

  54. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク
    54
    画面応答時間の基準*とは?
    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は文房具

    View full-size slide

  55. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク
    55
    実績値

    View full-size slide

  56. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|実績値
    56
    Redmine月間アクセス数*の経年変化
    * 9年分のApache アクセスログに記載されたURI - 2019年1月
    累計:2800万 月間:42万アクセス
    調査日 2019/1
    0
    500
    1,000
    1,500
    2,000
    2,500
    3,000
    0
    10
    20
    30
    40
    50
    2009 2010 2011 2012 2013 2014 2015 2016 2017 2018


    月平均 アクセス数累計














    View full-size slide

  57. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|実績値 2017
    8年間の運用結果*を集計
    57
    統計要約
    最小値 : 1
    第1四分位点 : 73
    中央値 : 193
    平均値 : 396
    第3四分位点 : 317
    最大値 :9562551
    100ms
    31%
    200ms
    20%
    300ms
    21%
    400ms
    10%
    500ms
    600ms
    700ms
    800ms
    900ms
    1000ms
    1000ms超
    5%
    100ms
    200ms
    300ms
    400ms
    500ms
    600ms
    700ms
    800ms
    900ms
    1000ms
    1000ms超
    * 8年分のProduction.logに記載された処理応答時間 (Redmine <-> DB) - 2017年8月
    調査日 2017/8
    ・1443万回の処理
    ・半分が200ms以下
    ・95% が1秒以下
    ・中央値193ms(median)

    View full-size slide

  58. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    100ms
    49%
    200ms
    21%
    300ms
    13%
    400ms
    6%
    500ms
    600ms
    700ms
    800ms 900ms 1000ms 1000ms超
    3%
    100ms
    200ms
    300ms
    400ms
    500ms
    600ms
    700ms
    800ms
    900ms
    1000ms
    1000ms超
    ベンチマーク|実績値 2019
    9年間の運用結果*を集計
    58
    統計要約
    最小値 : 0
    第1四分位点 : 35
    中央値 : 112
    平均値 : 295
    第3四分位点 : 239
    最大値 :9562551
    ・2365万回の処理
    ・半分が100ms以下
    ・97% が1秒以下
    ・中央値112ms(median)
    * 9年分のProduction.logに記載された処理応答時間 (Redmine <-> DB) - 2019年1月
    調査日 2019/1

    View full-size slide

  59. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|評価対象
    9年間の運用結果*を集計し、主要画面を決定
    59
    ・2800万アクセス(28M)
    ・■チケット表示 +
    ■チケット一覧で49%
    ・利用頻度、遅延
    を体感しやすい画面
    調査日 2019/1
    * 9年分のApache アクセスログに記載されたITSのURI - 2019年1月
    33%
    16%
    7%
    4%
    4%
    4%
    4%
    3%
    3%
    3%
    2%
    2%
    2%
    1%
    1% 11%
    2800万アクセス:ベンチマーク対象
    チケット表示
    チケット一覧
    Wikiページ
    プロジェクトTop
    (Work_Time)
    (Redmine_Draft)
    検索
    添付ダウンロード
    添付画像サムネイル
    ログイン画面
    マイページ
    時間入力
    RedmineTop
    リポジトリ閲覧
    チケットプレビュー
    その他

    View full-size slide

  60. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|評価対象
    9年間の運用結果*を集計し、主要画面を決定
    60
    ・2800万アクセス(28M)
    ・■チケット表示 +
    ■チケット一覧で49%
    ・利用頻度、遅延
    を体感しやすい画面
    ・ベンチマーク対象が
    全体の65.0%
    を網羅
    調査日 2019/1
    * 9年分のApache アクセスログに記載されたITSのURI - 2019年1月
    33%
    16%
    7%
    4%
    4%
    4%
    3%
    3%
    2%
    2%
    2%1%
    1%
    11%
    2800万アクセス:ベンチマーク対象
    チケット表示
    チケット一覧
    Wikiページ
    プロジェクトTop
    (Work_Time)
    (Redmine_Draft)
    検索
    添付ダウンロード
    添付画像サムネイル
    ログイン画面
    マイページ
    時間入力
    RedmineTop
    リポジトリ閲覧
    チケットプレビュー
    その他

    View full-size slide

  61. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|テストデータ*
    61
    規模
    0
    2
    4
    6
    8
    10
    12
    14
    16
    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関係性
    記録文字数
    * 実データ10万チケットを複写して製作
    200万チケットは
    ・3000万レコード
    ・14億9000万文字
    調査日 2019/1
    カスタムフィールドは
    77種に固定

    View full-size slide

  62. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|テストデータ*
    62
    200万チケットの内訳
    種類 件数
    チケット数 200万
    カスタムField値 1,200万
    添付ファイル 140万
    時間記録 74万
    注記欄 363万
    ウォッチャー数 76万
    Ticket間 参照数 27万
    記録文字数 14億9,000万
    プロジェクト数 113
    ユーザー数 457
    * 実データ10万チケットを複写して製作
    調査日 2019/1

    View full-size slide

  63. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測方法
    63
    Ruby OOBGC * Redmine
    Ruby 2.0 2016/2/24 EOL Normal 2.6 3.0 3.1 3.2 3.3 3.4
    Ruby 2.1 2017/3/31 EOL Normal / OOBGC 2.6 3.0 3.1 3.2 3.3 3.4
    Ruby 2.2 2018/3/31 EOL Normal / OOBGC 2.6 3.0 3.1 3.2 3.3 3.4 4.0
    Ruby 2.3 2019/3/31 EOL予定
    Normal / OOBGC 3.3 3.4 4.0
    Ruby 2.4 Normal 3.4 4.0
    Ruby 2.5 Normal 4.0
    Ruby 2.6 Normal 4.0
    組合せ
    * OOBGC; Out Of Band Garbage Collection。Request処理中にRubyがGCを実行すると応答に遅延が生じる。
    指定回数の処理毎に、間隙を縫ってGCを実行させることで応答の遅延を軽減する機能。
    Passenger6.0
    OS CentOS7 (64bit)
    Ruby 2.6
    Rails5.2
    Redmine 4.0 DBMS
    MySQL 5.7
    (BP 8GB)
    HTTP
    Apache 2.4
    Memory 16GB
    CPU 4cores
    VMware ESXi 6.5 【CPU】Intel Xeon Gold 5118 2.3GHz x2 (24Cores/48Threads) , 【Memory】256GB,
    【SSD】1.7TB SAS RAID6, 【HDD】12TB 10K RPM SAS RAID6
    VCS
    Subversion1.9
    環境構成
    SSD/HDD NIC
    調査日 2019/1

    View full-size slide

  64. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測方法
    64
    ① 主要画面8種に対して2並列でそれぞれ10回アクセスし、これを5回繰返して計測。
    ② 上記①を、下記3種のDBキャッシュ状態を順次切り替えて計測。
    (a)DBキャッシュ無 → (b)DBキャッシュ保存・復元 → (c)Fullメモリキャッシュ
    ③ 上記②の(c)Fullメモリキャッシュの計測値を平均した値を採用。
    ④ 上記①~③を、下記要素の全組み合わせ環境で繰り返す。
    Redmineバージョン、 Rubyバージョン、OOGBC有無、
    10万~200万チケット、SSD/HDD
    10万 20万 30万 50万 70万 100万 150万 200万
    所要時間合計(ミリ秒) 687.9 691.8 810.4 821.4 833.4 865.4 875.3 884.6
    Redmine4.0
    Ruby2.5
    Passenger6.0
    MySQL5.7
    BufferPool 8G
    SSD
    主要画面8種のURI
    /its40 12.5 12.8 12.5 12.5 12.8 12.8 13 12.6
    /its40/projects 28.1 28 26.8 27.1 27.2 27.1 27.6 27.1
    /its40/projects/sscope 57 56.8 54.1 54.9 54.1 54.6 55.4 53.7
    /its40/issues?per_page=200 239 234.3 240.4 239 234.5 232.2 237.7 237.7
    /its40/issues/1 83.2 68 181.2 180.5 181.1 180.8 182.2 181.7
    /its40/issues/47548 152.9 165.7 169.4 181 198 215.3 231.8 247
    /its40/issues/51782 76.6 87.8 87.8 88.3 87.4 87.8 87.9 87.8
    /its40/projects/its-issues/wiki 38.6 38.4 38.2 38.1 38.3 38.2 39.7 37.0
    調査日 2019/1

    View full-size slide

  65. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0 1000 2000 3000 4000 5000 6000 7000 8000 9000
    Ruby2.6 nml jit on
    Ruby2.2 nml
    Ruby2.3 nml
    Ruby2.2 oobgc
    Ruby2.4 nml
    Ruby2.3 oobgc
    Ruby2.6 nml jit off
    Ruby2.5 nml
    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果1
    65
    ms
    Redmine4.0の最速ベンチ
    調査日 2019/1
    ※ Experimental

    View full-size slide

  66. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0 1000 2000 3000 4000 5000 6000 7000 8000 9000
    Ruby2.6 nml jit on
    Ruby2.2 nml
    Ruby2.3 nml
    Ruby2.2 oobgc
    Ruby2.4 nml
    Ruby2.3 oobgc
    Ruby2.6 nml jit off
    Ruby2.5 nml
    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果1
    66
    ms
    Redmine4.0の最速ベンチ
    調査日 2019/1
    ※ Experimental
    最も遅い Ruby2.2 に比して、
    最も速い Ruby2.5, 2.6 は 21.7%
    速い

    View full-size slide

  67. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    2,000
    4,000
    6,000
    8,000
    10,000
    12,000
    Redmine
    2.6
    Redmine
    3.0
    Redmine
    3.1
    Redmine
    3.2
    Redmine
    3.3
    Redmine
    3.4
    Redmine
    4.0
    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果2
    67
    ms
    Redmine4.0は速いのか
    調査日 2019/1
    ・性能向上(平均)
    2.6 → 4.0 29% up
    3.0 → 4.0 24% up
    3.1 → 4.0 26% up
    3.2 → 4.0 29% up
    3.3 → 4.0 27% up
    3.4 → 4.0 10% up
    ・原因推測
    + Redmine4.0
    + Ruby2.5, 2.6
    - 機能増加

    View full-size slide

  68. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    2,000
    4,000
    6,000
    8,000
    10,000
    12,000
    Redmine
    2.6
    Redmine
    3.0
    Redmine
    3.1
    Redmine
    3.2
    Redmine
    3.3
    Redmine
    3.4
    Redmine
    4.0
    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果2
    68
    ms
    Redmine4.0は速いのか
    調査日 2019/1
    ・性能向上(平均)
    2.6 → 4.0 29% up
    3.0 → 4.0 24% up
    3.1 → 4.0 26% up
    3.2 → 4.0 29% up
    3.3 → 4.0 27% up
    3.4 → 4.0 10% up
    ・原因推測
    + Redmine4.0
    + Ruby2.5, 2.6
    - 機能増加
    Redmine2.6/3.2から4.0へアップデートする
    と、平均で29%
    の性能向上が得られる

    View full-size slide

  69. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    2,000
    4,000
    6,000
    8,000
    10,000
    12,000
    Ruby2.6
    nml jit on
    Ruby2.2
    nml
    Ruby2.3
    nml
    Ruby2.2
    oobgc
    Ruby2.4
    nml
    Ruby2.3
    oobgc
    Ruby2.6
    nml jit off
    Ruby2.5
    nml
    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果3
    69
    Rubyバージョン変更の効果
    ms
    調査日 2019/1
    Redmine4.0
    ※ Experimental
    Ruby2.0
    nml
    Ruby2.1
    nml
    Ruby2.2
    nml
    Ruby2.3
    nml
    Ruby2.1
    oobgc
    Ruby2.4
    nml
    Ruby2.2
    oobgc
    Ruby2.3
    oobgc
    Redmine3.4
    Redmine4.0 性能向上(平均)
    Ruby2.2→2.5/2.6 21.7%
    Redmine3.4 性能向上(平均)
    Ruby2.0→2.4 35.4%
    Ruby2.0→2.3OOBGC
    37.4%

    View full-size slide

  70. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    2,000
    4,000
    6,000
    8,000
    10,000
    12,000
    Ruby2.6
    nml jit on
    Ruby2.2
    nml
    Ruby2.3
    nml
    Ruby2.2
    oobgc
    Ruby2.4
    nml
    Ruby2.3
    oobgc
    Ruby2.6
    nml jit off
    Ruby2.5
    nml
    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果3
    70
    Rubyバージョン変更の効果 調査日 2019/1
    Redmine4.0
    ※ Experimental
    Ruby2.0
    nml
    Ruby2.1
    nml
    Ruby2.2
    nml
    Ruby2.3
    nml
    Ruby2.1
    oobgc
    Ruby2.4
    nml
    Ruby2.2
    oobgc
    Ruby2.3
    oobgc
    Redmine3.4
    Redmine4.0 性能向上(平均)
    Ruby2.2→2.5 21.7%
    Redmine3.4 性能向上(平均)
    Ruby2.0→2.4 37.4%
    Ruby2.0→2.3OOBGC
    36.7%
    ※ Experimental
    Redmine4.0において、Ruby2.2から2.5/2.6へ
    Updateすると平均21.7%
    の性能向上が得られる
    ms

    View full-size slide

  71. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    2,000
    4,000
    6,000
    8,000
    10,000
    12,000
    Ruby2.0
    nml
    Ruby2.1
    nml
    Ruby2.2
    nml
    Ruby2.3
    nml
    Ruby2.1
    oobgc
    Ruby2.4
    nml
    Ruby2.2
    oobgc
    Ruby2.3
    oobgc
    ベンチマーク|計測結果3
    71
    OOBGCの効果
    71
    調査日 2019/1
    Redmine3.4 Redmine3.4 性能向上(平均)
    OOBGC効果
    Ruby2.3→2.3OOBGC
    7.3% up
    ms

    View full-size slide

  72. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    2,000
    4,000
    6,000
    8,000
    10,000
    12,000
    Ruby2.0
    nml
    Ruby2.1
    nml
    Ruby2.2
    nml
    Ruby2.3
    nml
    Ruby2.1
    oobgc
    Ruby2.4
    nml
    Ruby2.2
    oobgc
    Ruby2.3
    oobgc
    ベンチマーク|計測結果3
    72
    OOBGCの効果
    72
    調査日 2019/1
    Redmine3.4 Redmine3.4 性能向上(平均)
    OOBGC効果
    Ruby2.3→2.3OOBGC
    7.3% up
    ms
    Redmine3.4において、Ruby2.3にOOBGCを適用すると
    平均 7.3%
    の性能向上が得られる
    Redmine4.0, Ruby2.4/2.5/2.6 のOOBGCは動作せず調査はできなかった。

    View full-size slide

  73. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果4
    73
    過去のRedmineと比較
    Redmineは速くなった? 遅くなった?
    調査日 2019/1

    View full-size slide

  74. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    1000
    2000
    3000
    4000
    5000
    6000
    7000
    8000
    9000
    Redmine1.4


    Redmine2.0


    Redmine2.1


    Redmine2.3


    Redmine2.6


    Redmine3.0


    Redmine3.1


    Redmine3.2


    Redmine3.3


    Redmine3.4


    Redmine4.0


    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果4
    74
    過去のRedmineと比較 調査日 2019/1
    最速ベンチマークを
    比較すると、
    2.3 → 2.6 – 26.4%
    性能が低下している
    ms

    View full-size slide

  75. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    1000
    2000
    3000
    4000
    5000
    6000
    7000
    8000
    9000
    Redmine1.4


    Redmine2.0


    Redmine2.1


    Redmine2.3


    Redmine2.6


    Redmine3.0


    Redmine3.1


    Redmine3.2


    Redmine3.3


    Redmine3.4


    Redmine4.0


    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果4
    75
    過去のRedmineと比較 調査日 2019/1
    最速ベンチマークを
    比較すると、
    2.3 → 2.6 – 26.4%
    2.3 → 3.4 – 13.5%
    2.3 → 4.0 – 5.3%
    性能が低下している
    ms

    View full-size slide

  76. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    1000
    2000
    3000
    4000
    5000
    6000
    7000
    8000
    9000
    Redmine1.4


    Redmine2.0


    Redmine2.1


    Redmine2.3


    Redmine2.6


    Redmine3.0


    Redmine3.1


    Redmine3.2


    Redmine3.3


    Redmine3.4


    Redmine4.0


    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果4
    76
    過去のRedmineと比較 調査日 2019/1
    ms
    性能変化の原因推測
    + Redmine内部改善
    + Ruby高速化
    + Multi Thread対応
    + Rails5の内部改善
    - 機能増加
    ※ Redmine2.3以前の計測は当時の
    計算機とRuby1.8, 1.9, 2.0による
    もの。現在は電算機の能力が向上し
    ており比較精度は完全でない。よっ
    て参考値とする。

    View full-size slide

  77. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    1000
    2000
    3000
    4000
    5000
    6000
    7000
    8000
    9000
    Redmine1.4


    Redmine2.0


    Redmine2.1


    Redmine2.3


    Redmine2.6


    Redmine3.0


    Redmine3.1


    Redmine3.2


    Redmine3.3


    Redmine3.4


    Redmine4.0


    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果4
    77
    過去のRedmineと比較 調査日 2019/1
    ms
    機能増加
    Redmine
    2.3, 2.4, 2.5, 2.6, 3.0, 3.1,3.2, 3.3, 3.4, 4.0
    Spent time
    2013-03~2018-12 (5y9m)
    Includes
    374 Features implemented
    641 Patches applied
    673 Defects fixed
    Getting faster and
    remarkably reliable!

    View full-size slide

  78. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    1000
    2000
    3000
    4000
    5000
    6000
    7000
    8000
    9000
    Redmine1.4


    Redmine2.0


    Redmine2.1


    Redmine2.3


    Redmine2.6


    Redmine3.0


    Redmine3.1


    Redmine3.2


    Redmine3.3


    Redmine3.4


    Redmine4.0


    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果4
    78
    過去のRedmineと比較 調査日 2019/1
    ms
    機能増加
    Redmine
    2.3, 2.4, 2.5, 2.6, 3.0, 3.1,3.2, 3.3, 3.4, 4.0
    Spent time
    2013-03~2018-12 (5y9m)
    Includes
    374 Features implemented
    641 Patches applied
    673 Defects fixed
    Getting faster and
    remarkably reliable!
    ・Redmine2.3を4.0へUpdateすると5.3%
    性能が
    低下する
    ・数多くの有益な機能が追加されたのにも関わらず
    コア開発チームの努力と技術の進歩により、
    応答性能の低下は最小限にとどめられた

    View full-size slide

  79. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|小まとめ(1/2)
    79
    Redmine4.0の性能が改善した主な理由
    理由1:Ruby2.5, 2.6の処理性能向上
    Issue# Subject
    Ruby2.5 #14104 命令列中のすべての trace 命令を削除することで、5~10% の高速化
    #14045 Lazy Proc allocation
    #13517 Mutex がよりコンパクトかつ高速に書き直された
    -
    ERB は Ruby 2.4 に比べて 2 倍の速度でテンプレートからコードを生成するよ
    うになった
    -
    組み込みメソッドの速度が向上(Array#concat、Enumerable#sort_by、
    String#concat、String#index、Time#+)
    #13867
    IO.copy_streamがcopy_file_range(2)を使ってコピーのオフロードを試みるよ
    うになった
    Ruby2.6 #14318 Proc#callが高速化された
    #14330 渡されたブロックの呼び出し block.call が高速化された
    #14989 Transient Heap (theap) が導入された
    #14739
    コルーチンをネイティブ実装による、Fiberのコンテキスト切り替えの性能が大
    幅に向上した
    調査日 2019/1

    View full-size slide

  80. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|小まとめ(2/2)
    80
    Redmine4.0の性能が改善した主な理由
    理由2:Redmine core パフォーマンス改善10種
    Issue# Subject
    30465 Deadlock when assigning custom values
    29406 Use sorted instead of sort
    29363 Use String#tr instead of String#gsub
    29359 Switch to mini_mime from mime-types
    29305 Use Hash#each_key instead of Hash#keys.each
    29299 Use Enumerable#sort_by instead of Enumerable#sort
    28952 Update User#last_login_on only once per minute
    27671 Use reverse_each instead of reverse.each for better performance
    26747 Use find_by instead of where.first to remove unnecessary sorting
    26711 Use pluck instead of collect/map
    30465 Deadlock when assigning custom values
    調査日 2019/1

    View full-size slide

  81. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果5
    81
    今回のベンチマークはSSDで行った。
    HDDとSSDの性能差はどの程度か?

    View full-size slide

  82. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    2,000
    4,000
    6,000
    8,000
    10,000
    12,000
    NO Cache
    Redmine4.0
    HDD
    NO Cache
    Redmine4.0
    SSD
    FULL Cache
    Redmine4.0
    HDD
    FULL Cache
    Redmine4.0
    SSD
    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果5
    82
    HDDをSSDに置換する効果
    調査日 2019/1
    ms
    Redmine4.0
    HDD→ SSDの性能向上
    No Cache 28.5% avg
    Disk I/Oに依存する処理が大半を占めた時
    例)起動直後、キャッシュ未設定、メモリ不足、
    大量データなどの理由により、処理対象データを
    Diskから読込むため時間がかかる
    Full Cached 3.6% avg
    キャッシュシステムによってDisk I/Oが不
    要、または減少した処理が大半を占めた時
    例)処理対象データは既に読み込まれてメモリ上に
    プールされており、すぐに取り出せる

    View full-size slide

  83. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    2,000
    4,000
    6,000
    8,000
    10,000
    12,000
    NO Cache
    Redmine4.0
    HDD
    NO Cache
    Redmine4.0
    SSD
    FULL Cache
    Redmine4.0
    HDD
    FULL Cache
    Redmine4.0
    SSD
    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果5
    83
    HDDをSSDに置換する効果
    調査日 2019/1
    ms
    Redmine4.0
    HDD→ SSDの性能向上
    No Cache 28.5% avg
    Disk I/Oに依存する処理が大半を占めた時
    例)起動直後、キャッシュ未設定、メモリ不足、
    大量データなどの理由により、処理対象データを
    Diskから読込むため時間がかかる
    Full Cached 3.6% avg
    キャッシュシステムによってDisk I/Oが不
    要、または減少した処理が大半を占めた時
    例)処理対象データは既に読み込まれてメモリ上に
    プールされており、すぐに取り出せる
    HDDをSSDに交換すると、
    平均28.5%
    の性能向上が得られる

    View full-size slide

  84. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果6
    84
    複数プラグイン導入の性能への影響
    Redmineの性能に、プラグインがどの程度
    の影響を与えるのか?

    View full-size slide

  85. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果6
    85
    複数プラグイン導入の性能への影響
    Redmine Pluginの多くはHook
    によって各処理に割り込みをか
    けている。性能が十分に考慮さ
    れていないコードが呼び出され
    た場合、応答性能に影響する。
    選出した16種のうち8種は
    Redmine3.0に未対応だった。
    プラグインを追加して応答時間
    を計測した結果、平均4%の性能
    低下が計測された。
    0
    2000
    4000
    6000
    8000
    10000
    12000
    Redmine3.0 Redmine3.0 -
    With Plugins
    10万 20万 30万 50万 70万 100万 150万 200万
    ms
    調査日 2015/5

    View full-size slide

  86. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果6
    86
    複数プラグイン導入の性能への影響
    0
    2000
    4000
    6000
    8000
    10000
    12000
    Redmine3.0 Redmine3.0 - With
    Plugins
    10万 20万 30万 50万 70万 100万 150万 200万
    ms
    Redmine Pluginの多くはHook
    によって各処理に割り込みをか
    けている。性能が十分に考慮さ
    れていないコードが呼び出され
    た場合、応答性能に影響する。
    選出した16種のうち8種は
    Redmine3.0に未対応だった。
    プラグインを追加して応答時間
    を計測した結果、平均4%の性能
    低下が計測された。
    不要なPluginを除去することで、
    応答性能が平均4%
    向上するケースがある
    調査日 2015/5

    View full-size slide

  87. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果7
    87
    FTS* 応答性能の計測
    1. Redmine4.0の全文検索性能
    2. Full Text Searchプラグインの導入による
    高速化の程度
    3. 35万添付ファイルの内容検索の性能
    * FTS; Full Text Search 全文検索(索引型/非索引型)

    View full-size slide

  88. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    88
    Redmine Ruby OOBGC * MySQL FTS Plugin
    3.0 Ruby 2.2 2018/3/31 EOL OOBGC 5.7 -
    4.0 Ruby 2.5 (2.6) Normal 5.7 ON / OFF
    組合せ
    * OOBGC; Out Of Band Garbage Collection。Request処理中にRubyがGCを実行すると応答に遅延が生じる。
    指定回数の処理毎に、間隙を縫ってGCを実行させることで応答の遅延を軽減する機能。
    Passenger6.0
    OS CentOS7 (64bit)
    Ruby 2.5 (2.6)
    Rails5.2
    Redmine 4.0 DBMS
    MySQL 5.7
    (BP 8GB)
    HTTP
    Apache 2.4
    Memory 16GB
    CPU 4cores
    VMware ESXi 6.5 【CPU】Intel Xeon E5-2670 2.3GHz x2 (24Cores/48Threads) , 【Memory】256GB,
    【SSD】8.7TB SAS RAID6, 【HDD】6TB 10K RPM SAS RAID6
    VCS
    Subversion1.9
    環境構成
    SSD/HDD NIC
    調査日 2019/1
    FTS* 応答性能の計測
    ベンチマーク|計測結果7

    View full-size slide

  89. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    89
    ① 検索キーワード3種に対して2並列でそれぞれ2回アクセスして計測値を平均。3種を
    合算して所要時間合計とする
    ② 上記①を、下記3種のキャッシュ状態を順次切り替えて計測
    全キャッシュ無 → Fullメモリキャッシュ
    ③ 上記②の全キャッシュ無、Fullメモリキャッシュの計測値を採用
    ④ 上記①~③を、下記要素の全組み合わせ環境で繰り返す
    Redmineバージョン、 Rubyバージョン、OOGBC有無、
    MySQLバージョン、10万~200万チケット、SSD固定
    10万 20万 30万 50万 70万 100万 150万 200万
    所要時間合計(ミリ秒) 1735.4 2286.9 2880.4 3983.7 5135.6 6836.7 9841.8 12340.2
    Redmine4.0
    Ruby2.5
    MySQL5.7
    BufferPool 8G
    SSD
    Plug-in ON
    No Cache
    検索キーワード3種のURI
    /its40/search?q=ATO 1181.8 1337.1 1534.2 1904.0 2283.7 2864.4 3852.1 4732.5
    /its40/search?q=WIP 279.7 477.3 674.0 1034.8 1425.0 1970.3 2966.9 3778.9
    /its40/search?q=sSCOPE 273.9 472.5 672.2 1044.9 1426.9 2002.0 3022.8 3828.8
    調査日 2019/1
    FTS* 応答性能の計測
    ベンチマーク|計測結果7
    * FTS; Full Text Search 全文検索(索引型/非索引型)

    View full-size slide

  90. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    200
    400
    600
    800
    1,000
    1,200
    No Cash Full Cash No Cash Full Cash No Cash Full Cash
    Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型















    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果7
    90
    FTS* 応答性能の計測

    調査日 2019/1
    * FTS; Full Text Search 全文検索(索引型/非索引型)
    Redmineの全文検索処理
    ・非索引型
    ・索引型(プラグイン導入)
    Redmine Full Text Search V0.7.3+
    OSS検索エンジン Goonga
    計測時のキャッシュ状態2種
    ・No Cash
    ・Full Cashed
    計測対象
    1) /its40/search?q=ATO
    2) /its40/search?q=WIP
    3) /its40/search?q=sSCOPE
    Redmine4.0
    非索引型 索引型
    Redmine4.0
    非索引型
    Redmine3.0

    View full-size slide

  91. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    200
    400
    600
    800
    1,000
    1,200
    No Cash Full Cash No Cash Full Cash No Cash Full Cash
    Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型















    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果7
    91
    FTS* 応答性能の計測

    調査日 2019/1
    * FTS; Full Text Search 全文検索(索引型/非索引型)
    Redmine3.0 Redmine4.0
    非索引型 索引型
    Redmine4.0
    非索引型
    Redmine3.0 非索引型 全文検索
    チケット数 No Cache Full Cache
    10万 15.3 0.6
    20万 29.5 1.0
    30万 46.5 1.4
    50万 78.1 2.4
    70万 108.8 3.5
    100万 165.7 4.9
    150万 253.6 7.3
    200万 355.3 9.7
    合計 1052.8 30.8
    計測値単位: 秒(sec)

    View full-size slide

  92. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    200
    400
    600
    800
    1,000
    1,200
    No Cash Full Cash No Cash Full Cash No Cash Full Cash
    Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型















    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果7
    92
    FTS* 応答性能の計測

    調査日 2019/1
    * FTS; Full Text Search 全文検索(索引型/非索引型)
    Redmine3.0 Redmine4.0
    非索引型 索引型
    Redmine4.0
    非索引型
    Redmine3.0 非索引型 全文検索
    チケット数 No Cache Full Cache
    10万 15.3 0.6
    20万 29.5 1.0
    30万 46.5 1.4
    50万 78.1 2.4
    70万 108.8 3.5
    100万 165.7 4.9
    150万 253.6 7.3
    200万 355.3 9.7
    合計 1052.8 30.8
    計測値単位: 秒(sec)
    ・Redmine3.0 非索引型は10万チケットの初回検索が平均15.3秒
    ・データをメモリ上へ読み込むにつれてFull Cacheの速度に近づく
    ・日常の検索は全横断ではなくプロジェクト内なので速い

    View full-size slide

  93. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    200
    400
    600
    800
    1,000
    1,200
    No Cash Full Cash No Cash Full Cash No Cash Full Cash
    Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型















    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果7
    93
    FTS* 応答性能の計測

    調査日 2019/1
    * FTS; Full Text Search 全文検索(索引型/非索引型)
    Redmine3.0 Redmine4.0
    非索引型 索引型
    Redmine4.0
    非索引型
    Redmine4.0 非索引型 全文検索
    チケット数 No Cache Full Cache
    10万 4.7 0.5
    20万 7.9 0.9
    30万 11.6 1.2
    50万 21.0 2.0
    70万 28.4 2.9
    100万 40.5 4.2
    150万 61.7 6.5
    200万 82.5 8.5
    合計 258.3 26.7
    計測値単位: 秒(sec)

    View full-size slide

  94. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    200
    400
    600
    800
    1,000
    1,200
    No Cash Full Cash No Cash Full Cash No Cash Full Cash
    Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型















    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果7
    94
    FTS* 応答性能の計測

    調査日 2019/1
    * FTS; Full Text Search 全文検索(索引型/非索引型)
    Redmine3.0 Redmine4.0
    非索引型 索引型
    Redmine4.0
    非索引型
    Redmine4.0 非索引型 全文検索
    チケット数 No Cache Full Cache
    10万 4.7 0.5
    20万 7.9 0.9
    30万 11.6 1.2
    50万 21.0 2.0
    70万 28.4 2.9
    100万 40.5 4.2
    150万 61.7 6.5
    200万 82.5 8.5
    合計 258.3 26.7
    計測値単位: 秒(sec)
    ・Redmine4.0 非索引型は10万チケットの初回検索が平均4.7秒
    ・データをメモリ上へ読み込むにつれてFull Cacheの速度に近づく
    ・日常の検索は全横断ではなくプロジェクト内なので十分に速い

    View full-size slide

  95. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    200
    400
    600
    800
    1,000
    1,200
    No Cash Full Cash No Cash Full Cash No Cash Full Cash
    Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型















    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果7
    95
    FTS* 応答性能の計測

    調査日 2019/1
    * FTS; Full Text Search 全文検索(索引型/非索引型)
    Redmine3.0 Redmine4.0
    非索引型 索引型
    Redmine4.0
    非索引型
    Redmine4.0 索引型 全文検索
    チケット数 No Cache Full Cache
    10万 1.7 0.1
    20万 2.3 0.1
    30万 2.9 0.1
    50万 4.0 0.1
    70万 5.1 0.1
    100万 6.8 0.1
    150万 9.8 0.1
    200万 12.3 0.1
    合計 44.9 0.8
    計測値単位: 秒(sec)

    View full-size slide

  96. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    200
    400
    600
    800
    1,000
    1,200
    No Cash Full Cash No Cash Full Cash No Cash Full Cash
    Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型















    10万 20万 30万 50万 70万 100万 150万 200万
    ベンチマーク|計測結果7
    96
    FTS* 応答性能の計測

    調査日 2019/1
    * FTS; Full Text Search 全文検索(索引型/非索引型)
    Redmine3.0 Redmine4.0
    非索引型 索引型
    Redmine4.0
    非索引型
    Redmine4.0 索引型 全文検索
    チケット数 No Cache Full Cache
    10万 1.7 0.1
    20万 2.3 0.1
    30万 2.9 0.1
    50万 4.0 0.1
    70万 5.1 0.1
    100万 6.8 0.1
    150万 9.8 0.1
    200万 12.3 0.1
    合計 44.9 0.8
    計測値単位: 秒(sec)
    ・Redmine4.0 索引型は10万チケットの初回検索が平均1.7秒
    ・索引データを一度メモリに読み込むとFull Cacheの速度になり、
    データが増加しても0.1秒を維持
    ・200万チケット(約15億文字)の索引データサイズは約9GB
    メモリを追加して起動時に読み込めばFull Cashスピードになる

    View full-size slide

  97. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果7
    97
    FTS 応答性能の計測 調査日 2019/1
    * 表中の数値は検索キーワード3種の所要時間の合計
    10万
    0.1M
    20万
    0.2M
    30万
    0.3M
    50万
    0.5M
    70万
    0.7M
    100万
    1M
    150万
    1.5M
    200万
    2M
    平均
    AVG
    Redmine 3.0
    非索引型
    No Index
    No Cash 15.3 29.5 46.5 78.1 108.8 165.7 253.6 355.3 131.6
    Full Cash 0.6 1.0 1.4 2.4 3.5 4.9 7.3 9.7 3.8
    Redmine 4.0
    非索引型
    No Index
    No Cash 4.7 7.9 11.6 21.0 28.4 40.5 61.7 82.5 32.3
    Full Cash 0.5 0.9 1.2 2.0 2.9 4.2 6.5 8.5 3.3
    Redmine 4.0
    索引型
    FTS Indices
    No Cash 1.7 2.3 2.9 4.0 5.1 6.8 9.8 12.3 5.6
    Full Cash 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1
    全文検索 所用時間(秒 sec)*

    View full-size slide

  98. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果7
    98
    FTS 応答性能の計測 調査日 2019/1
    10万
    0.1M
    20万
    0.2M
    30万
    0.3M
    50万
    0.5M
    70万
    0.7M
    100万
    1M
    150万
    1.5M
    200万
    2M
    平均
    AVG
    Redmine 3.0
    非索引型
    No Index
    No Cash 15.3 29.5 46.5 78.1 108.8 165.7 253.6 355.3 131.6
    Full Cash 0.6 1.0 1.4 2.4 3.5 4.9 7.3 9.7 3.8
    Redmine 4.0
    非索引型
    No Index
    No Cash 4.7 7.9 11.6 21.0 28.4 40.5 61.7 82.5 32.3
    Full Cash 0.5 0.9 1.2 2.0 2.9 4.2 6.5 8.5 3.3
    Redmine 4.0
    索引型
    FTS Indices
    No Cash 1.7 2.3 2.9 4.0 5.1 6.8 9.8 12.3 5.6
    Full Cash 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1
    全文検索 所用時間(秒 sec)*
    ・Redmine3.0の全文検索(非索引型)は10万チケットで、
    * 表中の数値は検索キーワード3種の所要時間の合計

    View full-size slide

  99. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果7
    99
    FTS 応答性能の計測 調査日 2019/1
    10万
    0.1M
    20万
    0.2M
    30万
    0.3M
    50万
    0.5M
    70万
    0.7M
    100万
    1M
    150万
    1.5M
    200万
    2M
    平均
    AVG
    Redmine 3.0
    非索引型
    No Index
    No Cash 15.3 29.5 46.5 78.1 108.8 165.7 253.6 355.3 131.6
    Full Cash 0.6 1.0 1.4 2.4 3.5 4.9 7.3 9.7 3.8
    Redmine 4.0
    非索引型
    No Index
    No Cash 4.7 7.9 11.6 21.0 28.4 40.5 61.7 82.5 32.3
    Full Cash 0.5 0.9 1.2 2.0 2.9 4.2 6.5 8.5 3.3
    Redmine 4.0
    索引型
    FTS Indices
    No Cash 1.7 2.3 2.9 4.0 5.1 6.8 9.8 12.3 5.6
    Full Cash 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1
    全文検索 所用時間(秒 sec)*
    ・Redmine3.0の全文検索(非索引型)は10万チケットで、
    4.0は20~30万チケットで実用性能の限界に到達する。
    * 表中の数値は検索キーワード3種の所要時間の合計

    View full-size slide

  100. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果7
    100
    FTS 応答性能の計測 調査日 2019/1
    10万
    0.1M
    20万
    0.2M
    30万
    0.3M
    50万
    0.5M
    70万
    0.7M
    100万
    1M
    150万
    1.5M
    200万
    2M
    平均
    AVG
    Redmine 3.0
    非索引型
    No Index
    No Cash 15.3 29.5 46.5 78.1 108.8 165.7 253.6 355.3 131.6
    Full Cash 0.6 1.0 1.4 2.4 3.5 4.9 7.3 9.7 3.8
    Redmine 4.0
    非索引型
    No Index
    No Cash 4.7 7.9 11.6 21.0 28.4 40.5 61.7 82.5 32.3
    Full Cash 0.5 0.9 1.2 2.0 2.9 4.2 6.5 8.5 3.3
    Redmine 4.0
    索引型
    FTS Indices
    No Cash 1.7 2.3 2.9 4.0 5.1 6.8 9.8 12.3 5.6
    Full Cash 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1
    全文検索 所用時間(秒 sec)*
    ・Redmine3.0の全文検索(非索引型)は10万チケットで、
    4.0は20~30万チケットで実用性能の限界に到達する。
    ・Redmine4.0に索引型の全文検索Pluginを導入すると、
    実用的な検索速度は3.0に比べて平均で23倍速くなる。
    * 表中の数値は検索キーワード3種の所要時間の合計

    View full-size slide

  101. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    10万
    0.1M
    20万
    0.2M
    30万
    0.3M
    50万
    0.5M
    70万
    0.7M
    100万
    1M
    150万
    1.5M
    200万
    2M
    平均
    AVG
    Redmine 3.0
    非索引型
    No Index
    No Cash 15.3 29.5 46.5 78.1 108.8 165.7 253.6 355.3 131.6
    Full Cash 0.6 1.0 1.4 2.4 3.5 4.9 7.3 9.7 3.8
    Redmine 4.0
    非索引型
    No Index
    No Cash 4.7 7.9 11.6 21.0 28.4 40.5 61.7 82.5 32.3
    Full Cash 0.5 0.9 1.2 2.0 2.9 4.2 6.5 8.5 3.3
    Redmine 4.0
    索引型
    FTS Indices
    No Cash 1.7 2.3 2.9 4.0 5.1 6.8 9.8 12.3 5.6
    Full Cash 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1
    ベンチマーク|計測結果7
    101
    FTS 応答性能の計測 調査日 2019/1
    全文検索 所用時間(秒 sec)*
    ・Redmine3.0の全文検索(非索引型)は10万チケットで、
    4.0は20~30万チケットで実用性能の限界に到達する。
    ・Redmine4.0に索引型の全文検索Pluginを導入すると、
    実用的な検索速度は3.0に比べて平均で23倍速くなる。
    ・200万チケット(≒15億文字)を1件あたり* 平均1.9秒で検索可能になる。
    2 million tickets include approximately 1.5 billion multi-byte characters. Indexed FTS takes 1.9s (Avg per 1 search).
    * 表中の数値は検索キーワード3種の所要時間の合計

    View full-size slide

  102. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果8
    102
    FTS 応答性能の計測 調査日 2019/X
    35万添付ファイルを検索対象としたときの全文検索の性能計測
    1)実運用環境の35万ファイルを使用して、全文検索(非索引型)の応答性能を計測し
    た。今回は約30億文字でスタートするが、将来データが増加した状態を最大200億文
    字と想定すると、検索時間が長時間化して使い物にならない可能性がある。
    2)検索結果の精度も問題となる。現状のSQLによる検索では、探したい情報が大量
    のデータに埋もれてしまい使い物にならない可能性がある。
    1ファイルの平均文字数:3000文字(想定)
    添付 1ファイル 平均3000文字 (オフィス文書、集計表、論文)
    リポジトリ 1ファイル 平均3000文字 (ソース、設計文書)
    試算
    10万ファイル= 3億文字
    200万ファイル= 60億文字
    500万ファイル=150億文字
    1000万ファイル=300億文字
    データ計測中
    グラフ作成予定

    View full-size slide

  103. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果8
    103
    FTS 応答性能の計測 調査日 2019/X
    35万ファイルのデータ量は
    約10億文字
    1ファイル平均3000文字
    ・オフィス文書
    ・集計表
    ・論文
    35万添付ファイルを検索対象としたときの全文検索の性能計測
    データ計測中
    グラフ作成予定
    友情出演:ぬるくま 様

    View full-size slide

  104. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    ベンチマーク|計測結果9
    104
    Redmine4.0は200万チケットでも
    “サクサク”なのか?

    View full-size slide

  105. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    100
    200
    300
    400
    500
    600
    700
    800
    900
    1000
    10万 20万 30万 50万 70万 100万 150万 200万
    Wiki Top
    チケット表示(小)
    チケット表示(大)
    チケット表示(中)
    チケット一覧
    プロジェクトTop
    プロジェクト一覧
    Redmine Top
    ベンチマーク|計測結果9
    105
    Redmine4.0は200万チケットでも
    “サクサク”なのか?
    ms
    調査日 2019/1

    View full-size slide

  106. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    100
    200
    300
    400
    500
    600
    700
    800
    900
    1000
    10万 20万 30万 50万 70万 100万 150万 200万
    Wiki Top
    チケット表示(小)
    チケット表示(大)
    チケット表示(中)
    チケット一覧
    プロジェクトTop
    プロジェクト一覧
    Redmine Top
    ベンチマーク|計測結果9
    106
    Redmine4.0は200万チケットでも
    “サクサク”なのか?
    ms
    調査日 2019/1

    View full-size slide

  107. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    100
    200
    300
    400
    500
    600
    700
    800
    900
    1000
    10万 20万 30万 50万 70万 100万 150万 200万
    Wiki Top
    チケット表示(小)
    チケット表示(大)
    チケット表示(中)
    チケット一覧
    プロジェクトTop
    プロジェクト一覧
    Redmine Top
    ベンチマーク|計測結果9
    107
    Redmine4.0は200万チケットでも
    “サクサク”なのか?
    ms
    調査日 2019/1
    チューニングの結果、Redmine4.0の
    主要画面8種の平均応答時間は103ms

    View full-size slide

  108. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    100
    200
    300
    400
    500
    600
    700
    800
    900
    1000
    10万 20万 30万 50万 70万 100万 150万 200万
    Wiki Top
    チケット表示(小)
    チケット表示(大)
    チケット表示(中)
    チケット一覧
    プロジェクトTop
    プロジェクト一覧
    Redmine Top
    ベンチマーク|計測結果9
    108
    Redmine4.0は200万チケットでも
    “サクサク”なのか?
    ms
    調査日 2019/1
    ①全文検索 20秒
    Full_Text_Search Plugin
    ②DB始動時の暖機運転5分
    MySQL5.6, Postgres9.4に対策有り
    (BufferPool dump/Restore)
    ③BufferPool
    8GB以上必須
    ④SSD

    View full-size slide

  109. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    0
    100
    200
    300
    400
    500
    600
    700
    800
    900
    1000
    10万 20万 30万 50万 70万 100万 150万 200万
    Wiki Top
    チケット表示(小)
    チケット表示(大)
    チケット表示(中)
    チケット一覧
    プロジェクトTop
    プロジェクト一覧
    Redmine Top
    ③BufferPool
    8GB以上必須
    ④SSD
    ベンチマーク|計測結果9
    109
    Redmine4.0は200万チケットでも
    “サクサク”なのか?
    ms
    調査日 2019/1
    ①全文検索 20秒
    Full_Text_Search Plugin
    ②DB始動時の暖機運転5分
    MySQL5.6, Postgres9.4に対策有り
    (BufferPool dump/Restore)
    4点対策して環境を整備すれば
    200万チケットまで大丈夫

    View full-size slide

  110. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    目次
    110
    第1部 背景と要求
    第2部 チューニングの基本
    第3部 ベンチマーク
    第4部 全文検索機能の拡張
    第5部 性能改善事例集
    第6部 まとめ
    110

    View full-size slide

  111. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    全文検索機能の拡張
    111
    【要求】
    ・添付ファイルとリポジトリの内容を高速に検索したい
    ・大量のデータが収容されるので検索精度を向上したい
    【想定】
    ・10年後の想定 = 200億文字
    200万チケット= 30億文字(1500文字/1チケット換算)
    Wiki, コメント= 20億文字
    500万ファイル= 150億文字
    (平均3000文字/ファイル、添付ファイル200万、リポジトリ300万)
    【機能拡張】
    1. 添付ファイルとリポジトリ検索機能
    2. 200億文字の全文検索を300ms以内に実現
    3. 高精度検索(機械学習によるAI検索)
    【OSS開発】
    ・株式会社クリアコードさんと株式会社島津製作所の共同開発
    ・開発成果物はオープンソースとして公開

    View full-size slide

  112. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    全文検索機能の拡張
    112
    検索対象 50億文字
    ・添付ファイル35万 10億文字
    ・リポジトリ100万ファイル 40億文字
    1ファイル平均3000文字
    ・オフィス文書
    ・集計表
    ・論文
    ・ソースコード
    ・製品ドキュメント
    添付ファイルとSubversionリポジトリを検索対象としたときの全文検索の性能計測
    開発中
    データ計測予定
    (画餅)
    友情出演:京都 出町ふたば の まめ餅 様

    View full-size slide

  113. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    目次
    113
    第1部 背景と要求
    第2部 チューニングの基本
    第3部 ベンチマーク
    第4部 全文検索機能の拡張
    第5部 性能改善事例集
    第6部 まとめ
    113

    View full-size slide

  114. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    性能改善事例集
    114
    1. 9年間に渡るRedmineの運用におい
    て、どのような問題が発生し、どう
    やって解消したのか
    2. 信頼性と安定性を維持する取組みの
    「実際と限界」に焦点
    3. 各種設定、チューニング方法、性能計
    測方法を全て紹介する

    View full-size slide

  115. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    計測 - 定量化手法
    「測定できないものは制御できない」*
    115
    * DeMarco, Tom., 1982, “You can’t control what you can't measure.”

    View full-size slide

  116. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    計測 - 定量化手法
    「測定できないものは制御できない」*
    1.テスト実行時間 (Redmine Built-in Test Code)
    2.負荷ベンチマーク
    ・httpref https://github.com/httperf/httperf
    ・wrk https://github.com/wg/wrk
    ・apache bench http://httpd.apache.org/docs/2.4/programs/ab.html
    3.時間計測
    ・MySQL Slow-query ログ
    ・Redmineログ (Production.log, Development.log)
    4.分析
    ・SQL実行計画(MySQL Workbench) https://www-jp.mysql.com/products/workbench/
    ・Chrome開発者ツール https://developers.google.com/web/tools/chrome-devtools/
    ・ネットワークスループット調査 iperf https://iperf.fr/ (Win版は× : ブルースクリーン死亡)
    116
    * DeMarco, Tom., 1982, “You can’t control what you can't measure.”

    View full-size slide

  117. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    チューニングチェックリスト20 1/2
    117
    1)Memory搭載・設定 DBMSに十分なキャッシュメモリを付与
    2)Disk I/O HDD→ SSD
    3)CPUコア数と同時並行処理数
    4)OS選択 Linux / 起動プロセスとパッケージは必要最低限に削ぎ落とす。
    5)DBMS選択 MySQL, Postgresql を使用して、必ず設定値を変更。
    6)通信データ圧縮 Apache等 HTTP/1.1 Compression
    7)Rubyバージョン利用可能な最新版を使用
    1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 < 2.4 < 2.5 ≒ 2.6
    8)Webアプリケーションサーバー選択
    WEBrick < < < Thin < < Passenger5 / 6
    9)通信経路の狭帯域対策
    10M/bps → 1G/bps (ケーブル交換、装置交換)
    同一サーバーに置くことで通信帯域を広くする。Local Loopback は最速のNIC
    10)通信装置の性能向上
    Normal-HubをSwitching-Hubへ交換しコリジョンによる通信効率低下を回避
    11)Subversionリポジトリの同期トリガを変更

    View full-size slide

  118. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    118
    12)Subversionリポジトリの同期対象を指定する
    13)Subversionセッションキャッシュを付与する
    14)Subversion通信圧縮機能を利用する
    15)MySQLメモリチューニング
    メモリを十分に付与し、全インデックスや全データをできるだけオンメモリ化
    16)カスタムフィールドの設定
    「検索対象」の数が多いと極端に性能が落ちる
    17)DBMSサーバーの「暖機運転」
    MySQL 5.6以降: Buffer-Pool Save & Load
    PostgreSQL 9.4以降: pg_prewarm
    18)メール非同期送信(Async)
    19)Plugin導入数
    20)RubyとGC
    ・内部処理の大幅改善によりRuby2.5が最速のバージョン( 調査時点 2019/1 )
    ・2位は Ruby2.3+OOBGC
    チューニングチェックリスト20 2/2

    View full-size slide

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

    View full-size slide

  120. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例1)【性能】全体がひどく遅い
    120
    【チューニング要素】
    ・H/W: HDD, Memory, CPU
    ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer
    ・N/W: 通信帯域, Switching-Hub
    1)Memory搭載・設定
    DBMSに十分なキャッシュメモリを付与
    2)Disk I/O HDD→ SSD
    OS, DBMS, APL(Redmine他)はSSDに格納し、他のデータはHDDへ
    3)CPUコア数と同時並行処理数
    処理要求が集中した時の待ち行列
    CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える。
    - Passenger:自動調整 (指定可能)
    - Unicorn , Thin:起動サーバー数を増減

    View full-size slide

  121. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例1)【性能】全体がひどく遅い
    121
    【チューニング要素】
    ・H/W: HDD, Memory, CPU
    ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer
    ・N/W: 通信帯域, Switching-Hub
    4)OS選択
    Windows Bitnamiは10万件まで(制約:Ruby2.3系, DBMS 32bit)
    最新のBitnami 3.4, 4.0系はRuby2.3に。未調査だが期待。(制約:DBMS 32bit)
    15万件以上扱うなら、Windows上にスクラッチでRedmine構築を推奨
    20万件以上扱うなら200万件まで確認したLinux 64bitを推奨
    5)DBMS選択
    MySQL, Postgresql を使用して, 必ず設定値を変更。Sqliteは1万チケットまで
    6)通信データ圧縮
    Apache等 HTTP/1.1 Compression
    ネットワーク帯域が狭い時、通信輻輳時に高い効果

    View full-size slide

  122. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例1)【性能】全体がひどく遅い
    122
    【チューニング要素】
    ・H/W: HDD, Memory, CPU
    ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer
    ・N/W: 通信帯域, Switching-Hub
    7)Rubyバージョン
    利用可能な最新版を使用 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 < 2.4 < 2.5 ≒ 2.6
    8)Webアプリケーションサーバー選択
    WEBrick < < < Thin < < Passenger6
    (Unicornは未調査。速いがPassengerに比して扱い難い。上級者向け)
    9)通信経路の狭帯域対策
    10M/bps → 1G/bps (ケーブル+Switch機器を交換)
    Local Loopback は最速のNIC
    10)通信装置の性能向上
    Normal-HubをSwitchへ交換しコリジョンによる通信効率低下を回避

    View full-size slide

  123. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例2)【性能】リポジトリタブが遅い
    123
    【チューニング要素】
    ・H/W: HDD, Memory, CPU
    ・S/W: DBMS, Ruby, WebAppServer, Subversion Server
    ・N/W: 通信帯域, Switching-Hub
    1)Subversionリポジトリの同期トリガを変更
    SubversionとRedmine間のリポジトリ同期は、画面上のリポジトリタブをクリッ
    クすると実施されるのが既定の動作。リビジョン数が増えてくると表示されるまで
    に1分以上待たされる。
    Redmine全体管理画面の「コミットを自動取得する」をOFFにして、Subversion
    リポジトリ側のPost-Commit-Hookに同期スクリプトを組み込むことで、同期ト
    リガが“コミット時”へ変更され、画面上のリポジトリタブは直ちに表示されるよう
    になる。
    2)Subversionリポジトリの同期対象を指定する
    前述のPost-Commit-Hookは全プロジェクトを対象にするため、リポジトリ数が多
    い場合5分以上かかる場合がある。ほぼ同時に5人が5回ずつコミットすると同期が
    25並列で実行されてしまい、処理輻輳によりRedmineが応答しなくなる。
    特定のProjectのみ同期を実施するよう、スクリプトに追記する。

    View full-size slide

  124. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例2)【性能】リポジトリタブが遅い
    124
    【チューニング要素】
    ・H/W: HDD, Memory, CPU
    ・S/W: DBMS, Ruby, WebAppServer, Subversion Server
    ・N/W: 通信帯域, Switching-Hub
    3)Subversionセッションキャッシュ
    セッション毎にキャッシュメモリを付与 (Subversion 1.7 以上)
    4)Subversion通信圧縮機能
    通信内容の圧縮レベル指定(Subversion 1.7 以上)
    5)同一サーバーに置き、通信帯域を広くする
    Local loopback, TCP/UDP/Socket通信は高速
    6)MySQL テーブル更新が遅い
    DBMSメモリ設定
    SSD採用

    View full-size slide

  125. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例3)【性能】検索が遅い
    125
    1)MySQLメモリチューニング
    ・メモリをできるだけ積み込む
    ・全インデックス、全データをオンメモリにする
    2)カスタムフィールドの設定
    「検索対象」の数が多いと極端に性能が落ちる
    【チューニング要素】
    ・H/W: Memory, CPU
    ・S/W: DBMS, Redmine

    View full-size slide

  126. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例4)【性能】画面応答が遅い
    126
    1)Rubyのバージョン 処理性能
    1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 < 2.4 < 2.5 ≒ 2.6
    2)MySQLメモリチューニング
    全インデックスと主要データをメモリに乗せる
    3)初回アクセスが極端に遅い
    MySQL 5.6以降 – Bufferpool save and load
    PostgreSQL 9.4以降 - pg_prewarm
    4)CPUコア数と同時並行処理数
    処理要求が集中した時の待ち行列
    CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える
    - Passenger:自動調整 (指定も可能)
    - Thin:起動サーバー数を増減
    【チューニング要素】
    ・H/W: HDD, Memory, CPU
    ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer
    ・N/W: 通信帯域, Switching-Hub

    View full-size slide

  127. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例4)【性能】画面応答が遅い
    127
    5)メール非同期送信(Async)
    通知先が多い / メールサーバー(MTA)が遅い
    6)Plugin導入数
    導入数が多いと遅くなる。
    大量データの応答性能まで考慮されているPluginはそう多くない。
    7)通信データの圧縮
    HTTP1.1/Compression (最大10倍速)
    【チューニング要素】
    ・H/W: HDD, Memory, CPU
    ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer
    ・N/W: 通信帯域, Switching-Hub

    View full-size slide

  128. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例5)【性能】特定プラグインが遅い
    128
    【チューニング要素】
    ・H/W: Memory, CPU
    ・S/W: DBMS, Ruby, WebAppServer
    - 一部のプラグインは大量のデータ処理を想定していない。
    極端に遅い場合はチューニングを施し、作者にパッチを送付できる。
    処理遅延の原因は、SQL/コード実装/データ設計の3系統に大別できる。
    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
    ・アプリコード調査手順(今回は実施せず)
    ・データ設計調査手順 (今回は実施せず)

    View full-size slide

  129. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例6)【信頼性】不安定で手間がかかる
    129
    1)3歩遅れの「枯れた技術」
    末尾が3になったら導入 例)Redmine 4.0.3
    2)Windows <<< Linux OS
    両方面倒を見てきたが、Ruby, Rails はWindowsで制限が多い(印象)
    3)RedmineUpdateの工夫
    新旧の環境を並立させて動作を確認し、準備が整ったら切り替える
    4)OSS パッチの取込み
    Redmineの性能が改善され、問題は解消され続けている。
    最新版を手間なく取り込む方法がある。Gitの追跡ブランチモードで git cloneし、
    Local変更との共存を確保しつつ、git pull で差分を取り込めば良い。
    例)# mkdir /var/lib/its/rm40_its
    # cd /var/lib/its/rm40_its
    # git clone https://github.com/redmine/redmine.git .
    # git checkout -b 4.0-stable-local origin/4.0-stable
    # git pull (差分取り込み実行)
    【チューニング要素】
    ・H/W: Memory, CPU
    ・S/W: DBMS, Ruby, WebAppServer

    View full-size slide

  130. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例6)【信頼性】不安定で手間がかかる
    130
    5)Exception発生をMail 通知し、不具合を確実に検出
    Redmine本体のExceptionは9年間でもほんの僅か
    https://github.com/kou/redmine_exception_handler (Redmine4.0対応)
    6)Redmine本体やRailsに手を入れない
    Redmine本体の品質は極めて高い
    テストコードのカバレッジ率がとても高い
    http://www.redmine.org/builds/coverage/
    7)Pluginは魅力的だが、採用は最小限に抑制
    Redmine本体のUpdateの足枷になる
    テストコードが無く、DBテーブル構造を壊す例もある
    【ITS運転結果(実績値)】
    平均故障間隔(MTBF) 8,364時間(348日)、平均修復時間(MTTR) 15時間、稼働率 99.8%
    言い換えると「SBSのITSサーバーは1年に1回故障し、システムサービスの復帰まで15時間かかる」
    【チューニング要素】
    ・H/W: Memory, CPU
    ・S/W: DBMS, Ruby, WebAppServer

    View full-size slide

  131. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例6)【信頼性】不安定で手間がかかる
    131
    8)完全なクローン環境を常設
    ・ゴミデータ、評価用データを本番に持ち込ませない
    ・要望を受けてから手動で同期
    ・誤入力の事故を防止するため、画面の色を変えている
    【チューニング要素】
    ・H/W: Memory, CPU
    ・S/W: DBMS, Ruby, WebAppServer
    Dump and Restore

    View full-size slide

  132. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    Munin: Average latency
    Munin: Average latency
    事例7)【性能】電算機のH/W資源不足
    132
    1)Redmine関係アプリケーションを1VMに集約し、狭帯域通信を回避
    2)CPU キャッシュの大きなものを複数コア用意
    同時接続の処理数に合わせる
    3)メモリをできるだけ積み込む
    4)SSD導入: SSD(OS, DBMS, Redmine)、HDD(その他データ)
    ↓ SSD切替点
    ↓ SSD切替点
    【HDD】突出ピークが無くなった。
    【SSD】ピークが無くなりI/O waitが小さくなった。
    振れ幅が小さく、余力が見てとれる。

    View full-size slide

  133. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    事例8)【性能】電算機通信網の帯域不足
    133
    <Network>
    1)主要通信経路は1G/bpsに統一
    10M/bps, 100M/bps のボトルネックを排除
    2)Normal Hub → Switching Hub
    コリジョン発生率の低減
    3)Local Loopback通信
    サーバー統合による通信の高速化

    View full-size slide

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

    View full-size slide

  135. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    設定例1)基本S/W
    135
    OS, File-System
    1)OS CentOS 7
    プロセス、パッケージは必要最低限に削ぎ落とす。
    (パッチ適用、最少の停止頻度、セキュリティー、メモリ)
    2)File-System
    Ext4 nobarrier チューン http://goo.gl/LYwfA0
    3)Kernel設定
    ・[SSD] Disk I/O スケジューラーを cfq から deadline へ変更
    ・[SSD] SWAP抑制 vm.swappiness=1
    ※ 性能への影響は未確認

    View full-size slide

  136. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    設定例2)ミドルウェア
    136
    DBMS, WebServer, Web Application Server
    <DBMS>
    1)チューニング設定
    ・MySQL 5.7
    2)SSDによるI/O改善
    ・DBMS設定
    MySQL innodb_flush_neighbors = 0
    ・配置構成
    DBデータだけでなく、OS全体をSSDに乗せると効果が大きい
    ・結果例
    200万チケット分のDBデータをダンプ/リストア
    HDD → SSDにより33%向上(5分早く終わる)

    View full-size slide

  137. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    設定例2)ミドルウェア
    137
    DBMS, WebServer, Web Application Server
    <WebServer>
    3)通信圧縮 Compress, Gzip, Deflate 圧縮
    <Web Application Server>
    4)選択
    WEBLick は性能 ×
    運用の容易さは Unicorn < Passenger
    5)Phusion Passenger 6
    6)Passenger と OOBGC
    Passenger4, Ruby2.1, OOBGC(gctools)で安定稼働(実績1年)
    Passenger5, Ruby2.2, OOBGC(gctools)で安定稼働(実績6ヶ月)
    Passenger5, Ruby2.3, OOBGC(gctools)で安定稼働(実績2年)
    7)Passenger Enterprise
    Multi Threadモードで○○% 向上 (未調査)
    利用料金は 5000円/月程度

    View full-size slide

  138. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    設定例3)応用S/W
    138
    Ruby, OOBGC, Redmine, Subversion
    <Ruby>
    ・GCの大幅改善によりRuby2.5が最速のバージョン(調査時点 2019/1 )
    ・2位は Ruby2.3+OOBGC
    <OOBGC for Ruby2.1, 2.2, 2.3>
    ・Unicorn
    GitHubのAman gupta-san(@tmm1)が作ったgctools original.
    https://github.com/tmm1/gctools
    ・Passenger4/5
    Ruby2.1は、Shirosaki-san(@shirosaki)のFork版
    https://github.com/shirosaki/gctools
    Ruby2.1/2.2/2.3は、@akahane92 のFork版
    https://github.com/akahane92/gctools
    This 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.4, 2.5, 2.6は、Normalの採用が総合的に見て最適選択。
    OOBGC有は最大性能への向上を必要とする方向け(ちょいムズ)

    View full-size slide

  139. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    設定例3)応用S/W
    139
    Ruby, OOBGC, Redmine, Subversion
    <Redmine>
    ・カスタムフィールドの設定値「検索条件」の数を減らす。
    例「14万チケットだと30種 ○○秒 → 5種 〇秒」
    (未計測だが効果は絶大)
    ・メール非同期送信(Async)
    ※ Redmine4.0以降は不要(ActiveJobによる非同期の送信処理へ変更された)
    config/configuration.yml
    production:
    email_delivery:
    delivery_method: :async_smtp
    async_smtp_settings:

    View full-size slide

  140. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    設定例3)応用S/W
    140
    Ruby, OOBGC, Redmine, Subversion
    <VCS>
    ・Subversion Server 1.7以降のセッションキャッシュ付与機能
    セッションキャッシュにより、通信応答速度が向上する。
    ・Subversion Server 1.7以降の通信圧縮機能
    セッションデータ通信内容の多くはテキストデータ。
    高い圧縮によって通信効率と応答性が向上する。

    View full-size slide

  141. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    目次
    141
    第1部 背景と要求
    第2部 チューニングの基本
    第3部 ベンチマーク
    第4部 全文検索機能の拡張
    第5部 性能改善事例集
    第6部 まとめ
    141

    View full-size slide

  142. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    お話ししたこと
    142
    1)200万チケットでもサクサク動くRedmineの全レシピ*
    2)Redmine 2.6 を 4.0 へUpdateすると平均で29%
    速くなる
    3)Ruby2.2 を 2.5, 2.6 へUpdateすると平均で21.7%
    速くなる
    4)HDDをSSDにすると環境により平均で28.5%
    速くなる
    5)非索引型の全文検索は20~30万チケットで性能限界に到達
    するが、Fulltext-Search-Plugin の導入によって23倍速くなり、
    200万チケットの環境では平均1.9秒で全文検索できる
    6)Redmine全文検索の機能の追加開発とオープンソース化
    7) Redmineチューニング事例 9種
    *全レシピ: 設定値の一括ダウンロードはこちら (GitHub Gist)
    Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt
    https://gist.github.com/akahane92/771f9a52d81af9864dd8

    View full-size slide

  143. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    まとめ|実際
    143
    ・初期値のままでは、1万チケットまで
    ・最低限のチューニングで、10万チケットまで(最新のWindows Bitnami)
    ・最低限のチューニングで、15万チケットまで(Linux, MySQL, Windowsスクラッチ)
    ・ある程度のチューニングで、200万チケットまで(Linux, MySQL)
    ・最大限のチューニング (必要としてないので今はやっていない)
    処理並行度を上げる、高IOPsのDisk採用、DBMSのI/O最適化
    例)Linux, MySQL:
    Nginx + Unicorn
    ロードバランサ + WebAppServerクラスタリング
    + DBMSクラスタリングと、SQL ProxyによるR/W, R/Oの分離、SSD PCIe

    View full-size slide

  144. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    まとめ|限界
    144
    RedmineのFTS (非索引型)
    (Redmineは悪くないが)30万チケットを超えたあたりで検索が遅くなる。
    例えばCPU4コアで稼働している時に、全プロジェクト横断の検索が4回ク
    リックされ、並行で実行されるとCPUが占有されてRedmineが無応答になっ
    てしまう。
    また、 現在のSQL検索ではデータ量が増えると埋もれてしまい、探してい
    る情報がなかなか得られないという、検索精度の問題が明らかになった。
    今回、 Full Text Search Plugin の性能向上による高速化と、スコアベース検
    索による検索精度の改善が得られた。十分な性能を確認できたことから、検
    索に関する懸念要素が払拭された。
    現在4億5千万文字を記録・蓄積しており、今後も増加の一途にあるので、何
    らかの索引型FTSサポートがRedmineに必要(標準機能が最善)。

    View full-size slide

  145. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    まとめ|限界
    145
    Redmineのファイル内容 全文検索
    添付ファイルの内容検索がパッチとして提供されている(Planio提供 #306)が、
    大量の添付ファイルを検索対象とした場合、全文検索の性能は低いと予想される。
    想定される課題は3点:
    1)検索処理時間
    実運用環境の35万ファイルを使用して、全文検索(非索引型)の応答性能を計測
    すると、10億文字分の検索処理が長時間かかってしまい、日常的に使うには
    性能が不足するだろう。将来のデータ増加を最大200億文字と想定すると、
    このままでは厳しい。
    → Full Text Searchプラグインによる、検索機能の拡張開発「添付ファイ
    ルの索引型高速全文検索」により改善できる(もうすぐ)
    2)検索結果の精度
    SQL検索では探している情報が大量のデータに埋もれてしまうため、見つける
    までに時間がかかってしまう。
    → Full Text Searchプラグインによる、
    検索機能の拡張開発「高精度検索」により改善できる(予定)

    View full-size slide

  146. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    まとめ|限界
    146
    Redmineのファイル内容 全文検索
    3)リポジトリ内容の検索機能が無いため、ソースコード検索、ドキュメント検索
    ができず、効率が悪い。
    → Full Text Searchプラグインによる、検索機能の拡張開発「リポジトリ内容
    の索引型高速全文検索」により改善できる(予定)

    View full-size slide

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

    View full-size slide

  148. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録|性能関連設定の一覧
    148
    本稿で扱った性能ベンチ-マークは下記設定による。
    1. 計測プログラム
    2. Apache2.4, 2.2 HTTP/1.1 通信圧縮
    3. Passenger
    4. MySQL 5.7, 5.6 Linux, Bitnami
    5. Subversion キャッシュ設定, 通信圧縮
    6. Redmine Subversion同期 ProjectID指定
    7. Redmine OOBGC for Unicorn and Passenger
    8. OS File System
    設定値の一括ダウンロードはこちら (GitHub Gist)
    Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt
    https://gist.github.com/akahane92/771f9a52d81af9864dd8

    View full-size slide

  149. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録|計測方法
    149
    計測プログラム
    # bench.rb
    # -*- coding: utf-8 -*-
    rv = ARGV[0]
    cashmode = ARGV[1]
    url_list = [
    "/#{rv} ",
    "/#{rv}/projects ",
    "/#{rv}/projects/sscope ",
    "/#{rv}/issues?per_page=200 ",
    "/#{rv}/issues/1 ",
    "/#{rv}/issues/47548 ",
    "/#{rv}/issues/51782 ",
    "/#{rv}/projects/its-issues/wiki "
    ]
    puts "--- Environment ---"
    puts `httpd -version`
    puts `ruby -v`
    puts `gem list --local passenger`
    puts `export RAILS_ENV=production;
    /var/lib/its/#{rv}/script/about`
    puts `export RAILS_ENV=production;
    /var/lib/its/#{rv}/bin/about`
    puts `export RAILS_ENV=production; cd /var/lib/its/#{rv};
    bundle list`
    ti = 5
    result = []
    url_list.each { |url|
    rate_avg = 0
    ms_avg = 0
    puts "--- #{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 "#{cashmode} ¥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)"
    }

    View full-size slide

  150. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録|Apache2.4, 2.2
    150
    Apache2.4 /etc/httpd/conf.d/defelate.conf

    SetOutputFilter DEFLATE
    DeflateCompressionLevel 1
    DeflateMemLevel 8
    # LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
    # CustomLog /var/log/httpd/deflate_log deflate

    # MSIE masquerades as Netscape, but it is fine
    BrowserMatch ¥bMSIE¥s(7|8) !no-gzip !gzip-only-text/html
    FilterDeclare Compression CONTENT_SET
    FilterProvider 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 files
    SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|t?gz|zip|bz2|sit|rar|lzh|exe)$ dont-vary
    # Make sure proxies don't deliver the wrong content
    Header append Vary Accept-Encoding env=!dont-vary


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

    DeflateCompressionLevel 2
    # LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
    # CustomLog /var/log/httpd/deflate_log deflate

    # Netscape 4.x has some problems...
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    # Netscape 4.06-4.08 have some more problems
    BrowserMatch ^Mozilla/4.0[678] no-gzip
    # MSIE masquerades as Netscape, but it is fine
    BrowserMatch bMSIE !no-gzip !gzip-only-text/html
    FilterDeclare Compression CONTENT_SET
    FilterProvider Compression DEFLATE resp=Content-Type $text/html
    FilterProvider Compression DEFLATE resp=Content-Type $text/xml
    FilterProvider Compression DEFLATE resp=Content-Type $text/css
    FilterProvider Compression DEFLATE resp=Content-Type $text/plain
    FilterProvider Compression DEFLATE resp=Content-Type $image/svg+xml
    FilterProvider Compression DEFLATE resp=Content-Type $application/xhtml+xml
    FilterProvider Compression DEFLATE resp=Content-Type $application/xml
    FilterProvider Compression DEFLATE resp=Content-Type $application/rdf+xml
    FilterProvider Compression DEFLATE resp=Content-Type $application/rss+xml
    FilterProvider Compression DEFLATE resp=Content-Type $application/atom+xml
    FilterProvider Compression DEFLATE resp=Content-Type $text/javascript
    FilterProvider Compression DEFLATE resp=Content-Type $application/javascript
    FilterProvider Compression DEFLATE resp=Content-Type $application/x-javascript
    FilterProvider Compression DEFLATE resp=Content-Type $application/x-font-ttf
    FilterProvider Compression DEFLATE resp=Content-Type $application/x-font-otf
    FilterProvider Compression DEFLATE resp=Content-Type $font/truetype
    FilterProvider Compression DEFLATE resp=Content-Type $font/opentype
    FilterChain Compression
    # Don't append Vary heder for specific files
    SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|t?gz|zip|bz2|sit|rar|lzh|exe)$ dont-vary
    # Make sure proxies don't deliver the wrong content
    Header append Vary User-Agent env=!dont-vary
    Header append Vary Accept-Encoding env=!dont-vary


    1. HTTP/1.1 通信圧縮

    View full-size slide

  151. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録|Passenger
    151
    Apache2 /etc/httpd/conf.d/passenger.conf
    # Rails environment settings
    RailsEnv production
    # Multiple Redmine Envirnoment with Sub-URI
    RailsBaseURI /its26
    RailsBaseURI /its30
    RailsBaseURI /its31
    RailsBaseURI /its32
    RailsBaseURI /its33
    RailsBaseURI /its34
    RailsBaseURI /its40
    # 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 20
    PassengerMaxInstancesPerApp 4
    PassengerPoolIdleTime 3600
    PassengerHighPerformance on
    PassengerStatThrottleRate 10
    RailsSpawnMethod smart
    RailsAppSpawnerIdleTime 86400
    PassengerMaxPreloaderIdleTime 0
    # For OOBGC < Experimental >
    # PassengerSpawnMethod direct

    View full-size slide

  152. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録|MySQL 5.7
    152
    <続き>
    default_storage_engine = InnoDB
    explicit_defaults_for_timestamp = 1
    # For SSD
    innodb_flush_neighbors = 0
    #innodb_page_size = 4K
    innodb_io_capacity = 2000
    innodb_io_capacity_max = 6000
    innodb_lru_scan_depth = 2000
    # MySQL Server System Variables
    # http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html
    sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER
    join_buffer_size = 128M
    sort_buffer_size = 1M
    query_cache_type = 1
    query_cache_size = 128M
    query_cache_limit = 6M
    tmp_table_size = 512M
    max_heap_table_size = 1G
    read_rnd_buffer_size = 16M
    key_buffer_size = 32M
    max_allowed_packet = 16M
    read_buffer_size = 1M
    bulk_insert_buffer_size = 64M
    max_connections = 100
    character-set-server = utf8
    skip-external-locking
    thread_cache_size = max_connections/3
    table_open_cache = 4096
    table_open_cache_instances = 64
    performance_schema = OFF
    back_log = 50 + (max_connections / 5)
    expire_logs_days = 7
    open_files_limit = 65500
    max_prepared_stmt_count = 65528
    innodb_print_all_deadlocks = ON
    MySQL 5.7 my.cnf
    # For advice on how to change settings please see
    # http://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html
    [mysqld]
    init-connect = SET NAMES utf8
    default_password_lifetime = 0
    server-id = 1
    # InnoDB Paramaters
    # http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html
    innodb_buffer_pool_dump_at_shutdown = ON
    innodb_buffer_pool_load_at_startup = ON
    innodb_buffer_pool_size = 8G
    innodb_log_file_size = 4G
    innodb_log_buffer_size = 8M
    innodb_flush_log_at_trx_commit = 1
    innodb_log_files_in_group = 2
    innodb_thread_concurrency = 16
    innodb_concurrency_tickets = 5000
    innodb_old_blocks_time = 1000
    innodb_open_files = 300
    innodb_stats_on_metadata = 0
    innodb_checksum_algorithm = crc32
    innodb_max_dirty_pages_pct = 90
    innodb_lock_wait_timeout = 120
    innodb_print_all_deadlocks = ON
    innodb_data_file_path = ibdata1:10M:autoextend
    innodb_autoextend_increment = 64
    innodb_flush_method = O_DIRECT
    innodb_read_io_threads = 8
    innodb_write_io_threads = 8
    innodb_buffer_pool_instances = 8
    innodb_rollback_segments = 32

    View full-size slide

  153. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録|MySQL 5.6
    153
    <続き>
    default_storage_engine = InnoDB
    explicit_defaults_for_timestamp = 1
    # For SSD
    innodb_flush_neighbors = 0
    # MySQL Server System Variables
    # http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html
    sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
    join_buffer_size = 128M
    sort_buffer_size = 1M
    query_cache_type = 1
    query_cache_size = 128M
    query_cache_limit = 6M
    tmp_table_size = 512M
    max_heap_table_size = 1G
    read_rnd_buffer_size = 16M
    key_buffer_size = 32M
    max_allowed_packet = 16M
    read_buffer_size = 1M
    bulk_insert_buffer_size = 64M
    max_connections = 100
    character-set-server = utf8
    skip-external-locking
    thread_cache_size = max_connections/3
    table_open_cache = 4096
    table_open_cache_instances = 64
    performance_schema = OFF
    open_files_limit = 65500
    max_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.html
    innodb_buffer_pool_dump_at_shutdown = ON
    innodb_buffer_pool_load_at_startup = ON
    innodb_buffer_pool_size = 8G
    innodb_log_file_size = 4G
    innodb_log_buffer_size = 8M
    innodb_flush_log_at_trx_commit = 1
    innodb_log_files_in_group = 2
    innodb_thread_concurrency = 16
    innodb_concurrency_tickets = 5000
    innodb_old_blocks_time = 1000
    innodb_open_files = 300
    innodb_stats_on_metadata = 0
    innodb_checksum_algorithm = crc32
    innodb_file_format = Barracuda
    innodb_max_dirty_pages_pct = 90
    innodb_lock_wait_timeout = 120
    innodb_print_all_deadlocks = ON
    innodb_data_file_path = ibdata1:10M:autoextend
    innodb_autoextend_increment = 64
    innodb_flush_method = O_DIRECT
    innodb_read_io_threads = 8
    innodb_write_io_threads = 8
    innodb_buffer_pool_instances = 8
    innodb_rollback_segments = 32
    innodb_use_sys_malloc = 1

    View full-size slide

  154. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録|MySQL 5.6 for Bitnami
    154
    MySQL 5.6 my.cnf for Bitnami
    # The MySQL server
    [mysqld]
    # set basedir to your installation path
    basedir=C:/Bitnami/REDMIN~1.0-2/mysql
    # set datadir to the location of your data directory
    datadir=C:/Bitnami/REDMIN~1.0-2/mysql/data
    port=3306
    character-set-server=UTF8
    collation-server=utf8_general_ci
    max_allowed_packet=16M
    bind-address=127.0.0.1
    # The default storage engine that will be used when create new tables when
    default-storage-engine=INNODB
    #================================================================
    # InnoDB Paramaters
    # http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html
    innodb_buffer_pool_size = 2G
    innodb_log_file_size = 512M
    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
    #================================================================

    View full-size slide

  155. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録|Subversion キャッシュ&通信圧縮
    155
    Apache2.4, 2.2 /etc/httpd/conf.d/subversion.conf

    SVNCompressionLevel 1
    SVNInMemoryCacheSize 128000
    SVNCacheFullTexts on
    SVNCacheTextDeltas on

    View full-size slide

  156. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録| Redmine Subversion同期
    156
    Subversion Post-Commit-Hook - post-commit
    #!/bin/sh
    # Redmine のプロジェクト名とSubversionリポジトリ名が一致している条件下でのスクリプト
    # 名称不一致の場合、本スクリプト中に名称を指定すればよい。(数が多いと面倒なのでお勧めしません)
    # (APIKEYは、 $REPOSHOME/common/APIKEY というファイルに記述)
    export LANG="ja_JP.UTF8"
    REPOS="$1"
    REV="$2"
    # Send E-Mail
    ${REPOS}/hooks/commit-email.rb "$REPOS" "$REV"
    # Sync SVN Repo with ITS
    REPOSHOME=`/usr/bin/dirname $REPOS`
    APIKEY=`/bin/cat $REPOSHOME/common/APIKEY`
    PJNAME=`/bin/basename $REPOS`
    URL="http://localhost/its/sys/fetch_changesets?id=$PJNAME&key=$APIKEY"
    /usr/bin/wget -q --no-proxy $URL -O /dev/null

    View full-size slide

  157. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録| Redmine OOBGC for Unicorn
    157
    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+

    View full-size slide

  158. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録| Redmine OOBGC for Passenger
    158
    Passengerへの gctools導入
    ■About gctools
    Aman 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/src
    git clone https://github.com/shirosaki/gctools # For Ruby2.1
    # または
    git clone https://github.com/akahane92/gctools # For Ruby2.1, 2.2, 2.3
    gem build gctools.gemspec
    gem install gctools-0.2.3.gem
    ■Passengerとgctools を Gemfile.localに追記
    gem 'passenger'
    gem "gctools", '0.2.3'

    View full-size slide

  159. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録| Redmine OOBGC for Passenger
    159
    ■config.ru パッチ
    diff --git config.ru config.ru
    index 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

    View full-size slide

  160. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録| Redmine OOBGC for Passenger
    160
    Passengerへの gctools導入
    ■ /etc/httpd/conf.d/passenger.conf にOOBGC用の設定値を指定
    # For OOBGC < Experimental >
    PassengerSpawnMethod direct

    View full-size slide

  161. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved
    付録|OS File System
    161
    ■/etc/fstab
    /dev/mapper/vg_sms01-lv_root / ext4 defaults,nobarrier,noatime,discard 1 1
    UUID=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
    注意:ディスクにアクセスできなくなったり、システム・アプリケーションが正しく動作しなくなる危険性があります。
    バックアップを確保したうえで、理解できる方だけ自己責任でチャレンジしてください。
    危険性が高いわりに、性能向上は体感しにくいので、専門家以外には推奨しません。

    View full-size slide


  162. Special Thanks to
    ブログ等で技術情報を公開して下さったみなさま
    西川 撒さん
    My Family.

    View full-size slide