KeepAliveTimeoutは2秒

先日行われた第二回 ライブドア テクニカルセミナーをustreamで見ました。pixivの中の人の話が聞けて面白かったです(資料と動画はこちら)。

そのときに出てきたのが、Apache HTTP ServerでKeepAliveTimeoutを2秒に設定しているという話です。MPMもpreforkでもworkerでもなくeventで運用しているとのことでした。eventならKeepAliveTimeoutを伸ばしてもいい気がするのですが、「安全のため」2秒にしているそうです。ちなみにftp.jaist.ac.jpのKeepAliveTimeoutも2秒です。

メモリを64GB積んでみる

Sunから贈られたSun Fire T2000にはメモリが16GB積まれていました。2006年秋から話が始まって、USの決裁が下りて実物が届けられたのは2007年5月です。8コアモデルにメモリ16GBですから、当時としてはがんばった構成だったと思います。16あるメモリスロットに、1GBメモリがぎっちり刺さっていました。

SSDによるコンテンツキャッシュ(ソフト編)

ZFSにはSSDをキャッシュに使ってランダムリードの性能を稼ぐL2ARCという仕掛けがあります。L2ARCはOpenSolarisでは使えるのですが、Solaris 10ではまだ使えません。10u6 (10/08)で使えるようになると言われていたのが延期されて、今年の10u7 (5/09)で使えるだろうと思っていたのが、また延期されてしまいました。実は10u7に合わせてSSDを購入したのですが、当てが外れてしまいました。

仕方ないのでバージョン2.2から実用可能になったApacheのmod_disk_cacheを使おうかと思ったのですが、これがうまくありませんでした。

SSDによるコンテンツキャッシュ(ハード編)

先日のエントリでSun Fire T2000はUltraSPARC T1には4Gbpsの帯域を埋める能力があると書きましたが、それを実現するには一つボトルネックを解決しなければなりません。それはディスクI/Oです。最近の速いハードディスクでも最外周で100MB/sくらいしか出ません。ビットにすると800Mbpsですね。ぜんぜん足りないのでRAIDを組んで性能を稼ぐ必要があります。

Firefoxが10億回ダウンロードされたのは本当か

Mozilla Foundationが7月31日にFirefoxが10億回ダウンロードされたとアナウンスし、特設サイトも作られました。この回数はどうやって数えたのでしょうか？

皆さんもご存知の通り、mozilla.comのDownload Firefoxのボタンを押すと世界中のミラーサーバに飛ばされます。Mozilla Foundationが把握できるのはクリックされた回数だけで、本当にダウンロードされたかどうかはわかりません。では、クリックされた回数が10億回と言ってるのかというと、そうでもないようです。

worker MPMの設定(後編)

前回の話で何がいけなかったのかというとMaxSpareThreadsが小さすぎたのです。MaxSpareThreadsはクライアント数の変動幅より十分大きくないと、プロセスの終了と起動の頻度が高くなり、結果として終了待ちプロセスの数が増えてしまいます。

MaxSpareThreadsをMaxClientsに合わせてしてしまえば、MaxSpareThreadsが理由でプロセスが終了することはなくなります。しかし、不要なプロセスを起動したままにするのも気持ちが悪いので、できることなら適切に終了させたいものです。

worker MPMの設定(前編)

ftp.jaist.ac.jpではHTTPサーバとしてApache HTTP Server (以降Apacheと略記)を使っています。lighttpdじゃないんですかって？ えぇ、違います。SourceForge.netのミラーネットワークに参加するためには、Apacheのmod_rewriteを前提にした複雑なURL書き換え規則を受け入れる必要があるので、Apacheでないとだめなんです。

net-snmpのC10K問題(後編)

なぜsnmpdがリクエストに答えないのか突き止めるべく、まずprstat (topみたいなやつ)で様子を見てみたら、snmpdが3%以上のCPU使用率でトップに君臨していました。この使用率は32CPUで計算されているので、本当は8コアのUltraSPARC T1にはかなりの重荷です。

いったい何をそんなに忙しくしているのかとtrussで追ってみたら、ひたすらファイル記述子6番からgetmsgでメッセージを読んでいました。このメッセージの読み込みが忙しくてリクエストに答えるひまがないようです。

net-snmpのC10K問題(前編)

昔C10K問題というのが話題になりました。Y2K問題をもじった名前なので2000年から数年間くらいですね。インターネットのバックボーンが1Gbpsに到達した。GbEを備えた1GHzのCPUのサーバが安価に手に入るようになった。しかし、10,000クライアントを同時にさばこうとすると、ハードウェアではなくOSがボトルネックになるという問題です。

UltraSPARC T1の弱点とUltraSPARC T2

UltraSPARC T1には決定的に向かない仕事があります。各コアは整数ユニットは持ってるんですが、浮動小数点ユニットは8つのコアで共有していて、浮動小数点ユニットを使うだけで40サイクルのペナルティがあります。だから浮動小数点演算をたくさんする仕事はだめです。

Ultra SPARC T1のこと

http://ftp.jaist.ac.jp/に書いてあるんですけどftp.jaist.ac.jpはSun Fire T2000で動いてます。この子のCPUのUltraSPARC T1には8つのコアがありますが、クロックヘルツはわずか1GHzです(最近は1.4GHzのもあります)。各コアにはアウトオブオーダ実行もスーパースカラーもありません。だからとても遅いです。

UltraSPARC T1は8つのコアのそれぞれで4つのスレッドを実行できるので、OSから見ると32個CPUがあるように見えます。ところが、各コアは4つのスレッドのうち実行可能なものをクロックごとに順番に実行するだけなので、残念ながら実力はCPU 8個分です。 それもとても遅いCPUの。