何の話？
“Super-linear scaling”に”challenge”ということなのだが，この”challenge”は「チャレンジする」という意味とは異なる．同じ意味の卑近な例は，ウインブルドン選手権といったテニスの試合において，in, outの判定に不服を持った選手がビデオ判定を要求する”challenge”だ．なので，タイトルは”Challenging the super-linear scaling mentioned at a blog titled Scalability, in Graphical Form, Analyzed”と長くなるが厳密に書かないと意味をなさないだろう．これ以降，上記のwebページを単にblogと表記する．
次は”super-linear scaling”の意味だ．このadvent calendarの読者には不要と思われるが，一応，ごく簡単に紹介しておく．通常，1（CPU）コアの性能がスループット1の場合，nコア構成のシステムではスループットがnになるのが理想だが，このようになることは殆どなく，n未満になってしまうのが普通の姿だ．ところが，nコアのスループットがnを超えてしまう，という状況（現象）を”super-linear scaling”と呼ぶ．
加速する？
上記のblogでは，pgbenchで-S（select-only）を指定して測定した結果が”super-linear scaling”だとされている．クライアント当たりのスループットでみたとき，１クライアント時のスループットを100%とすると，32クライアントのときには150%以上になってしまうのだ．この測定結果のグラフはPostgreSQLカンファレンス（2012年2月）において，blog主による基調講演でも紹介されている．そのQ&Aにおいて”super-linear scaling”らしき現象の理由を問われた際，blog主が”I don’t know.”と答え，会場の笑いを誘ったことを今でもはっきりと覚えている．
そして，blogでは，この”super-linear scaling”について”at the higher client counts, performance appears to be increasing more than linearly as we add clients.”と述べている．「クライアント数が多くなるほど性能を加速する（ある意味，超常的な）要因が働いている」というようなニュアンスを感じる．しかし，”super-linear scaling”なんて現象には滅多にお目にかかれるものではない．四葉のクローバーを見つけるより遥かに確率は低いだろう．性能評価を長年手がけてきた立場からすると，クライアント数が少ないときに何か足を引っ張る現象が起きている，と考えるのが普通だ．
再現できるか？
この「足を引っ張る現象」とは何か，ということになるが，blogに寄せられたコメントの中に的（のど真ん中）を射たものがあるので，ここでは直接，”super-linear scaling”もどきの挙動を示す原因については触れないでおく．その代わりとして，その原因を強く示唆する興味深い実験結果を以下に示す．
blogの実験は32コアであったが，当方で使用できるのは16コアのマシンであったので，まず，同様の現象が観測できるかどうか調べてみた．実験方法は，できるだけblog記載の方法に準拠した．下表がPostgreSQL 9.2.4で測定した結果である．
| クライアント数 | スループット |
|---|---|
| 1 | 6611.74 |
| 2 | 12777.12 |
| 4 | 24969.75 |
| 8 | 47909.13 |
| 12 | 74015.65 |
| 14 | 86452.66 |
| 16 | 100139.74 |
4～14クライアントにおいて16クライアントとの間に”super-linear scaling”の関係が伺え，その程度は8クライアント時に最も顕著となった（47909.13*16/8 < 100139.74）．
パラドクス？
8クライアント時には，16コアの内，8コアはbusy, 残りの8コアはidle状態となっているものと考えられる．そこで，idleの8コアを潰してみる．「潰す」といっても物理的に破壊するわけではなく（当たり前），main() { while(1); } というような無限ループを実行させるのである．なお，実際に使ったプログラムでは，Linuxのsched_setaffinity()システム・コールを使うことで無限ループが動作するコア番号を指定できるようにした．コア番号が0, 2, 4, 6, 8, 10, 12, 14の8コア上でこのプログラムを実行させておき，その状態で8クライアントのpgbenchを実行させると，スループットは51022.18となった。つまり、”super-linear scaling”状態は解消（51022.18*16/8 > 100139.74）されたのである．これより「クライアント数が少ないときに何か足を引っ張る現象が起きており，idle状態のCPUコアを潰すことでその現象の発生が抑えられた」ことが実証できたと考えてよいだろう．
何といっても，ここで興味深いのは，idle状態になっている（と思われる）CPUコアに負荷をかけた方が（＝サーバ全体としてCPU使用率を高くする方が），idle状態として空けておくよりもベンチマーク性能は高くなる，という一見パラドックス的な結果となることであろう．pgbenchを使っての性能測定において”super-linear scaling”もどきの状況を生んだ原因は，この実験結果から明白と思えるので，上で述べたとおり，ここではそれ以上の言及はしないでおく．
Challenge成功？
さて，テニスのウインブルドン選手権では１セットにつき3回，”challenge”する権利が与えられており，”challenge”が成功するとその回数は減らない（”challenge”する権利を消費したことにならない）というルールになっている．ここで行った”challenge”は成功したと判断して貰えるであろうか．