[pgsql-jp: 36358] Re: 8.1 Released
SAKATA Testuo
sakata.tetsuo @ lab.ntt.co.jp
2005年 11月 10日 (木) 08:54:04 JST
おはようございます。坂田@横須賀です。
Kiyoshi Mizuno wrote:
> 水野です。
>
> ITmediaの記事ではロールの導入や2Phaseコミット、テーブルパーティショニング
> なんかに着目してましたね。
> 読んでて機能的にどんどんOracleナイズされているような気がしたのは私だけ?
まぁ、Oracleナイズというよりも、エンタープライズ指向というほうが適切かと。
(2年ほど前に、B.Momjianさんが7.4の講演を開いた際には、エンタープライズ向けに
がんばりたい、という趣旨の話をされていましたし)
逆に言えば、非エンタープライズ向け、AP用の賢いストレージとしてDBMSを
使いたい、という用途には、別のDBMSが良いだろうということでもありますね。
>>-----Original Message-----
>>From: pgsql-jp-bounces @ ml.postgresql.jp On Behalf Of TANIDA Yutaka
>>Subject: [pgsql-jp: 36355] Re: 8.1 Released
>>
>>
>>>次は64ビットのチューニングと、CPUキャッシュだな(独り言)
>>
>>前者はともかく、後者のような個別プラットフォームに特化した改造はあまり受
>>け入れられないような。もちろん、キャッシュヒット問題から見つかった問題が、
>>広範囲な修正となる場合は受け入れられると思いますけど。そういえば、今回の
>>バッファ関連の改造も、うろ覚えの記憶によればXeon SMPでのキャッシュ問題と
>>かから発展したような・・・
CPUのキャッシュを意識したコードとしては、spin lock を含むLWLockのデータ構造に
適当な詰め物をして、構造体がキャッシュラインの大きさ(32byte)にフィットする
ようなパッチが投稿されていたと記憶します。
(これは結局採用されていないようですね)
マシン依存の改善項目としては、Opteron用のspin lockのコードが変更されていますね。
(この辺は、元からマシン依存なので、改善提案が通りやすいのでしょうけど)
> 64-bit Shared Memory: the buffer manager has been enhanced to utilize up to two terabytes of RAM
> on 64-bit platforms, preparing PostgreSQL for the high-memory servers of the future.
>
> とありますので徐々に64bit対応も進んでいくようですね。
> 数年前には「4GBも実メモリ積む必要なんてある訳ねえじゃん」
> と言っていたこの口が今じゃ「このマシン、4GBしか積めないのかよ」と。
> あと数年したら普通にテラバイトマシンを構築してるのかな。
Mooreの法則でメモリが高密度化すれば、4年後くらいには、
デスクトップで4GBくらいは当たり前、中規模サーバで128GBとかになるのでは。
(メモリチップよりも、メモリ周りのバスのほうが問題でしょうな)
中規模サーバでテラバイトになるのは、7,8年後くらいでしょうか。
> 【こっから質問】
> ところでCPUキャッシュなんてPostgreSQL(というかアプリ)から
> 制御可能なんですか?
IntelのEM64Tのマニュアルを見ると、キャッシュラインをフラッシュする命令
(CLFLUSH)なんていうのがあって、しかも、Intel C compiler には、これを叩く
関数が用意されているのだそうです。
このほか、内部キャッシュをフラッシュする命令や、キャッシュラインの大きさを
取得する命令もありますね。
…と言っても、どういう風に使うと性能が向上するかちょっと想像がつかないですが。
では。
--
坂田 哲夫@NTT サイバースペース研究所
sakata.tetsuo _at_ lab.ntt.co.jp
SAKATA, Tetsuo. Yokosuka JAPAN.
pgsql-jp メーリングリストの案内