以前のエントリでも取り上げましたが、Firefoxのダウンロードやアップデートのアクセスは、国や地域に関係なく世界中のミラーサーバに振り分けられます。この負荷分散を行っているのがBouncerと呼ばれるプログラムです。Bouncerは各サーバに割り当てられたウェイトに基づいて負荷を割り振ります。各サーバの稼働状況も確認して、止まっているサーバへの割り当てを止めたり、過負荷のサーバのウェイトを下げたりもします。
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、
このサーバにまつわるよしなしごとを語ります。
English versions of some posts on another blog.
2009年12月30日水曜日
2009年12月18日金曜日
ロードアベレージが1000を超えた
12月17日の未明にftp.jaist.ac.jpのロードアベレージが1000を超えました。気がついたときには峠を過ぎていて、15分平均がちょうど1000くらいで、1分平均は120くらいまで下がっていました。忙しい間はMRTGがsnmpdからロードアベレージを正しく取れていなかったため、残念ながら証拠が残りませんでした。UltraSPARC T1は32スレッド同時に処理出来るので、1000といってもシングルコア・シングルスレッドのCPUの31くらいですけどね。
2009年12月6日日曜日
L2ARCといんちきキャッシュの折衷案
先日L2ARCが利用可能になったときに、以前紹介したいんちきキャッシュ(以降ICacheと呼びます)をお払い箱にして、SSDをすべて新しいストレージのL2ARCにしました。新しいストレージのRAID-Z2は、ARCとL2ARCで性能を補うことを前提に組んであります。これらが両方とも空になる起動直後に負荷が大きくなることは、ある程度想定していました。しかし、平均的な負荷のときの再起動の直後に、HDDへの負荷が大きすぎてサービスに支障をきたしてしまいました。
2009年11月28日土曜日
ネットワーク性能のチューニング (TCP編)
前回はsun4vアーキテクチャのSolarisでネットワーク性能を改善する方法について説明しました。今回はSolaris一般についてTCPの性能を改善する方法を説明します。
TCPの性能のチューニングといえば、まずはウィンドウサイズです。必要なウィンドウサイズは、通信相手とのRTT(ms)÷1000×帯域(bps)÷8で求められます。今どきはRTTが300msくらいあるヨーロッパ相手でも50Mbpsとか出ることがあるので、2MBはほしいです。国内については、石川県から東京を経由して行くので場所によってはRTTがいくらか大きくなりますが、悪くても50ms程度なので2MBもあれば320Mbpsまで対応できます。
TCPの性能のチューニングといえば、まずはウィンドウサイズです。必要なウィンドウサイズは、通信相手とのRTT(ms)÷1000×帯域(bps)÷8で求められます。今どきはRTTが300msくらいあるヨーロッパ相手でも50Mbpsとか出ることがあるので、2MBはほしいです。国内については、石川県から東京を経由して行くので場所によってはRTTがいくらか大きくなりますが、悪くても50ms程度なので2MBもあれば320Mbpsまで対応できます。
2009年11月26日木曜日
ネットワーク性能のチューニング (Sun Fire T2000編)
Sun Fire T2000には4ポートのGbEが装備されているので、これを束ねれば理論的には4Gbpsのスループットが出ます。しかし、Sun Fire T2000はうまくチューニングしないと、CPUに余裕がある場合でも低いスループットしかでないので注意が必要です。
2009年11月9日月曜日
新しいストレージを構築してみた(ソフト編)
前回構築したストレージでは、ホストから12個のハードディスクがそのまま見えます。これを9D+2P+1Sの構成でRAID-Z2にしました。ZFSのRAIDには1つ注意しなければならない点があります。それはRAIDを構成するディスクの数を増やしても、IOPSが増えないことです。
2009年11月8日日曜日
新しいストレージを構築してみた(ハード編)
先日壊れたSATAのディスクアレイの筐体ですが、これは寄贈してもらった試作機なので(こんなんばっかり)、修理については営業と相談してくれとサポートに言われてしまいました。お金を出して修理してまで使いたい筐体でもないので、お財布と相談して新しいストレージを調達することにしました。
2009年11月3日火曜日
L2ARCがやってきた
先日ご迷惑をおかけしたばかりですが、openSUSE 11.2のリリースの前にOSのバージョンをSolaris 10 10/09 (s10u8)に上げてしまいたかったので、日曜日の18時ごろから40分ほどftp.jaist.ac.jpを止めてしまいました。
Live Upgradeを使ったので、停止時間は再起動1回の間で済むはずだったのですが、ちょっとしたミスがあって停止時間が長くなってしまいました。敗因はluupgradeと再起動の間にZFSの構成が変わっていたことでした。luupgradeしたら、すぐに再起動しましょうね。
ともあれOSのバージョンはs10u8になり、晴れてL2ARCが使えるようになりました。L2ARCはSSDをリードキャッシュに使って、ZFSのランダムリードの性能を上げることができる仕組みです。ログをSSDに書き込んで同期書き込みの遅延を減らすZILはs10u6から使えたのですが、s10u8でようやくL2ARCが使えるようになりました。
Live Upgradeを使ったので、停止時間は再起動1回の間で済むはずだったのですが、ちょっとしたミスがあって停止時間が長くなってしまいました。敗因はluupgradeと再起動の間にZFSの構成が変わっていたことでした。luupgradeしたら、すぐに再起動しましょうね。
ともあれOSのバージョンはs10u8になり、晴れてL2ARCが使えるようになりました。L2ARCはSSDをリードキャッシュに使って、ZFSのランダムリードの性能を上げることができる仕組みです。ログをSSDに書き込んで同期書き込みの遅延を減らすZILはs10u6から使えたのですが、s10u8でようやくL2ARCが使えるようになりました。
2009年11月1日日曜日
Ubuntu 9.10のリリース直後に遅かったわけ
今回のUbuntu 9.10のリリースの際に、ftp.jaist.ac.jpが本来の性能を発揮できず、日本のUbuntuユーザの皆様にご迷惑をおかけして申し訳ありません。
今回性能を発揮できなかった理由は二つあります。一つは、ディスクアレイが一つ故障していたため、代わりにJAISTの学内インフラのEqualLogicのiSCSIストレージを借りていたこと。もう一つは、Firefoxのアップデートが突然Ubuntu 9.10のリリースの前日に降ってきたことです。
今回性能を発揮できなかった理由は二つあります。一つは、ディスクアレイが一つ故障していたため、代わりにJAISTの学内インフラのEqualLogicのiSCSIストレージを借りていたこと。もう一つは、Firefoxのアップデートが突然Ubuntu 9.10のリリースの前日に降ってきたことです。
2009年10月4日日曜日
ZFSはRAIDと相性が悪い
Sun Fire T2000には最初、2GbpsのFibre Channelに対応したSATAのディスクアレイを2基つないでいました。それぞれ14D+1P+1SのRAID 5にして、2つのvdevでZFSのpoolを1つ作りました。これはRAID 5+0に相当します。
しかし、この構成はまったく性能が出ませんでした。負荷がほぼ100%のときにディスクアレイ1基あたりで約20MB/sしか出ません。1基20MB/sなら2基合わせて40MB/s、ビットにすると320Mbps、ARCの助けを借りても、ftp.jaist.ac.jpの出力帯域は450Mbpsがいいところでした。これではSun Fire T2000が宝の持ち腐れです。
しかし、この構成はまったく性能が出ませんでした。負荷がほぼ100%のときにディスクアレイ1基あたりで約20MB/sしか出ません。1基20MB/sなら2基合わせて40MB/s、ビットにすると320Mbps、ARCの助けを借りても、ftp.jaist.ac.jpの出力帯域は450Mbpsがいいところでした。これではSun Fire T2000が宝の持ち腐れです。
2009年9月28日月曜日
KeepAliveTimeoutは2秒
先日行われた第二回 ライブドア テクニカルセミナーをustreamで見ました。pixivの中の人の話が聞けて面白かったです(資料と動画はこちら)。
そのときに出てきたのが、Apache HTTP ServerでKeepAliveTimeoutを2秒に設定しているという話です。MPMもpreforkでもworkerでもなくeventで運用しているとのことでした。eventならKeepAliveTimeoutを伸ばしてもいい気がするのですが、「安全のため」2秒にしているそうです。ちなみにftp.jaist.ac.jpのKeepAliveTimeoutも2秒です。
そのときに出てきたのが、Apache HTTP ServerでKeepAliveTimeoutを2秒に設定しているという話です。MPMもpreforkでもworkerでもなくeventで運用しているとのことでした。eventならKeepAliveTimeoutを伸ばしてもいい気がするのですが、「安全のため」2秒にしているそうです。ちなみにftp.jaist.ac.jpのKeepAliveTimeoutも2秒です。
2009年9月25日金曜日
メモリを64GB積んでみる
Sunから贈られたSun Fire T2000にはメモリが16GB積まれていました。2006年秋から話が始まって、USの決裁が下りて実物が届けられたのは2007年5月です。8コアモデルにメモリ16GBですから、当時としてはがんばった構成だったと思います。16あるメモリスロットに、1GBメモリがぎっちり刺さっていました。
2009年9月24日木曜日
SSDによるコンテンツキャッシュ(ソフト編)
ZFSにはSSDをキャッシュに使ってランダムリードの性能を稼ぐL2ARCという仕掛けがあります。L2ARCはOpenSolarisでは使えるのですが、Solaris 10ではまだ使えません。10u6 (10/08)で使えるようになると言われていたのが延期されて、今年の10u7 (5/09)で使えるだろうと思っていたのが、また延期されてしまいました。実は10u7に合わせてSSDを購入したのですが、当てが外れてしまいました。
仕方ないのでバージョン2.2から実用可能になったApacheのmod_disk_cacheを使おうかと思ったのですが、これがうまくありませんでした。
仕方ないのでバージョン2.2から実用可能になったApacheのmod_disk_cacheを使おうかと思ったのですが、これがうまくありませんでした。
2009年9月19日土曜日
SSDによるコンテンツキャッシュ(ハード編)
先日のエントリでSun Fire T2000はUltraSPARC T1には4Gbpsの帯域を埋める能力があると書きましたが、それを実現するには一つボトルネックを解決しなければなりません。それはディスクI/Oです。最近の速いハードディスクでも最外周で100MB/sくらいしか出ません。ビットにすると800Mbpsですね。ぜんぜん足りないのでRAIDを組んで性能を稼ぐ必要があります。
2009年9月17日木曜日
Firefoxが10億回ダウンロードされたのは本当か
Mozilla Foundationが7月31日にFirefoxが10億回ダウンロードされたとアナウンスし、特設サイトも作られました。この回数はどうやって数えたのでしょうか?
皆さんもご存知の通り、mozilla.comのDownload Firefoxのボタンを押すと世界中のミラーサーバに飛ばされます。Mozilla Foundationが把握できるのはクリックされた回数だけで、本当にダウンロードされたかどうかはわかりません。では、クリックされた回数が10億回と言ってるのかというと、そうでもないようです。
皆さんもご存知の通り、mozilla.comのDownload Firefoxのボタンを押すと世界中のミラーサーバに飛ばされます。Mozilla Foundationが把握できるのはクリックされた回数だけで、本当にダウンロードされたかどうかはわかりません。では、クリックされた回数が10億回と言ってるのかというと、そうでもないようです。
2009年9月15日火曜日
worker MPMの設定(後編)
前回の話で何がいけなかったのかというとMaxSpareThreadsが小さすぎたのです。MaxSpareThreadsはクライアント数の変動幅より十分大きくないと、プロセスの終了と起動の頻度が高くなり、結果として終了待ちプロセスの数が増えてしまいます。
MaxSpareThreadsをMaxClientsに合わせてしてしまえば、MaxSpareThreadsが理由でプロセスが終了することはなくなります。しかし、不要なプロセスを起動したままにするのも気持ちが悪いので、できることなら適切に終了させたいものです。
MaxSpareThreadsをMaxClientsに合わせてしてしまえば、MaxSpareThreadsが理由でプロセスが終了することはなくなります。しかし、不要なプロセスを起動したままにするのも気持ちが悪いので、できることなら適切に終了させたいものです。
worker MPMの設定(前編)
ftp.jaist.ac.jpではHTTPサーバとしてApache HTTP Server (以降Apacheと略記)を使っています。lighttpdじゃないんですかって? えぇ、違います。SourceForge.netのミラーネットワークに参加するためには、Apacheのmod_rewriteを前提にした複雑なURL書き換え規則を受け入れる必要があるので、Apacheでないとだめなんです。
2009年9月14日月曜日
net-snmpのC10K問題(後編)
なぜsnmpdがリクエストに答えないのか突き止めるべく、まずprstat (topみたいなやつ)で様子を見てみたら、snmpdが3%以上のCPU使用率でトップに君臨していました。この使用率は32CPUで計算されているので、本当は8コアのUltraSPARC T1にはかなりの重荷です。
いったい何をそんなに忙しくしているのかとtrussで追ってみたら、ひたすらファイル記述子6番からgetmsgでメッセージを読んでいました。このメッセージの読み込みが忙しくてリクエストに答えるひまがないようです。
いったい何をそんなに忙しくしているのかとtrussで追ってみたら、ひたすらファイル記述子6番からgetmsgでメッセージを読んでいました。このメッセージの読み込みが忙しくてリクエストに答えるひまがないようです。
net-snmpのC10K問題(前編)
昔C10K問題というのが話題になりました。Y2K問題をもじった名前なので2000年から数年間くらいですね。インターネットのバックボーンが1Gbpsに到達した。GbEを備えた1GHzのCPUのサーバが安価に手に入るようになった。しかし、10,000クライアントを同時にさばこうとすると、ハードウェアではなくOSがボトルネックになるという問題です。
UltraSPARC T1の弱点とUltraSPARC T2
UltraSPARC T1には決定的に向かない仕事があります。各コアは整数ユニットは持ってるんですが、浮動小数点ユニットは8つのコアで共有していて、浮動小数点ユニットを使うだけで40サイクルのペナルティがあります。だから浮動小数点演算をたくさんする仕事はだめです。
2009年9月13日日曜日
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の。
UltraSPARC T1は8つのコアのそれぞれで4つのスレッドを実行できるので、OSから見ると32個CPUがあるように見えます。ところが、各コアは4つのスレッドのうち実行可能なものをクロックごとに順番に実行するだけなので、残念ながら実力はCPU 8個分です。 それもとても遅いCPUの。
登録:
投稿 (Atom)