[pgsql-jp: 36360] Re: 8.1 Released

[Hiro Yoshioka]

On 11/10/05, SAKATA Testuo <sakata.tetsuo ＠ lab.ntt.co.jp> wrote:
> おはようございます。坂田@横須賀です。
> Kiyoshi Mizuno wrote:
> > 水野です。

こんにちは〜

> > ITmediaの記事ではロールの導入や２Phaseコミット、テーブルパーティショニング
> > なんかに着目してましたね。
> > 読んでて機能的にどんどんOracleナイズされているような気がしたのは私だけ？
>
> まぁ、Oracleナイズというよりも、エンタープライズ指向というほうが適切かと。

そうかもしれないですね。
VLDBの機能としてパーティショニングとか必須ですし、
まあその手の機能はOracleにはテンコ盛りなんで。

> (2年ほど前に、B.Momjianさんが7.4の講演を開いた際には、エンタープライズ向けに
> がんばりたい、という趣旨の話をされていましたし)
> 逆に言えば、非エンタープライズ向け、AP用の賢いストレージとしてDBMSを
> 使いたい、という用途には、別のDBMSが良いだろうということでもありますね。

よくわからないのですが、Oracleと同じ方向に向いてい
るというのはそれはそれでいいのですが、やっぱ、もっと
ニッチもがんばって欲しいというか。
メインメモリDBとか組み込みDBとかリアルタイムDBとか…

勝手な思いですが。

> >>-----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)にフィットする
> ようなパッチが投稿されていたと記憶します。
> (これは結局採用されていないようですね)

すげーー昔にpgbenchでL1キャッシュミスを測定したことがあります。

そーしたらLWLockにボトルネックがあるとわかって
ちょっとしたハックで15％ほどキャッシュミスを
減らしました。
http://sourceforge.jp/projects/hardmeter/document/dews20030328.pdf/ja/1/dews20030328.pdf

oprofileを使えば同様な事が簡単にできるかと思います。

最近のコードが追っていないのですが、たぶん
いろいろチューニングネタはあると思います。

> マシン依存の改善項目としては、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対応も進んでいくようですね。
> > 数年前には「４GBも実メモリ積む必要なんてある訳ねえじゃん」
> > と言っていたこの口が今じゃ「このマシン、４GBしか積めないのかよ」と。
> > あと数年したら普通にテラバイトマシンを構築してるのかな。
>
> Mooreの法則でメモリが高密度化すれば、4年後くらいには、
> デスクトップで4GBくらいは当たり前、中規模サーバで128GBとかになるのでは。
> (メモリチップよりも、メモリ周りのバスのほうが問題でしょうな)
>
> 中規模サーバでテラバイトになるのは、7,8年後くらいでしょうか。

メモりサイズが増えてもアクセスレイテンシはほとんど
減らないので、メモリを上手に使うアルゴリズムを発明
しないと性能向上にほとんど（？）寄与しないのでは
ないかと思っています。

その意味でキャッシュを上手に使うアルゴリズムの
発明というか再発見が必要かと。

> > 【こっから質問】
> > ところでCPUキャッシュなんてPostgreSQL（というかアプリ）から
> > 制御可能なんですか？

可能なんですが、ちょっとめんどくさいです。

むしろ、キャッシュサイズを意識したプログラミングで
性能が変わってくると思っています。

L2（2次キャッシュ）は512KB程度しかないので、
L3（3次キャッシュ）でも2ないし4MB程度、
それを上手に利用すれば劇的に速度が向上する
可能性があります。

http://www.vldb2005.org/program/full_program.php
Research Session 16: Architectural Issues
Cache-conscious Frequent Pattern Mining on a Modern Processor
Amol Ghoting, Gregory Buehrer, Srinivasan Parthasarathy, Daehyun Kim,
Anthony Nguyen, Yen-Kuang Chen, Pradeep Dubey

> IntelのEM64Tのマニュアルを見ると、キャッシュラインをフラッシュする命令
> (CLFLUSH)なんていうのがあって、しかも、Intel C compiler には、これを叩く
> 関数が用意されているのだそうです。

gcc でインラインアセンブラを使えば利用できます。
だけどちょっと面倒ですね。

> このほか、内部キャッシュをフラッシュする命令や、キャッシュラインの大きさを
> 取得する命令もありますね。
>
> …と言っても、どういう風に使うと性能が向上するかちょっと想像がつかないですが。

Linux Kernelの copy_from_user_ll()という
ユーザー空間からカーネル空間へコピーする
関数があるのですが、データアクセスの時間的
非局所性（コピーされたデータがすぐに使われない）
に注目して、キャッシュをバイパスすることによって
性能向上をはかるパッチを今年の夏頃作りました。
Cache Pollution Aware Patch

write(2)中心のベンチマークで10％位性能向上しています。

下記スレッド参照。
http://marc.theaimsgroup.com/?t=112401104100001&r=1&w=2

パッチそのものは下記。
http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14/2.6.14-mm1/broken-out/x86-cache-pollution-aware-__copy_from_user_ll.patch

RDBMSの中でシーケンシャルコピーをしているところで
利用できるかもしれません。

RDBMSのベンチマークをちゃんと取ることがもちろん
先かとは思いますがキャッシュミスに注目した
チューニングは結構熱い話題かなと思っています。
（マイブーム）

誰か、予算と時間とマシンをくれれば、どーにかしたい…
（笑

> では。
> --
> 坂田 哲夫＠NTT サイバースペース研究所
> sakata.tetsuo _at_ lab.ntt.co.jp
> SAKATA, Tetsuo. Yokosuka JAPAN.
>

よ
--
http://d.hatena.ne.jp/hyoshiok/
mailto:hyoshiok ＠ gmail.com