最初に 今日は、 JPOUG Advent Calendar のエントリです。 昨日の小田さんに続き、私は、 1μmも役には立たないエントリ となります ! 最近思うこと 昨今、データベースシステムを構成するハードウェアは大量のコア、一昔では考えられないほどの大量のメモリーが搭載し、さらにデータベースのボトルネックの王者たる風格さえ漂っていたI/Oにも高速化の波が押し寄せてきています。 そんな中、古くて新しい、そして、RDBMSとしての真価を問われるコンカレンシーの問題がボトルネックとして浮かび上がっているような気がしています。 このコンカレンシーの問題は、曲者で、どんなに高速なCPUを沢山搭載しても、どんなに沢山のメモリーを積んでも、ロケットばりの高速ストレージを使っても、コンカレンシーがボトルネックとなると全くパフォーマンスがスケールしません。(まぁー、極端な言い回しですが) そんな事を、つらつら考えつつ、コンカレンシーの問題が大きく関係するBuffer Cache上で繰り広げられる様々な動きを考えて見ることにします。 ここで、登場するボトルネックの原因となるWait Eventは、こんな物です。 latch: cache buffers chains latch: cache buffer lru chain free buffer waits read by other session まず、 SELECT文 のEXEC/FETCHフェーズを想像して下さい。 上記のWait Eventを噛み砕くと、こんな感じでしょうか? latch: cache buffers chains 「僕の探しているブロックはキャッシュされていますか～」を多くの人(Session)が聞きたがっている。でも、キャッシュされているか答えをもらうためのチケット(cache buffers chains latch)は一つ(もしくは非常に少ない)なので、なかなか、その順番が回ってこない。なので、「待つ」 * ちなみに latch: cache buffers chains は"聞く"だけなら、コンカレンシーの問題は起こらないのですが、このラッチは、「ブロックをキャッシュするので、ちゃんと管理してお