 |
|
|
| 1 2 3 4 次のページ
|
|
| 今回のチューニング
|
前回は、共有バッファサイズを調整することでPostgreSQLのパフォーマンスを向上させました。共有バッファはPostgreSQLエンジンとハードディスクとの間でデータをキャッシュして処理速度を稼ぐものでしたが、もう1つ似たような位置づけのバッファがあります。それはトランザクションログバッファです。今回のチューニングは、この「トランザクションログバッファ」をターゲットにします。
|
| 共有バッファの問題
|
前回のチューニングで取り上げた共有バッファが、いわゆるディスクキャッシュとして働いていることは説明しました（図1）。
図1：共有バッファの概念図
このディスクキャッシュは読み込み時だけでなく書き込み時にもキャッシュとして機能しているため、PostgreSQLエンジンによって更新されたデータは、すぐにはハードディスクに書き込まれません。読み込みだけでなく書き込みでさえも、できるだけハードディスクへのアクセスを減らし、パフォーマンスを上げるように工夫しているわけです。
ここで1つ疑問がわきませんか？
データを更新しても即座にハードディスクへ書き込まないのであれば、その瞬間に何らかの障害が発生してPostgreSQLサーバが停止してしまうと、大切なデータが失われるのではないか…。実はそのとおり、失われてしまいます。このままではRDBMSとして十分な信頼性を備えているとはいえません。
|
1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
日本PostgreSQLユーザ会 片岡 裕生
1995年よりインターウィズという屋号で個人事業を営む。普段はPostgreSQLを用いたウェブアプリケーション開発などを行う。各コンピュータ情報誌にてPostgreSQL関連記事や連載を執筆。日本PostgreSQLユーザ会の創立メンバーの1人で、同会の技術担当理事、PostgreSQLのしくみ分科会座長を経て、2004年度からは理事長を勤める。
|
|
|
|
|
|
