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の内部については、スライド上がったらリンク貼る
        • 本番稼働前に発覚したのが奇跡っぽいw(@yancya)
    • SELECT結果が違う
    • 根本原因を特定することが重要!
      • PostgreSQLのコードには親切なREADMEやコメントがあるので、助けに
      • コミュニティも力になってくれる!
  • ソースがあれば何とかなる

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

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


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




このエントリーをはてなブックマークに追加