[pgsql-jp: 32341] Re: 数万アクセスに対する対処について

[Tsunehisa Kazawa]

こんばんは。加澤です。

Kenji Ono wrote:
> 他にも書いたのですが、そんなにSolarisはパフォーマンスが上がらな
> いのでしょう。
> それとも、オープンソースの製品がLinux用に最適化されているとか。

というか、Linux と比べると Solaris は fork の負荷が高い、ということで
す。その代わりに lwp があり、thread 周りの実装はかなり Solaris の方が良
い。あくまでも世間の評判＋PostgreSQL や Java 等で使ってみた感想レベルで
すけど…。

// Linux も 2.6 からは大分良くなっているとも聞きますね。

> ConnectionPoolですか・・・
> やはり異句同音に皆さんが提案するあたりはこの方式にいくしかないか
> な。

PostgreSQL の場合 (や Oracle を専用サーバで使った場合) は特にそうだと思
います。MySQL を例に出したのは、あちらは新たな Connection に対して fork
するのではなく thread を生成するだけであるので、Solaris の場合は結構差が
出るのではないかと考えたからです。

>>// チューニング時に参考になったページ。
>>// http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
>>// 共有メモリを増やし過ぎるとダメなんですよね…。
> 
> 僕もSolarisでは増やし過ぎて、うんともすんとも言わなくなってえら
> く難儀した思いがあります。

OS 側の設定の話ではなくて、postgresql.conf の shared_buffers 設定の話で
した。公式のチューニングマニュアルなどでは「スワップが発生しない範囲でな
るたけたくさん割り当てましょう」とも読めるような記述があったりしますが、
実際にはたくさん割り当て過ぎると逆に性能劣化することもあることを経験して
います (上の参考になったページにも書いてありました)。

// よしおかさんも書かれていましたね。

> PostgreSQLに特化したSQLもあったり、いまからMySQL検証は厳しいっす。

なるほど。まぁそうでなくとも MySQL は相当特殊ですから、切り替えるにはか
なりの根性が必要なんですけれども… (かなり理不尽な制限がたくさんあるんで
すよね)。

＊＊＊

他のメールで寺岡さんのおっしゃる通り、DB のベンチマーク結果なんてものは
環境／アプリケーションによって千差万別であって異なる環境での結果なんてほ
とんど意味がないわけですけれども、僕があえて意味のない実性能を提示した理
由は、そのことにより小野さんが性能的なスケール感を得られるんじゃないかと
考えたからです。例え環境が異なるとしても、「PC サーバ上で単純 insert な
ら 1000 insert/sec 出る」ということを知っていれば、例えばそれに select
(unique index がばっちりヒットするようなもの) が加わっただけで 15
trans./sec しか出ない、という状況はおかしい、と気づけるはずです。どこか
にボトルネックがあると。

// ちなみに IO について記述するのを忘れてましたが、ごく普通の SCSI
// HDD を単発で２発、ログ領域とデータファイル領域として使っている
// だけでした。かなり poor な環境です。

そういう感覚さえつかめてしまえば、後は地道なボトルネック探しに落とし込め
ます。あっちゃこっちゃにプロファイリング情報を取得するための仕組みを仕込
むなどして、どこがボトルネックになっているのかを推理していくだけです。実
験研究者のように、地道に正確な情報を調べて頑張って推理すれば、自ずからボ
トルネックは見えてきます。

-- 
  ◇   加澤恒央 Tsunehisa KAZAWA
◇  ◇ mailto:kazawa ＠ ca2.so-net.ne.jp
  ◇   http://www.digitune.org/