[pgsql-jp: 38544] Re: DB

[Keisuke YAMAMOTO]

お世話になっております。
山本です。

ご回答いただきありがとうございます。

YuGo様
> 1)パフォーマンスが悪い→チューニングの問題
> 2)危険である→可用性の問題（？）

水野様
> YuGo氏も書かれていますが性能問題と可用性問題がごっちゃです。
> 動作モードは可用性、shared_buffersは性能の話です。

もちろん、存じておりますが、20個のインスタンスを動かしている
理由が、ダンプファイルでバックアップが取れるサイズに分割したい。
ということで、shared_buffersを大きくすると、スワップを起こし始め
て、サイト、イントラ共に止まってしまうため、64M分しか設定できない。

ということで関連しているのです。
64Mでは、パフォーマンスも悪いですし、4時間のバックアップでは
不安と言うことです。


> 「DB毎に負荷のかかる時間帯が異なるため同時に忙しくなるのは３〜４つ」
> というのならマシンの稼動率向上という意味でアリでしょう。

稼働率が向上するのでしょうか？
向上するパターンが思いつかないのですが。

> 使用しているマシンスペックやDBの規模が分かりませんが、
> 一般的な業務用のDBだとして実メモリ２GBのマシンで２０インスタンス
> （という事ですよね）は多いと思います。ただ

APサーバは２台ありますが、現在、月間のPVが数百万で
倍増を目指しています。
イントラでも利用しています。

DBはトータルすれば10〜数十Gになると思います。
それをshared_buffers を64Mで運用する。
一つの機能で、複数のDBに接続すると、APサーバにも、DBサーバにも
相当な負荷を掛けていることになると思います。

私の経験ではかなり無茶な構造だと思います。
PostgreSQLでも、同じだと思うのですが。

中井 様
> vaccumeは行っていらっしゃるのでしょうか。オンライン中に
> vaccumeできますし、やって損をすることはないと思います。

毎日１回行っています。

> DBを一つにまとめた方が、レスポンス、メモリ消費、
> トランザクションの点で良くなります。
> バックアップが問題ならば、もう一台ハードを用意して、
> ポイントインタイムリカバリを使ってウォーアップ
> スタンバイにするか、pgpoolを使ってリプリケーションを

私もDBを一つにまとめる方が良いと思っています。
危険でないかどうかは、確かに、企業の価値観の問題ですね。