2015/01/31

第31回(仮名)PostgreSQL勉強会に参加してきました！


いつになったら、(仮名)がとれるのか気になっている江川(@daiti0804)です。
1/31(土)に行われた第31回(仮名)PostgreSQL勉強会に参加してきました！


今回は、PostgreSQLの勉強会にも関わらず、MySQLの話も聞けちゃうお得な回になりました。知らないことを知るのは新鮮で楽しいですねー。
また、@nuko_yokohamaさんが中国地方DB勉強会にてご登壇。というわけで、まとめてくれる人がいなそうなのもあり、以下、本日のメモ書きをば。ちなみに少し遅刻しました。ごめんなさい。

MySQLのロックについて - Oracle ACE 平塚貞夫(sh2)氏

  • Oracle DB, PostgreSQLと対比させつつ、MySQLのロックの話を。
  • InnoDBでは、不可解なデッドロックが起きることがある(トランザクション分離レベルが"RepeatbleRead"のときの話)。
  • MySQLのつらいとこ
    1. ギャップロックで、コードとレコードの間がロックされるとこ
      • 「MySQLのギャップロックで泣いたことある人RT #jpug_study #俺はブチ切れたことがある」(@soudai1025)
    2. 合致したレコードではなく、走査したレコードに対してロックを取得するとこ
      • 「MySQLは操作したレコードにロックをかけるので、実行計画によってロック範囲が変わる！ これは厳しいな・・ 」（@kasa_zip）
  • READ COMMITEDを使いましょう
    • 「私、READ COMMITED普及委員会の人なので」
    • READ COMMITEDにしておけば、ギャップロック発生しない
    • 空振りでもギャップロックとらない
  • まとめ

プラクティカルなPostgreSQLチューニング - 喜田 紘介氏 (株アシスト)

  • 出だし、プラクティカルな映画の話して、会場が静まった気がするw
  • チューニングの種類
    • DBチューニング：パラメータチューニングetc
    • SQLチューニング：SQL修正、統計情報の調整etc
  • DBチューニング
    • キャッシュヒット率をあげよう、ディスクI/Oを減らそう
      • →OSが出してくれる情報を監視することが重要
    • 基本はパラメータ設定(postgresql.conf)！
      • アクセスデータ範囲をshared_buffersに収める
        • shared_buffers: 物理メモリの25〜40%程度
      • WAL生成のタイミングを知る。WALバッファがいっぱいになって、ディスクに書きにいくことを避ける
        • wal_buffers:16MB以上(推奨32MB)（旧バージョンの場合。最近のバージョンでは自動調整）
      • ディスクソートの発生を避ける
        • work_mem：SET文でセッションごとに適切な値を
          • trace_sortパラメータを有効にし、ログ出力からディスクソートがあったかを確認！
      • チェックポイント間隔の調整
        • クラッシュリカバリ時に許容できる時間を元に調整
        • checkpoint_segments:16個以上
        • checkpoint_timeout: 30分以上
      • VACUUM処理の調整
    • DBチューニングとっておきのツール！！
      •  pg_statsinfo：PostgreSQL統計情報収集/可視化ツール(9.4対応済み)
  • SQLチューニング
    • 実行時間が長いSQLが、レスポンス要件を満たすように改善！
    • ログ出力から実行時間の長いSQLを確認
      • log_min_durations：SQLの実行時間をログに記録
      • auto_explain：自動的に遅い文の実行計画をログに記録するcontribモジュール
    • 実行計画をよく見ましょう
      • PostgreSQLの計画タイプを覚えておきましょう！(@surumegohan)
      • たまに、nest_loop をoffって、巨大テーブルの結合をHash join or Merge join に倒して、バッチ系のチューニングをすることがありますね(@kasa_zip)
      • pg_hint_planなんてものもある
    • 高速化が期待される機能
    • PostgreSQL9.4での改善
      • WALロックの改善
      • hugepageへの対応
      • JSONB
      • GINの軽量・高速化
      • pg_prewarm
      • auto.conf
    • 堀川さんの質問：「shared_buffersを極端に多くすると、メモリ管理のオーバーヘッドが大きくなるので、注意と言っていたが、なぜ？」→「OS(Linux)の従来のページを扱うため、RDBMS側で多くのページ管理をすることにより、CPU負荷があがることがあるため。ただし、PostgreSQL9.4からLinuxのhugepageをサポートする！」

NTT データと PostgreSQL が挑んだ総力戦・カンファレンスで話せなかった裏話 - 笠原 辰仁氏 (NTTデータ)

  • まずは、PostgreSQLカンファレンス基調講演のダイジェスト
    • 今回は、某Web記事で講演してなかった人みたいになっていた@kasa_zipさんが一人で話すみたい。
    • エネルギー元売会社の情報系システム
      • 販売情報などをもとに、集計などをほぼリアルタイムで行う
      • OSSメイン & 拡張機能フル活用：商用システム初適用のものも
    • 大量SQLの死守
      1. SQLガイドライン
      2. SQLチェックツール：シンタックスチェック。
        • ブラウザでSQL書くと、 「XXだからNG」みたいなのが出る
      3. 実行計画チェックツール：EXPLAINをチェック！
        • 統計情報を偽装するのに、pg_dbms_statsを拡張して使用
        • 開発環境用に統計上をすげ替えて環境整えるとかDBエンジニア思いつくことすごいな。(@cstyles_jp)
      4. アジリティSQLチューニング
        • pg_hint_planを使用：単体テストのやり直ししなくていいので楽だった
      5. SQL書き換え
  • 今日の本題
    • SEGVでPostgreSQLが落ちた
      • コード解析した結果、pg_dbms_statsが誤った統計情報を返していた
      • pg_dbms_statsの内部については、スライド上がったらリンク貼る
        • 本番稼働前に発覚したのが奇跡っぽいｗ(@yancya)
    • SELECT結果が違う
    • 根本原因を特定することが重要！
      • PostgreSQLのコードには親切なREADMEやコメントがあるので、助けに
      • コミュニティも力になってくれる！
  • 「ソースがあれば何とかなる」

さて、飲み会に行ってくる！

懇親会
  • うぇーい
  • @fujii_masaoさんが育休中という話から、家庭生活話へ。
    • たなけんさんの「子ども二人目できると大変」だわー
    • 結婚のときに色々な契約をコミットするとツラいわー
    • 陰でこそっと言われるのツラいわー
    • 一馬力ツラいわー
    • とりあえず自由なのが一番
  • サポートではまるとツラいわー
  • JPUGなお話
    • マニュアル翻訳に対して、もう少し力入れた方がいいかなー
    • すそ野を広げる意味でも、初心者向け本やDB一般本の中でPostgreSQLを例にとるもの出したら
    • PostgreSQL徹底入門、そろそろ新版出した方がよいのでは？
    • 理事の若返りが求められる
  • pg_bigmとPGroongaのお話
  • textsearch_jaというか、形態素解析は需要ありますよー
  • 60歳越えてもコード書くのか論
  • 「ビールとソーセージ作って暮らしたいわー」（by @kasa_zipさん）
  • JPUG合宿を熱海でやるから来てねー(by @kkkida_twtrさん)
  • すき焼きー


次回は5月。久しぶりになにか話したくなってきたー









時刻: 0 件のコメント:
場所: 日本, 市ヶ谷駅（東京）
登録: 投稿 (Atom)