[pgsql-jp: 28479] Re: updateの性能を向上
Yasuo Ohgaki
yohgaki @ ohgaki.net
2002年 12月 25日 (水) 19:54:11 JST
大垣です。
Tatsuo Ishii wrote:
>>最適な構成はシステム毎に異なると思いますが、極端な例では、ファイ
>>ルシステムのブロックサイズが32KB以上なのにPostgreSQLは8KBと
>>言う構成の場合、PostgreSQLのブロックサイズを32KBにしてパフォー
>>マンスが落ちる、と言う事は考えられず、逆にパフォーマンスは向上す
>>る可能性が高いと考えられます。
>
>
> ここのところ,私も興味がありますが,ディスクドライブレベルでは相変わら
> ず512バイト/セクタ単位でしかアクセスできないとすると,いくらOSの方の管
> 理ブロック単位が大きくなっても性能向上には限界があるのではないでしょう
> か?
私がLinuxのFS関連ソースを読んだり、いじったりしていたのは大
昔で、FSはext2のコードで知識の蓄積は停止していたりしますが判
るところだけ :)
ハードウェアレベルでのアクセスはセクタ単位で普通のディスクは
512バイトですが、OSが扱うディスクブロックサイズを大きくすると、
・ディスクIOの回数が少なくなる (OSは読み書きする複数のセク
タを指定して読み書きが終るまで、他の処理を行ない、完了する
と割り込みが入るので続きの処理をする。ブロックサイズより大
きいファイルが多くなると、大きいブロックサイズの方がOSのIO
処理回数が少なくなる)
・ブロックは連続したセクタなので大きなデータを効率良く良み出
すことができる
と言うメリットがあります。
・小さいファイルが多い場合、無駄が多くなる
(1KB程度しかないファイルはシステム上に沢山ある)
・ディスクからメモリへの転送に時間余分にかかる
(ローテイション遅延とデータ転送遅延)
と言うデメリットがありますが、OSから見ると、ディスクIOの数が
減るメリットは大きいので、ディスクが大きくなった現在では多少の
ディスク領域の無駄は無視できるようになったと思います。このため、
多くのシステムが昔の4倍(4KB)ブロックサイズをデフォルトにし
て、大きなファイルが効率良く取り扱えるよう、更に大きい64KBな
どのブロックサイズをサポートしていると思います。
OS内部のバッファキャッシュがファイルシステムのブロックサイズ
単位で管理できるようになっていると更に処理効率が良くなると思
います。
# ディスク領域の無駄と同様に、バッファキャッシュのメモリも無駄
# になりますが、今は多少のメモリの無駄は無視できると思います。
# 最近のカーネルがどうなっているのか知りません。
# Linuxは最大ページサイズまで??
# だとすると、memory mapped I/O関連の制限でしょうか?
# 大きけれは良いという物でもなく、Newsサーバーなどを作る時は、
# ブロックサイズを1KBに小さくして、inodeの数を多くしますよね。
最近のバスやI/Fは昔と較べもにならないくらい早いですし、ディス
クは転送速度もかなり早くなり(700Mbit/secのディスクは十分安
い)のでブロックサイズが大きくなった事による、転送時間オーバー
ヘッドより、ブロックサイズが小さい事によるOSのIO操作が増える
方のデメリットが気になるようになったと思います。
どんな設定・実装が一番良いかは使い方によるのでケースバイケー
スですが、インデックス、テーブルを全部スキャンする様なクエリ、
大きなテキスト、BYTEA、Large Objectを多用しているDBでは
ファイルシステムとDBのブロックサイズを大きくするメリットが十
分あると思います。
# PostgreSQLのLarge Objectのブロックサイズは別に定義
# されていて、最近8KBから16KBに増えていたような気がします。
# PostgreSQLのソースは斜め読みなので、間違っていたら教え
# てください。
反対に、小さいデータを大量に挿入・更新し、ディスクと同期させ
るような場合は小さ目のブロックサイズの方が多少、有利になるよ
うに思えます。
実験してみないとはっきりしませんが、PostgreSQLの同時実行性
に問題があるかないかを無視すると、仕組み上はこうなると思いま
す。
# OS、PostgreSQLの仕様・設定はもちろん、詳細なH/W(ディ
# スクI/F、CPU、FSB、メモリの種類、HDDのビットレート・平
# 均アクセスタイムなど)付きのベンチマーク結果があると嬉しい
# です。私の予測が間違っていたりして :)
# 重ねて書きますが、今はベンチマークとりをしている時間があり
# ません。
--
Yasuo Ohgaki
pgsql-jp メーリングリストの案内