博士

やっほー、ロボ子！今日のニュースはPostgreSQLのshared_bufferについてじゃ。

ロボ子

博士、こんにちは。shared_bufferですか。PostgreSQLのパフォーマンスに大きく影響する部分ですよね。

博士

そうそう！shared_bufferは、PostgreSQLがサーバーのメモリに割り当てる領域で、データ領域とバックエンド間のデータフローを管理するのじゃ。

ロボ子

記事によると、データベースの物理ページは、データの読み書きに関わらず、共有バッファに格納されるんですね。

博士

その通り！そして、PostgreSQL 8.1以降はクロックスイープアルゴリズムが使われているぞ。

ロボ子

クロックスイープアルゴリズムは、バッファの置換戦略を管理するものですね。ステップがたくさんありますね…

博士

難しく見えるけど、要は使用頻度の低いバッファを追い出す仕組みじゃ。フリーリストが空だと、nextVictimBufferが頑張ってスキャンするのじゃ。

ロボ子

各バッファは、バックエンドによってピン留めされるたびに使用カウンタが増加するんですね。使用カウンタがゼロでないと、置換対象にならないと。

博士

さすがロボ子、理解が早い！リングバッファ戦略ってのもあるぞ。これは、大量のVACUUMとか大規模なシーケンシャルスキャンの時に、共有バッファ全体への影響を避けるために使うのじゃ。

ロボ子

リングバッファ戦略ですか。VACUUMのリングサイズはvacuum_buffer_usage_limit GUCで制御できるんですね。

博士

そう！バルク書き込みだと、リングサイズは16MBだけど、shared_buffersサイズの1/8を超えないようにするのじゃ。

ロボ子

shared_bufferのサイズ設定も重要ですよね。システムのRAMの25%を推奨とのことですが。

博士

そうじゃ！4GB～100GBのシステムなら、1GB～25GBくらいが目安じゃな。40%まで上げるのは推奨されてないぞ。

ロボ子

データ領域がshared_bufferより小さい場合は、すべてのバッファがキャッシュされるんですね。それは理想的ですね。

博士

じゃろ？でも、データ領域がshared_bufferに収まらないと、クロックスイープがフル稼働になるのじゃ。

ロボ子

64GBをshared_bufferの上限とすることが妥当、と記事にありますね。

博士

デフォルト値は128MBと小さいから、initdb後に変更するのが超重要！

ロボ子

確かにそうですね。デフォルトのままでは、パフォーマンスが出ない可能性が高いですね。

博士

というわけで、shared_bufferの設定は、PostgreSQLを使う上で避けては通れない道なのじゃ！

ロボ子

はい、博士。勉強になりました！

博士

ところでロボ子、shared_bufferの設定を間違えるとどうなるか知ってるか？

ロボ子

えっと…システムが共有バッファを共有できなくなります…？

博士

ぶっぶー！正解は…「共有」だけに「笑う」バッファになるのじゃ！