 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||||||
|
||||||||||||||||||||
| テスト其の伍 〜 VACUUMの影響 | ||||||||||||||||||||
|
ではPostgreSQLでのVACUUM実行の有無が、パフォーマンス上どのような影響となって現われるかを検証してみます。テスト方法は、以下のようなパターンで行いました。
|
||||||||||||||||||||
|
||||||||||||||||||||
|
2で実行したSQL文 |
||||||||||||||||||||
select sum(給与) from 社員表;
|
||||||||||||||||||||
|
||||||||||||||||||||
|
3で実行したSQL文 |
||||||||||||||||||||
update 社員表 set その他="ダミーの文字列70byte"
|
||||||||||||||||||||
|
||||||||||||||||||||
| データ中の半分をupdateする事によって、データファイル中で更新された行が（削除マークを付けられたうえで）新たな行へと置き換わるために、表全体の占める領域が徐々に拡大します。 表を構成するファイルサイズの拡大と、この操作の合間に実行する全件検索の検索の実行時間がどう推移するかを確認してみます。そして全件検索の3回目が終了したところで、VACUUMもしくはVACUUM FULLを実行して、その効果の有無や大きさを4回目の計測で確認しようというのが今回のテストの趣旨です。 OracleにはVACUUMと同様の操作は存在しませんが、それ以外の部分で同じデータの操作を行った場合のパフォーマンスへの影響を合わせて確認してみます。  図1：PostgreSQLのデータサイズ増分と全件検索時のレスポンス（VACUUMとVACUUM FULLの違い ここでグラフ中「3回目」と「4回目」の間で、実行したVACUUMについてのおさらいです。
|
||||||||||||||||||||
|
||||||||||||||||||||
| 詳細については過去の記事を参照していただきたいと思います。 両者の大きな違いとしては、排他ロックの有無と不要な行の扱いがあります。図1の4回目の部分を見てください。コンカレントVACUUMの方はデータファイルのサイズには変化がありませんでしたが、VACUUM FULLではupdate実行前のデータローディング終了直後よりも若干ですがサイズが小さくなりました。 そして肝心のレスポンスタイムは両者ともデータローディング終了直後(1回目)と同じレベルまで改善されました。このテストではその差は小さいものでしたが、VACUUM FULL実行後のほうが若干高速です。微妙な差ではありますが、データファイルの大きさの差が影響により、発生したものであると考えられます。  図2：VACUUMの実行時間 テスト環境ではVACUUM FULLはコンカレントVACUUMの倍程度の時間が必要でしたが、この実行時間の絶対値は重要ではありません。VACUUMの実行時間はその処理から想像されるように、行データ・データファイルのサイズや不要データの割合などで大きく変わります。 重要なのはシステムのデータ状態（更新・削除などの処理量）を把握したうえで実行間隔を見積もり、定期的に実行する運用設計を事前に行う事です。特に更新データが多い場合には、排他ロックが許されるタイミングを見つけ（作り）だしVACUUM FULLを実行するようにすべきでしょう。 |
||||||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
-
-
連載
