 |
|
| オープンソースソフトウェアの性能・信頼性評価手法
|
第６回：PostgreSQLは使えるのか？
〜 あなたの環境での性能特性を調べる
著者：野村総合研究所 平野 耕一 2005/6/20
|
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| データベースのチューニング
|
本稿は、PostgreSQLのチューニングの方法を明らかにすることを目的としてはいないので、チューニングの過程は詳述しない。もしそうした興味がある方は、ぜひ報告書の第6章をご覧いただきたい。非常に具体的なチューニング手順の例が詳しく述べられている。筆者も参考にさせていただいた。さて、DBT-1の測定で明らかになった代表的な「問題箇所」を挙げる。
|
| 問題箇所1：シーケンシャルスキャンが多すぎる
|
DBT-1で動く約20のトランザクションタイプ（例えば商品検索、買い物かごに入れる、注文など）のうち、いくつかの平均応答時間がすこぶる悪い。
PostgreSQLの統計情報を見てみると、Itemテーブルのseq_scan（シーケンシャルスキャン）の回数が非常に多いのと、shopping_cartテーブルならびにshopping_cart_lineテーブルのインデックスを使ったアクセス（idx_scan）が0件であるということが気になる。つまり、すべてシーケンシャルスキャンであるということである。
一般に、検索結果集合が全体集合よりかなり小さいときはインデックスを使ったアクセスが効率的であり、シーケンシャルスキャンは全体集合のうち大部分を取得するときに行われるべきものである。インデックスを使うべきところで、PostgreSQLのオプティマイザ（クエリを実際にどう処理することで効率化するかを判断する内部機能）がインデックスを使ってくれない実行計画（クエリの実際の内部処理手順）を立てているようだ。
|
| 問題箇所2：PostgreSQLのシェアードバッファが8MBしかない
|
先に述べたとおり、PostgreSQLのインストール時のデフォルトでは、DBMSが確保するキャッシュは猫の額ほどしかない。
|
| 問題箇所への対処
|
問題箇所2への対処は比較的簡単である。PostgreSQLの設定ファイルpostgresql.confの内容を手持ちのPCサーバのリソースに合わせて変更すればよい（例えばシェアードバッファを8MBから1GBに増加）。問題箇所1はもう少し調査が必要である。今回判明したことは次の2つであった。
|
| DBT-1そのものはPostgreSQLに必須な運用手順を含んでいない
|
今回採用したDBT-1とそのオリジナルマニュアルはPostgreSQL向けに作られたものではあったが、マニュアル通りの手順ではPostgreSQLを期待通りに動作させることができない。
データの統計情報を取得する「analyze table」コマンドを発行する時に、shopping_cartテーブルならびにshopping_cart_lineテーブルが空であり、有効な統計情報が取得できていない。これが原因でshopping_cartテーブルならびにshopping_cart_lineに対してインデックスアクセスするべきところを、シーケンシャルスキャンをするようにオプティマイザが判断した。
オプティマイザは、十分に的確なデータの統計情報を持っていないとうまく動作しない。これはどんなRDBMSでも同じことである。DBT-1そのものの操作手順を再考しよう。再考の内容は報告書を参照されたい。
|
| PostgreSQLのオプティマイザがややシーケンシャルスキャンを好みすぎ
|
上記の運用手順の問題とは別個に、今回のデータに基づく統計情報とクエリでは、PostgreSQLのオプティマイザがややシーケンシャルスキャンを好みすぎている傾向がみられた。
これはオプティマイザの本質的な欠陥ではなく、PostgreSQLの管理者が調節してあげるべきことである。postgresql.confのrandom_page_costパラメータを変更し、オプティマイザがインデックスを使用する傾向を強める。デフォルトは4であるが、これを2とすることで、クエリプランはインデックスを使用すべきところでインデックスを使用するようになった。
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社野村総合研究所 平野 耕一
大英帝国の大学院に私費留学中、研究費がなく、大学教員のLinuxマシンを複数台連結し、夜中にこっそり大量の科学計算を行ったのがオープンソースとの出会い。現在は米国西海岸のNRI Pacific, Inc.に出向中。3才になる双子の父でもある。趣味は自転車通勤。
|
|
|
|
|
|
