本日、 世界は変わった。開発の現場はどうか？ Developers Summit 2010 に参加してきました。
- 開催概要：
- 会期： 2010年2月18日（木）・19日（金）
- 会場： 目黒雅叙園（東京・目黒）
- 主催： 株式会社 翔泳社
- 私が聴講してきたのは以下の 3 つのセッションです。
- [18-E-3] 高性能・安定運用のための Linux-DB システム構築/運用技術
- [18-E-4] データベースの品質を守る。- 22 年間のノウハウを終結させたデータベース開発・運用改善手法の紹介-
- [18-E-5] NoSQL を知る 〜kumofs から学ぶ Not only SQL の技術
- Speaker の方々の発表資料は、
404 error. Page Not Found.
に順次 Up されていくそうです。
以下より私が会場でとってきたメモの共有です。
[18-E-3] 高性能・安定運用のための Linux-DB システム構築/運用技術
当日使用資料： Linux/DB Tuning (DevSumi2010, Japanese)
私が有用だと思った情報
- メモリアロケータ
- メモリ割り当てに malloc() がつかわれる
- 使いこなしたいコマンド
- Oprofile
- どの関数が CPU リソースを使いきっているかを簡単に特定
- gdb
- デバッグツール
- 実行中のプロセスにおける全スレッドのスタックトレースをとることができる
- 対象プログラムにデバッグシンボルがあればよい
- SystemTap
- Speaker の松信さんの著書
| |
|
|
|
セッションメモ
- 安定稼動と高性能を支える
- アプリ、db、OS、HW
- 潜在的なリスクを予知し未然に防ぐ
- 運用経験を積めば積むほど力は上がる
- 愚者は経験にまなび、賢者は歴史にまなぶ
- 頭の隅においておきたい知識
- 考え方
- 問題の大半は disk io
- メモリアクセスですむならば問題にはならない
- disk io をいかに減らすか
- disk io が発生しないベンチマークだまされない。
- 製品の性質に目を向ける
- 品質の定量的な評価は難しい
- source レベルまでの解析は難しい
- GAの定義は製品によってまちまち
- 客観的視点に基づいていない
- 半年たてば安全の経験則
- 使われない機能はいつまでたっても使われない
- マーケティング上とりあえずつけてみた、みたいなもの
- 一般解を求めすぎない
- 汎用制を高くしようとすればするほど効率が悪くなる
- 社内標準
- utf8 消費バイト数が1.5〜2倍 マルチバイト文字の表現
- InnoDB が常に最適解ではない - MyISAM,NDB
- よいところよりも悪いところをみる
- 悪いクエリひとつですべてがとまる
- 毎秒100アクセス、10秒とまれば、1000セッションたまる
- ボトルネックになっていないところをどれだけ最適化しても全体のパフォーマンスはよくならない
- TOC
- DB以外にも目をむける
- 監視ツール
- アプリケーション
- HAソフト
- アプリの性質をある程度知っておく
- ORマッパーを使うことがおおくなった
- ユーザ数2倍!=CPU負荷2倍
- OSSを責任転嫁の道具に使わない
- 問題の答えをしるのにお金をつかうことはわるいことではない
- Linux のチューニングと安定運用
- メモリ
- DBサーバでもっとも重要な要素
- 32GB - 64GB
- Direct IO
- 2段階キャッシュから Direct IO
- 全部BUFFERで解決する
- innodb_flush_method=O_DIRECT
- 未サポート innoDB log, MyISAM
- スワップ制御とOOM Killer
- メモリをつかいきる
- スワップの効率は悪い
- ディスクにかいてよむ、無駄がおおい
- 処理はシングルスレッドで行われる
- スワップも使いきると
- OOM killer が動作
- 強制終了される
- たくさんのメモリをつかっているものとかをころす
- DRBD, Heartbeat
- OOM Killer が動作
- すぐにおわらない
- スワップを 0 にしてはいけない
- スワップを調整する
- スワップは必要
- DBサーバのメモリ使用
- DB本体
- 管理操作 - バックアップ
- vm.swappiness=0
- 実メモリをつかいきったときにファイルシステムキャッシュを優先的にきりすてる
- メモリアロケータ
- メモリ割り当てに malloc() がつかわれる
- tcmalloc 高速なメモリアロケータの利用
- innodb plugin
- innodb_use_sys_malloc=1
- LD_LIBRARY_PATH,LD_PRELOAD で指定 tc_malloc
- IOスケジューラ
- 例えるなら エレベータ
- スケジューラの種類とキューのサイズ
- DBにまかせたほうがよいケースがおおい
- cfq - default
- noop, deadline
- InnoDB
- MySQL 5.4 裏でうごいている thread 16
- MySQL 5.1 thread 2
- MyISAM
- IO のキューを内部で調整する仕組みをもっていない
- OSとストレージに影響受ける
- FileSystem
- root と data はわける
- ext3
- 圧倒的に使われている
- 特別な事情がなければこれをつかう
- 欠点
- large file の削除に時間がかかる
- mutex の競合が起こってしまう
- 同じファイルに並列で書き込むことができない
- 大量のファイル dir_index で最適化
- ジャナリングモード
- データを上書き途中でcrashしたときに中途半端な書き込み状態になってしまう可能性
- OS に任せる場合はつかう
- xfs
- ext2
- btrfs - developing now
- ファイル IO と同期書き込み
- ストレージを有効に使う
- RAID コントローラ
- 上書きと追記の違いに注意
- 追記のほうがずっと遅い
- ファイルメタデータの更新も必要
- sync_binlog 追記の同期書き込みになる
- 使いこなしたいコマンド
- iostat
- iostat -x
- r/s w/s svctm %util に注目
- %util = (r/s+w/s) / svctm
- mpstat
- cpu のコア単位での統計
- vmstat は平均値
- ひとつのコアが100% だったとしてもそれがわからない
- Oprofile
- どの関数が CPU リソースを使いきっているかを簡単に特定
- opcontroll
- opreport
- gdb
- デバッグツール
- 実行中のプロセスにおける全スレッドのスタックトレースをとることができる
- 対象プログラムにデバッグシンボルがあればよい
- gdb によるスタックトレース
- 接続数が跳ね上がったときだけ取得するような仕組み
- gdb で thread の dump をとっていき
- 毎回同じ thread がとまっているところをつきとめる
- thread_cache
- pthread_create
- SystemTap
- Solaris の Dtrace に該当するもの
- DWARF デバッグシンボルのあるプログラムなら
- MySQL の sort
- 旧型方式
- 新型方式
- どちらを選択したか MySQL の管理コマンドではわからない
- rr_from_pointer
- rr_unpack_from_buffer
- それぞれの数をかぞえるスクリプト
- ネットワークと DB接続
- Non Pconnect
- Pconnect
- カーネルパニックと HA 構成
[18-E-4] データベースの品質を守る。- 22 年間のノウハウを終結させたデータベース開発・運用改善手法の紹介-
私が有用だと思った情報
- Toad World (Blog) の紹介
http://www.toadworld.com/
Toad for Oracle のツール紹介だけでなく、 DB のコアなエンジニアが個々人の知見の共有をしてくれている。セッションメモ
- ソフトウェアのテストをずっとやってきた
- ソフトウェア品質
- クエストソフトウェア
- ソフトウェアの品質は確率でないと語れない
- 不確かさ
- 開発-> テスト-> デバッグ に追われる
- 忙しい開発者
- ソフトウェアの完全性は No
- 動かなくても保証しませんといっている -> 米ソフトウェア業界
- よいアプリケーション
- 正確
- 仕様
- Bug
- 効率
- 目的を効率的に行える
- 性能
- 運用効率
- 今日も明日も1年後も動く
- 誰でも修正できる
- 高品質なアプリをつくる
- Test するしかない
- Source
- System
- 本番レベル
- テストが効率の鍵 # GARTNER GROUP
- 65% Debug
- 25% Proof Read
- 10% Cording
- Code Level でのテストの課題
- テスト量の多さ
- 1 step に 10 step のテストコード
- 複雑なテストはあとまわし
- 手動でのテスト
- 1回ごとに確認
- 再利用
- プログラム変更->テストコードの変更
- テスト、当事者がどのように考えるかに依存
- テストが効率化できたら、すばらしいとおもわないか
- テストの標準化
- V字型開発モデル
- 開発の標準化はテストの標準化
- 方法論だけではうまくいかない
- 方法論をバックアップするのがツール
- いい方法論は多くのツールに組み込まれていることがおおい。
- テスト環境で流しても、本番で遅いクエリが速いことがある
- テストの自動化
- SQLのパフォーマンスとスケーラビリティ
- コードの妥当性
- レポート
- SQL チューニングの課題
- 最適な SQL を証明すること->不可能
- SQL の性能 -> 本番直前までテストされない
- SQL が正しい結果を返すこと != 文法が正しい
と思うこと- システムボトルネックを見つけるスペシャリストはすくない現状
- スペシャリストではなくジェネラリスト
- 迅速にボトルネックのきりわけをできるようになる
- Toad for Oracle の紹介
- テストの自動化
- ボトルネックの検出
- SQL の検証
- Toad for MySQL もある
- Toad World
- Community Knowledge Power
- DB の Expert が集まっている
- このサイトはみんなに役立つ
- ブログは創立10年
- Spotlight On Oracle
- ボトルネックを発見するツール
- ダウンロードできるから使ってみてね
- SQL Optimizer for Oracle
- Oracle とは異なるアルゴリズム
- 実行ボタンを押すと実行してしまう
- 影響分析
- JProbe + Toad
- 性能チェック
- メモリーチェック
- SQL Optimizer for Oracle の体験セミナー
- 2hour 無料の体験セミナー
- 100305
- 今日紹介したツールはダウンロード可
- 検証、評価可能
[18-E-5] NoSQL を知る 〜kumofs から学ぶ Not only SQL の技術
当日使用資料：NoSQLを知る
私が有用だと思った情報
- 未来を予測する最善の方法は、自らそれを創りだすことである (アラン・ケイ)
- CAP 定理
- Consistency / Availbility / Partioning Toleranceの最大でも2つまでしか担保できない
- kumofs
- 耐障害性
- 3 重化
- 超高速
- スケールアウト
- mencashed にせまる性能
- 動的な運用
- 構成
- 3台必要
セッションメモ
- twitterID: @frsyuki
- ハッシュタグ: #kumofs
- 分散 keyvalue store
- 座右の銘
- 未来を予測する最善の方法は、自らそれを創りだすことである (アラン・ケイ)
- VIVER
- ネットワークをインストール
- ネットワークブート
- ブートメディアを変えることでシステム一式を変更できる
- RUNES
- ネットワークブートのデメリットを解消
- ちょっとした変更を容易にできるようにする
- V-FIELD
- 分散ディスク共有システム
- 締め切り効果
- source をかくスピードが急速にUp
- kumofs えとらぼアルバイト
- NoSQL とは？
- 3層モデル
- appはスケールアウト容易
- DB sharding
- アトミックな更新できない
- joinできない
- RDBMS の不得意を補完するもの -> NoSQL
- スケーラビリティ
- 利用者や仕事の増大に適応できる能力
- 拡張性
- ユーザ
- データ
- サーバ
- 増える
- サーバおちる、運用コスト大、可用性さがる
- 後から拡張可能、負荷が増えたら拡張
- 拡張して適応
- スケールアップ×スケールアウト
- スケールアップ
- サーバの置き換え
- 指数関数的に価格が増大
- 性能向上に限界
- 負荷の見積もりが必須
- スケールアウト
- 負荷にみあった価格
- 最小限のコスト
- ソフトに依存->性能向上
- 負荷が増えたら拡張
- 可用性
- サーバが増えると可用性がおちる
- サーバを多重化することで解決
- サーバ台数が増えても管理コストがかからない？
- 一括管理システム
- 一人の人間がすべてのサーバを管理しなければならないような状況はつくらない
- NoSQL の技術
- CAP 定理
- Consistency / Availbility / Partioning Toleranceの最大でも2つまでしか担保できない
- Availability
- 快適なな利用
- Consistency
- Atomic に書き換え可能
- どちらも変更/どちらも更新されない
- Partitioning Tolerance
- 実装上のジレンマの説明
- Eventually Consistents
- Atomic Data Object
製品によりどのように定義するかことなる
- key → kumofs
- ROW → Google.Bigtable
- どのサーバに分散データStoreするのか
- Consistent Hashing
- サーバごとの担当範囲
- ノードの追加
- データの移動中
- get は失敗する->既存のノードがらとるようにする
- set は実行される
- kumofs
- 耐障害性
- 3 重化
- 超高速
- スケールアウト
- mencashed にせまる性能
- 動的な運用
- 構成
- 3台必要
- manager -> state less
- server
- gateway -> app から要求受け取る
- gateway
- memcached プロトコル実相
- memcachdサーバにみえるアプリからは
- messagepack-rpc
- 高速RPCライブラリ
- 多言語対応
- 非同期・並列処理
- 管理ツール
- Ruby
- kumoctl, kumotop, kumostat, kumosum
