Posts Tagged ‘fac2010’

    はてなブックマーク - PostgreSQL の VACUUM をなんとなくでするのはやめよう
    このエントリーをはてなブックマークに追加

    はじめての人もそうでない人もはじめまして。 河野と申します。

    いきなりすいません・・・。

    私の名前をさっそく覚えていただいた方には申し訳ないのですが、
    弊社にはもう一人河野というものがおり、そっちとは違う方と覚えて頂けると溜飲が下がります…。

    さて、今回 Fusic Advent Calendar の一番槍として最初に寄稿させて頂くことになりました。

    本日はお題の通り PostgreSQL の VACUUM をなんとなくでするのはやめようという提案を、全国 4,000万の VACUUM ファンの皆様にしたいと思います。

    尚、PostgreSQLの対応バージョンは 8.3 以降となります。

    PostgreSQL のメンテナンスと VACUUM

    データベースに PostgreSQL を採用している会社はどのくらいあるのでしょう?
    オープンソースのデータベースでは MySQL が多く採用されているイメージがありますが、弊社では以前より PostgreSQL を使用しシステム開発を行なっています。

    そんなこんなで PostgreSQL のメンテナンス業務などで VACUUM を実行する場面が私は何度かあるのですが、同じようにメンテナンスをされてる皆様は漫然と VACUUM を実行していませんでしょうか?

    VACUUM とは不要になった領域の回収を行うコマンドです。
    PostgreSQL は追記型のデータベースのためレコードの削除時はもちろん、更新時にも不要な領域が溜まっていきます。
    不要な領域が溜まっていくと、データベースのパフォーマンスが落ちていきます。
    そうなる前に PostgreSQL 好きの皆さんは VACUUM を実行してパフォーマンスをあげたいなと思いますよね?

    でも、ちょっと待って!
    あなたが VACUUM を実行するその時、それが VACUUM のタイミングなのでしょうか?

    VACUUM 前にチェック! 不要領域はどれぐらいあるの?

    PostgreSQL 8.3 からは、不要になった領域をSQLで確認することが可能となりました。
    ここでは pgAdmin を使って不要な領域、デッドタプルを確認したいと思います。

    データベースに接続して…テーブルを選んで…統計情報タブを選択する…以上。

    簡単ですね。 これで不要な行がどの程度あるのか確認することが可能です。
    23699行のデッドタプルがあることが分かりました。

    このテーブルの有効タプルが 454340行 そのうち 23699 行が不要なデッドタプルです。
    有効タプルに対して大体 5% が不要な領域として使用されている事がわかります。

    ちなみにSQLではこのように…。

    
    SELECT
        relname, n_live_tup, n_dead_tup, round(n_dead_tup*100/n_live_tup,2) AS ratio
    FROM
        pg_stat_user_tables WHERE relname = 'テーブル名';
    
     relname | n_live_tup | n_dead_tup | ratio
    ------------+------------+------------+-------
     テーブル名 |     454340 |      23699 |  5.00
    

    実際に確認してみますと、更新の多いテーブルほど n_dead_tup デッドタプルが多いことが分かるかと思います。
    そのデッドタプルが多く有効なレコードに対する割合の多いテーブルほど VACUUM すべきなのです!

    VACUUM を行ないましょう

    5%程でしたら VACUUM を実行するほどではないかもしれませんw
    (統計情報の更新や btree インデックスの不要領域の回収も行なうため実行した方がよいです。)
    むしろこのエントリーの本題は先ほどの”確認する”という部分なので、後はおまけみたいなものなのですが…
    VACUUM を実行してすっきりしたテーブルを見て心までまですっきりするために VACUUM を行なってみましょう。

    ここでも pgAdmin を利用して VACUUM を実行してみましょう。

    テーブルを右クリックしてメンテナンスを選択…VACUUMにラジオのチェックが入っているのを確認したらOKボタン…以上。

    SQLでは以下のようになります。

    VACUUM テーブル名;

    簡単ですね?
    デッドタプルが無くなり不要領域が回収されています。

    VACUUM をなんとなくでするのはやめよう

    如何でしたでしょうか?
    不要領域を回収するから、パフォーマンスが回復するからという理由で漫然と行なってきた VACUUM。

    これからは VACUUM を実行する前に、デッドタプルがあるか確認してください。
    そしてデッドタプルが多く、有効なレコードに対するデッドタプルの割合の多いテーブルに VACUUM をするようにしてみてください。

    このようなデータベースの状況の確認・把握するのは管理・メンテナンスを行なう者にとって重要なことです。
    なんとなく行なってきた VACUUM が明日からは ハッキリ とした理由で行なうことができます。

    VACUUM ファンの皆様なら分かってくれますよね?

      はてなブックマーク - Fusic Advent Calendar 2010開始します
      このエントリーをはてなブックマークに追加

      今日はお湯割りを呑もうかなと思っている小山です。

      今年も技術系Advent Calendarの季節がやってきましたね。
      「技術系Advent Calendarって何?」という方はこちらをどうぞ。

      PerlRuby、そしてEmacsなどいろいろあります。
      (CakePHPも行うそうです)

      どこの会社でも同じでしょうが、弊社Fusicでもご多分にもれず「師走」なわけですが(想像にお任せいたします)、「なぜか」FusicでもAdvent Calendarをやってみようということになりました。こういうアグレッシブにつっこんでいくのはほんとFusicらしいです。

      参加者

      参加者の呼びかけの時点は任意だったのですが、話の流れというか勢いでなんと社長、副社長を含む技術チーム全員が参加することに。
      「勢い」って怖いです。
      普段Blogに出てこないメンバーも参加するなかなか面白い25日になりそうです。

      ルール

      技術チーム全員が同じ確率で、当日朝にルーレットスクリプトを実行して、その日の担当者を決定するというかなり怖いルールになりました。

      1回当たった人は確率が1/2になりますが、確率が0になることはありません。
      連続して当たった人の顔が目に浮かびます。

      社長、副社長はレアということで確率を下げています。(が、まあ、25日付近まで当たっていなかったら「アタックチャンス」とでも称して確率を10倍にでもします)

      というわけで

      明日12月1日から毎日更新されるブログになると思いますので、お楽しみに!