 |
||||||||||||
|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| 今回のチューニング | ||||||||||||
|
前回は、共有バッファサイズを調整することでPostgreSQLのパフォーマンスを向上させました。共有バッファはPostgreSQLエンジンとハードディスクとの間でデータをキャッシュして処理速度を稼ぐものでしたが、もう1つ似たような位置づけのバッファがあります。それはトランザクションログバッファです。今回のチューニングは、この「トランザクションログバッファ」をターゲットにします。 |
||||||||||||
| 共有バッファの問題 | ||||||||||||
|
前回のチューニングで取り上げた共有バッファが、いわゆるディスクキャッシュとして働いていることは説明しました（図1）。  図1：共有バッファの概念図 ここで1つ疑問がわきませんか？ データを更新しても即座にハードディスクへ書き込まないのであれば、その瞬間に何らかの障害が発生してPostgreSQLサーバが停止してしまうと、大切なデータが失われるのではないか…。実はそのとおり、失われてしまいます。このままではRDBMSとして十分な信頼性を備えているとはいえません。 |
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
