SlideShare a Scribd company logo
1 of 45
Download to read offline
情報システム部門の
タスク管理
~ ITS応答性能の調査結果と対策 編~
Shimadzu Business Systems
2012/10/20 ITS事務局 赤羽根© 島津ビジネスシステムズ
※最新情報を反映したスライドをUploadしました。以下のURLをご参照ください。 

Redmineチューニングの実際と限界 (2016-03)
http://www.slideshare.net/kakahane/redmine-48214015

旧資料(2013-10)

Redmine + MySQL 応答性能の調査結果と対策

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

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

    再起動時に全Restoreすることで暖気運転が不要となり、本来性能を即座に引き出せる」
     https://twitter.com/search/realtime?q=%23mysql_osaka&src=hash
 2)更なるチューニング例 ( @kazeburo さん )
  https://github.com/kazeburo/mysetup/tree/master/mysql
  http://blog.nomadscafe.jp/2012/10/mysql-mycnf-github.html
■Redmine1.4 → 2.x アップデートによる処理遅延原因の推測
 3) http://www.slideshare.net/slideshow/embed_code/13718690?rel=0&startSlide=51
  A) RoR3のStack増によるGC問題( http://bibwild.wordpress.com/2011/07/12/more-thoughts-on-unbearably-slow-rails3/ )
  B) RedmineのRoR3への最適化対応が手付かずな点(@marutosijp, 38:50, 品川Redmine USTream )が原因
   だろうか。
■HTTP Server:なぜ、NginxではなくApacheなのか。
 4)NginxとUnicornの組み合わせが速いとの報告がありますが、当方環境の都合でApach2にしました。
   なぜならば、Subversionをはじめとする複数のサービスがApacheに依存しているからです。
巻末注記2
協 力
島津ビジネスシステムズ
43
Thanks to 西川 撤 / @mirakui / @Secondlife / Kyoto.rb / @beco_ippei
MySQL大阪勉強会 / Oracle / @kazeburo
Shimadzu Business Systems
島津製作所のご紹介
 
 島津製作所グループ
  事業領域
   ・分析計測
   ・医用機器
   ・航空機器
   ・半導体機器
   ・油圧, 光学
44
Shimadzu Business Systems
45
ご清聴
ありがとう
ございました

More Related Content

Viewers also liked

チケット駆動開発導入のヒント - 自律と規律 -
チケット駆動開発導入のヒント - 自律と規律 -チケット駆動開発導入のヒント - 自律と規律 -
チケット駆動開発導入のヒント - 自律と規律 -Makoto SAKAI
 
RedmineへのContributeとビジネス展開
RedmineへのContributeとビジネス展開RedmineへのContributeとビジネス展開
RedmineへのContributeとビジネス展開Go Maeda
 
Remineチョット入門
Remineチョット入門Remineチョット入門
Remineチョット入門Makoto SAKAI
 
