トップ > log > 作業ログ(2009/11/14分)

作業ログ(2009/11/14分)

log
  • hbstudyに参加した(19:00-21:00)

以下，メモ

  • PostgreSQL安定運用のコツ
    • 資料 -> slideshare/uptimejp
    • ps -a | cat | grep username
    • 共有バッファ -> メモリ領域
  • PostgreSQLの構成
    • リスナ -> クライアントからの処理を待っているプロセス
  • PostgreSQLのアーキテクチャ
    • I/Oの制御をどうするかがパフォーマンスのポイント
  • テーブルファイル
  • インデックスファイル
    • テーブルファイルの実レコードへのポインタ
  • トランザクションログ
  • 発生するファイルI/O
  • アクセスパターン
    • シーケンシャルはよくない
  • 共有バッファ
    • あまりに大きかったり，小さかったりするとパフォーマンスに影響．
    • デフォルトではかなり小さいそう．
  • レコード量とデータサイズ
    • シーケンシャルアクセスはレコード量に比例して遅くなる．
  • > ユーザが増えた時に
  • 初期設定
    • 推奨 log_line_prefix -> ログ管理に必要
  • QA -> 必須項目の決め方のガイドラインはあるか？
    • たぶんないです．いろいろな要因があるため．
    • shared_bufferはPostgreSQLのプロセス内で共有される．
  • データベースの監視
    • チューニングは人件費がかかる．ハードウェア増強の方がコストが低ければ要検討．
  • 監視すべき項目とその方法
  • QA -> ある関数はコンパイルしないと使えないのでは?
    • PostgreSQL8.1ベースの話です．
  • データベースサイズ、テーブルサイズの取得
  • トランザクション量の取得
  • 監視結果の可視化
    • ビジュアライズするのが有効
  • 有効にすべきGUC項目
  • 性能劣化とメンテナンス
  • 性能劣化の原因
    • レコード数の増大、ユーザ数の増加，不要領域の増大
    • PostgreSQLでは，更新しても内部的にはDelete + Insertしているので，レコードは増える．
  • 不要領域のできる仕組み
    • VACUUM処理 -> 再利用領域を確保するためのメンテナンスに使う
  • 追記型アーキテクチャ
    • insert, update, delete
  • データファイル不要領域率の確認
  • 不要領域率とパフォーマンス
    • 不要領域率が増えるとパフォーマンスも落ちる
  • 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
          • 一定以上の長さの列を別領域に保存する
      • QA ->
    • 非一意検索は意外と遅い
      • HDDは1秒あたり数百回くらいしかランダムI/Oできない
    • Covering Index(インデックスだけを読む検索)
      • インデックスをデータの絞り込みに使わなくて
      • LIMIT句
      • 副作用としてレコードサイズが大きくなる，更新性能が落ちる．
    • Linux上でのチューニング
    • メモリ上へのキャッシュ効率を意識する
      • オンライン中にテーブルフルスキャン(バッチ処理等)をすると，それまでキャッシュされていたデータが追い出されてしまう...
      • InnoDBブロックのライフサイクル
      • old領域とyoung領域
    • OOM Killerに注意する
      • カーネルの機能
      • DB屋さん -> プロセスが死ぬくらいならスワップした方がマシという考え方
    • 実プロセスがスワップアウトされることを防ぐ
      • vm.swappiness
      • /proc/sys/vm/swappiness
    • ファイルシステム
    • 統計ツール
      • sar
      • vmstat
      • mpstat(cpu core単位の不可状況)
      • iostat
      • iotop
    • ネットワーク統計
    • SSDはとても早い
      • I/Oのランダムアクセス回数がHDDよりも早い．
    • SSD製品を選ぶ時に注意したいこと
      • 書き込み性能が製品によって差がある．
      • 基本的に地雷
      • ライトキャッシュ(書き込みをまとめて後でディスクに)
      • キャパシタ
      • 並列性が重要
    • 思いバッチ処理の性能
      • テーブルフルスキャン vs インデックススキャン(HDD)
      • SSDに適したファイルは位置
        • HDD -> シーケンシャルリード/ライト
        • SSD -> ランダムリード/ライトが得意
        • InnoDBの場合
        • random I/O
          • data file
          • undo log, insert buffer
        • sequential I/O
            • binaly log
            • innodb log file
            • doublewrite buffer
            • その他ログファイル
      • QA ->
      • レコード数だけでなく，データサイズを減らすことも重要．
      • マスターがスレーブよりも上のバージョンだとだめ

その後，カフェミヤマにて　22:00-24:00まで作業