作業ログ(2009/11/14分)
- hbstudyに参加した(19:00-21:00)
以下,メモ
- PostgreSQL安定運用のコツ
- 資料 -> slideshare/uptimejp
- ps -a | cat | grep username
- 共有バッファ -> メモリ領域
- PostgreSQLの構成
- リスナ -> クライアントからの処理を待っているプロセス
- PostgreSQLのアーキテクチャ
- I/Oの制御をどうするかがパフォーマンスのポイント
- テーブルファイル
- インデックスファイル
- テーブルファイルの実レコードへのポインタ
- トランザクションログ
- なぜトランザクションログのみ16M?
- 発生するファイルI/O
- アクセスパターン
- シーケンシャルはよくない
- 共有バッファ
- あまりに大きかったり,小さかったりするとパフォーマンスに影響.
- デフォルトではかなり小さいそう.
- レコード量とデータサイズ
- シーケンシャルアクセスはレコード量に比例して遅くなる.
- > ユーザが増えた時に
- 初期設定
- 推奨 log_line_prefix -> ログ管理に必要
- QA -> 必須項目の決め方のガイドラインはあるか?
- たぶんないです.いろいろな要因があるため.
- shared_bufferはPostgreSQLのプロセス内で共有される.
- データベースの監視
- チューニングは人件費がかかる.ハードウェア増強の方がコストが低ければ要検討.
- 監視すべき項目とその方法
- QA -> ある関数はコンパイルしないと使えないのでは?
- PostgreSQL8.1ベースの話です.
- データベースサイズ、テーブルサイズの取得
- トランザクション量の取得
- 監視結果の可視化
- ビジュアライズするのが有効
- 有効にすべきGUC項目
- 性能劣化とメンテナンス
- 性能劣化の原因
- レコード数の増大、ユーザ数の増加,不要領域の増大
- PostgreSQLでは,更新しても内部的にはDelete + Insertしているので,レコードは増える.
- 不要領域のできる仕組み
- VACUUM処理 -> 再利用領域を確保するためのメンテナンスに使う
- 追記型アーキテクチャ
- insert, update, delete
- データファイル不要領域率の確認
- contrib -> ユーティリティツール
- 不要領域率とパフォーマンス
- 不要領域率が増えるとパフォーマンスも落ちる
- VACUUMとは
- REINDEXとは
- インデックスの再作成
- タプルの更新とインデックスの更新
- ホット? -> HOT(Heap Only Tuple)
- 8.3以降から,インデックスの張られているカラムのみインデックスサイズを増やす.
- その他の情報
- autovaccumは8.3からデフォルトオン
- PosgreSQL conference
- twitter -> uptimejp
- -
- Linux/MySQLサーバのパフォーマンスチューニング
- 今日のテーマ
- InnoDB(イノデービー)のブロック構造
- 例:Blogエントリ用テーブル
- 日記の特性 ->本文が
- どうやってレコードサイズを小さくするか?
- データ型
- biting -> 8byte
- datetime -> 8byte
- timestamp -> 4byte
- フラグ -> tinyint -> 1byte
- InnoDBのブロック/レコード構造
- overflow page 768byteより大きいデータは別ブロック
- 巨大なTEXT/BLOBはクエリ効率を悪化させる
- 読み出しはデータの小さいカラムであっても,読み込み単位がブロック単位なので,レコードがバッファプール上にロードされてしまう.
- > ディスクI/Oが発生する.
- 1:1関連を考える
- 正規化が崩れるので一般的には非推奨.
- テーブルサイズ
- 1:1関連は一般的にどうなのか
- 必要ない限り使うべきじゃない.
- 巨大な列の扱いを最適化してくれるストレージエンジン
- Falcon
- TEXT型の列を別領域に保存
- PBXT
- 一定以上の長さの列を別領域に保存する
- Falcon
- QA ->
- 非一意検索は意外と遅い
- HDDは1秒あたり数百回くらいしかランダムI/Oできない
- Covering Index(インデックスだけを読む検索)
- インデックスをデータの絞り込みに使わなくて
- LIMIT句
- 副作用としてレコードサイズが大きくなる,更新性能が落ちる.
- Linux上でのチューニング
- メモリ上へのキャッシュ効率を意識する
- OOM Killerに注意する
- 実プロセスがスワップアウトされることを防ぐ
- ファイルシステム
- 統計ツール
- sar
- vmstat
- mpstat(cpu core単位の不可状況)
- iostat
- iotop
- ネットワーク統計
- /proc/net/dev にインターフェイス毎の転送料が
- mtstat
- SSDはとても早い
- I/Oのランダムアクセス回数がHDDよりも早い.
- SSD製品を選ぶ時に注意したいこと
- 書き込み性能が製品によって差がある.
- 基本的に地雷
- ライトキャッシュ(書き込みをまとめて後でディスクに)
- キャパシタ
- 並列性が重要
- 思いバッチ処理の性能
- 1:1関連を考える
その後,カフェミヤマにて 22:00-24:00まで作業
- ATND検索をフレームワークを使って書き直しの続き
- デーモン君のソース探検を読む.UNIXコマンドのソースコードリーディングを題材に,BSDのソースを読むための手引きとのこと.C言語,大分忘れてました... その他,manの使い方など.
デーモン君のソース探検―BSDのソースコードを探る冒険者たちのための手引き書 (BSD magazine Books)
- 作者: 氷山素子
- 出版社/メーカー: アスキー
- 発売日: 2004/02
- メディア: 単行本
- 購入: 5人 クリック: 184回
- この商品を含むブログ (29件) を見る