ソフトウェアの品質向上に資する開発・運用現場の情報管理 ∼現場主導によるITS導入∼( #JaSSTKansai #RxTstudy9 @akahane92 )
ソフトウェアの品質向上に資する開発・運用現場の情報管理 ∼現場主導によるITS導入∼( #JaSSTKansai #RxTstudy9 @akahane92 )ソフトウェアの品質向上に資する開発・運用現場の情報管理 ∼現場主導によるITS導入∼( #JaSSTKansai #RxTstudy9 @akahane92 )
ソフトウェアの品質向上に資する開発・運用現場の情報管理 ∼現場主導によるITS導入∼( #JaSSTKansai #RxTstudy9 @akahane92 )Kuniharu(州晴) AKAHANE(赤羽根)
 
プロジェクトを成功させるチケット管理
プロジェクトを成功させるチケット管理プロジェクトを成功させるチケット管理
プロジェクトを成功させるチケット管理Makoto SAKAI
 
Redmineチケットによるプロジェクト火消し戦略!
Redmineチケットによるプロジェクト火消し戦略!Redmineチケットによるプロジェクト火消し戦略!
Redmineチケットによるプロジェクト火消し戦略!TrinityT _
 
アイドルソング制作の工程管理
アイドルソング制作の工程管理アイドルソング制作の工程管理
アイドルソング制作の工程管理Motokazu Sekine
 
Remineを活かしたプロセス支援 - 失敗しないプロセス支援 -
Remineを活かしたプロセス支援 - 失敗しないプロセス支援 -Remineを活かしたプロセス支援 - 失敗しないプロセス支援 -
Remineを活かしたプロセス支援 - 失敗しないプロセス支援 -Makoto SAKAI
 
Redmineによるwebサポート窓口の実装と運用
Redmineによるwebサポート窓口の実装と運用Redmineによるwebサポート窓口の実装と運用
Redmineによるwebサポート窓口の実装と運用Go Maeda
 
Redmineによるメール対応管理の運用事例
Redmineによるメール対応管理の運用事例Redmineによるメール対応管理の運用事例
Redmineによるメール対応管理の運用事例Go Maeda
 

Viewers also liked (11)

チケット駆動開発導入のヒント - 自律と規律 -
チケット駆動開発導入のヒント - 自律と規律 -チケット駆動開発導入のヒント - 自律と規律 -
チケット駆動開発導入のヒント - 自律と規律 -
 
RedmineへのContributeとビジネス展開
RedmineへのContributeとビジネス展開RedmineへのContributeとビジネス展開
RedmineへのContributeとビジネス展開
 
Remineチョット入門
Remineチョット入門Remineチョット入門
Remineチョット入門
 
ソフトウェアの品質向上に資する開発・運用現場の情報管理 ∼現場主導によるITS導入∼( #JaSSTKansai #RxTstudy9 @akahane92 )
ソフトウェアの品質向上に資する開発・運用現場の情報管理 ∼現場主導によるITS導入∼( #JaSSTKansai #RxTstudy9 @akahane92 )ソフトウェアの品質向上に資する開発・運用現場の情報管理 ∼現場主導によるITS導入∼( #JaSSTKansai #RxTstudy9 @akahane92 )
ソフトウェアの品質向上に資する開発・運用現場の情報管理 ∼現場主導によるITS導入∼( #JaSSTKansai #RxTstudy9 @akahane92 )
 
プロジェクトを成功させるチケット管理
プロジェクトを成功させるチケット管理プロジェクトを成功させるチケット管理
プロジェクトを成功させるチケット管理
 
Redmineチケットによるプロジェクト火消し戦略!
Redmineチケットによるプロジェクト火消し戦略!Redmineチケットによるプロジェクト火消し戦略!
Redmineチケットによるプロジェクト火消し戦略!
 
アイドルソング制作の工程管理
アイドルソング制作の工程管理アイドルソング制作の工程管理
アイドルソング制作の工程管理
 
Remineを活かしたプロセス支援 - 失敗しないプロセス支援 -
Remineを活かしたプロセス支援 - 失敗しないプロセス支援 -Remineを活かしたプロセス支援 - 失敗しないプロセス支援 -
Remineを活かしたプロセス支援 - 失敗しないプロセス支援 -
 
運用業務でのRedmine
運用業務でのRedmine運用業務でのRedmine
運用業務でのRedmine
 
Redmineによるwebサポート窓口の実装と運用
Redmineによるwebサポート窓口の実装と運用Redmineによるwebサポート窓口の実装と運用
Redmineによるwebサポート窓口の実装と運用
 
Redmineによるメール対応管理の運用事例
Redmineによるメール対応管理の運用事例Redmineによるメール対応管理の運用事例
Redmineによるメール対応管理の運用事例
 

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

バックアップ時の問題から学んだDBエンジニアに必要なスキルとは
バックアップ時の問題から学んだDBエンジニアに必要なスキルとはバックアップ時の問題から学んだDBエンジニアに必要なスキルとは
バックアップ時の問題から学んだDBエンジニアに必要なスキルとはTakeshiYamamoto2049
 
アドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニングアドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニングYosuke Mizutani
 
Hyper-V エンタープライズ設計の現実解:2015 年版
Hyper-V エンタープライズ設計の現実解:2015 年版Hyper-V エンタープライズ設計の現実解:2015 年版
Hyper-V エンタープライズ設計の現実解:2015 年版Daichi Ogawa
 
IBM Cloud Community Summit JIMUC 活動のご紹介
IBM Cloud Community Summit JIMUC 活動のご紹介IBM Cloud Community Summit JIMUC 活動のご紹介
IBM Cloud Community Summit JIMUC 活動のご紹介kazuki masuda
 
[db tech showcase Tokyo 2017] E24: 流行りに乗っていれば幸せになれますか?数あるデータベースの中から敢えて今Db2が選ば...
[db tech showcase Tokyo 2017] E24: 流行りに乗っていれば幸せになれますか?数あるデータベースの中から敢えて今Db2が選ば...[db tech showcase Tokyo 2017] E24: 流行りに乗っていれば幸せになれますか?数あるデータベースの中から敢えて今Db2が選ば...
[db tech showcase Tokyo 2017] E24: 流行りに乗っていれば幸せになれますか?数あるデータベースの中から敢えて今Db2が選ば...Insight Technology, Inc.
 
CPU / GPU高速化セミナー!性能モデルの理論と実践:理論編
CPU / GPU高速化セミナー!性能モデルの理論と実践:理論編CPU / GPU高速化セミナー!性能モデルの理論と実践:理論編
CPU / GPU高速化セミナー!性能モデルの理論と実践:理論編Fixstars Corporation
 
Wot2015 微博平台护城河-构建高效的防御体系-王关胜
Wot2015 微博平台护城河-构建高效的防御体系-王关胜Wot2015 微博平台护城河-构建高效的防御体系-王关胜
Wot2015 微博平台护城河-构建高效的防御体系-王关胜Weibo Corporation
 
Db2 Warehouse on Cloud Flex ご紹介資料 2020年3月版
Db2 Warehouse on Cloud Flex ご紹介資料 2020年3月版Db2 Warehouse on Cloud Flex ご紹介資料 2020年3月版
Db2 Warehouse on Cloud Flex ご紹介資料 2020年3月版IBM Analytics Japan
 
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナーIMJ Corporation
 
Redshift Spectrumを使ってみた話
Redshift Spectrumを使ってみた話Redshift Spectrumを使ってみた話
Redshift Spectrumを使ってみた話Yoshiki Kouno
 
Microsoft Seminar: Design Optimization on Rescale
Microsoft Seminar: Design Optimization on RescaleMicrosoft Seminar: Design Optimization on Rescale
Microsoft Seminar: Design Optimization on RescaleRescale Japan株式会社
 
[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太
[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太
[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太Insight Technology, Inc.
 
第16回「エキスパート・インテグレーテッド・システム『IBM PureSystems』の価値」(2012/04/19 on しすなま!)
第16回「エキスパート・インテグレーテッド・システム『IBM PureSystems』の価値」(2012/04/19 on しすなま!)第16回「エキスパート・インテグレーテッド・システム『IBM PureSystems』の価値」(2012/04/19 on しすなま!)
第16回「エキスパート・インテグレーテッド・システム『IBM PureSystems』の価値」(2012/04/19 on しすなま!)System x 部 (生!) : しすなま! @ Lenovo Enterprise Solutions Ltd.
 
System Centerで変わる運用
System Centerで変わる運用System Centerで変わる運用
System Centerで変わる運用Masahiko Ebisuda
 
201110 01 Polytech Center 1
201110 01 Polytech Center 1201110 01 Polytech Center 1
201110 01 Polytech Center 1openrtm
 
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」Rescale Japan株式会社
 
オブジェクトストレージの適用領域とCloudianの位置づけ (Cloudian Summit 2012)
オブジェクトストレージの適用領域とCloudianの位置づけ (Cloudian Summit 2012)オブジェクトストレージの適用領域とCloudianの位置づけ (Cloudian Summit 2012)
オブジェクトストレージの適用領域とCloudianの位置づけ (Cloudian Summit 2012)CLOUDIAN KK
 
セミナ受講レポート NRI Senju V12
セミナ受講レポート NRI Senju V12セミナ受講レポート NRI Senju V12
セミナ受講レポート NRI Senju V12Yukio Saito
 

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

バックアップ時の問題から学んだDBエンジニアに必要なスキルとは
バックアップ時の問題から学んだDBエンジニアに必要なスキルとはバックアップ時の問題から学んだDBエンジニアに必要なスキルとは
バックアップ時の問題から学んだDBエンジニアに必要なスキルとは
 
アドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニングアドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニング
 
Hyper-V エンタープライズ設計の現実解:2015 年版
Hyper-V エンタープライズ設計の現実解:2015 年版Hyper-V エンタープライズ設計の現実解:2015 年版
Hyper-V エンタープライズ設計の現実解:2015 年版
 
IBM Cloud Community Summit JIMUC 活動のご紹介
IBM Cloud Community Summit JIMUC 活動のご紹介IBM Cloud Community Summit JIMUC 活動のご紹介
IBM Cloud Community Summit JIMUC 活動のご紹介
 
[db tech showcase Tokyo 2017] E24: 流行りに乗っていれば幸せになれますか?数あるデータベースの中から敢えて今Db2が選ば...
[db tech showcase Tokyo 2017] E24: 流行りに乗っていれば幸せになれますか?数あるデータベースの中から敢えて今Db2が選ば...[db tech showcase Tokyo 2017] E24: 流行りに乗っていれば幸せになれますか?数あるデータベースの中から敢えて今Db2が選ば...
[db tech showcase Tokyo 2017] E24: 流行りに乗っていれば幸せになれますか?数あるデータベースの中から敢えて今Db2が選ば...
 
CPU / GPU高速化セミナー!性能モデルの理論と実践:理論編
CPU / GPU高速化セミナー!性能モデルの理論と実践:理論編CPU / GPU高速化セミナー!性能モデルの理論と実践:理論編
CPU / GPU高速化セミナー!性能モデルの理論と実践:理論編
 
Wot2015 微博平台护城河-构建高效的防御体系-王关胜
Wot2015 微博平台护城河-构建高效的防御体系-王关胜Wot2015 微博平台护城河-构建高效的防御体系-王关胜
Wot2015 微博平台护城河-构建高效的防御体系-王关胜
 
Db2 Warehouse on Cloud Flex ご紹介資料 2020年3月版
Db2 Warehouse on Cloud Flex ご紹介資料 2020年3月版Db2 Warehouse on Cloud Flex ご紹介資料 2020年3月版
Db2 Warehouse on Cloud Flex ご紹介資料 2020年3月版
 
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
【IMJ】デジタルマーケティングを加速させるヒントがここに imj jelly cms 事例活用セミナー
 
Redshift Spectrumを使ってみた話
Redshift Spectrumを使ってみた話Redshift Spectrumを使ってみた話
Redshift Spectrumを使ってみた話
 
Microsoft Seminar: Design Optimization on Rescale
Microsoft Seminar: Design Optimization on RescaleMicrosoft Seminar: Design Optimization on Rescale
Microsoft Seminar: Design Optimization on Rescale
 
[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太
[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太
[db tech showcase Tokyo 2015] D35:高トランザクションを実現するスケーラブルRDBMS技術 by 日本電気株式会社 並木悠太
 
第16回「エキスパート・インテグレーテッド・システム『IBM PureSystems』の価値」(2012/04/19 on しすなま!)
第16回「エキスパート・インテグレーテッド・システム『IBM PureSystems』の価値」(2012/04/19 on しすなま!)第16回「エキスパート・インテグレーテッド・システム『IBM PureSystems』の価値」(2012/04/19 on しすなま!)
第16回「エキスパート・インテグレーテッド・システム『IBM PureSystems』の価値」(2012/04/19 on しすなま!)
 
System Centerで変わる運用
System Centerで変わる運用System Centerで変わる運用
System Centerで変わる運用
 
201110 01 Polytech Center 1
201110 01 Polytech Center 1201110 01 Polytech Center 1
201110 01 Polytech Center 1
 
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
セミナー資料 2017年1月27日開催「クラウドCAEフェスティバル」
 
お客様が望んでいるモダンデスクトップアプリとは?/傾向と対策 Part1
お客様が望んでいるモダンデスクトップアプリとは?/傾向と対策 Part1お客様が望んでいるモダンデスクトップアプリとは?/傾向と対策 Part1
お客様が望んでいるモダンデスクトップアプリとは?/傾向と対策 Part1
 
オブジェクトストレージの適用領域とCloudianの位置づけ (Cloudian Summit 2012)
オブジェクトストレージの適用領域とCloudianの位置づけ (Cloudian Summit 2012)オブジェクトストレージの適用領域とCloudianの位置づけ (Cloudian Summit 2012)
オブジェクトストレージの適用領域とCloudianの位置づけ (Cloudian Summit 2012)
 
セミナ受講レポート NRI Senju V12
セミナ受講レポート NRI Senju V12セミナ受講レポート NRI Senju V12
セミナ受講レポート NRI Senju V12
 
20121126 flex pure_ws2012
20121126 flex pure_ws201220121126 flex pure_ws2012
20121126 flex pure_ws2012
 

Recently uploaded

SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する       2024/04/19 の勉強会で発表されたものですSOPを理解する       2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものですiPride Co., Ltd.
 
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNetToru Tamaki
 
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By DanielPostman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Danieldanielhu54
 
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)Hiroki Ichikura
 
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略Ryo Sasaki
 
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A surveyToru Tamaki
 
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...Toru Tamaki
 
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介Yuma Ohgami
 
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムスマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムsugiuralab
 
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdfTSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdftaisei2219
 

Recently uploaded (10)

SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する       2024/04/19 の勉強会で発表されたものですSOPを理解する       2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
 
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
 
Postman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By DanielPostman LT Fukuoka_Quick Prototype_By Daniel
Postman LT Fukuoka_Quick Prototype_By Daniel
 
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
 
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
 
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
 
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
 
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
 
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システムスマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
 
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdfTSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
 

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

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