ログファイルの圧縮方法
圧縮レベル2と3では、bzip2よりずっと短い所要時間で高い圧縮率が得られています。興味深いのはレベル4で、所要時間が大きく増えたのに圧縮率が下がっています。xzはレベル4からLZ法の一致文字列を探すアルゴリズムが変わるので、これが裏目に出ているようです。 bzip2より2割以上高い圧縮率が得られるレベル7以上では、所要時間は5倍以上になります。ログファイルの圧縮方式が混ざるのは何かと面倒なので、5倍の所要時間でこの程度の圧縮率の差ではxzに変更する気にはなれないです。 圧縮率はそうでもないですが、xzの伸張速度の速さはとても魅力的です。デフォルトの圧縮率のファイルを伸張するのに、bzip2が1分22秒かかるのに対してxzは25秒しか掛かりません。ログを集計するときに伸張速度が3倍近く速いのはとても有利です。 もし圧縮方法を決め直せるならxzにするかもしれません。適宜レベルを調節してbzi
mixiのサーバーOS移行について
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. mixiのサーバーOSの移行の話がブログ(mixiのサーバOS移行のお話、mixiのサーバOS移行のお話 - 前回補足＆インストール編)で公開されました。移行先がFedora 17だったことについて否定的な見解を示す人が多いです。私ならこの選択はしませんが、真っ向から否定するほど合理性を欠く選択だったとは思っていません。 移行する前はmixiはFedora 8で運用していました。 Fedoraプロジェクトによるパッケージの更新が止まったあとは、長年自力でメンテナンスしています。mixiのLinuxシステムは、当初のFedora 8とは大きく異なるものになっているはず
Apache httpd 2.4.1を試してみた
接続数とリクエスト/秒はserver-statusハンドラーで取得したものです。使用帯域については、2.2のserver-statusは正確な値を返さないので2.4.1とは比較できません。そこでネットワークインターフェイスの出力帯域の直近の5分平均を採りました。メモリーの使用量とCPUの使用率は、httpdのプロセスの合計の値をprstat -aで調べました。 出力帯域を見る限り、どちらのバージョンも同様な負荷状況にあります。出力帯域にはFTPやrsyncも含まれていますが、HTTPがほとんどだからです。しかし、接続数やリクエスト/秒は2.2.22より2.4.1のほうがずっと小さいです。まだソースコードを読んでいないので正確なことはわかりませんが、計測方法が異なっているためではないかと思います。問題のメモリーとCPUの使用状況ですが、2.2.22よりも2.4.1のほうが2倍以上大きくなって
新しいサーバのCPUとメモリを増設してみた
以前新しいサーバを準備中であることを紹介しました。しかし、httpdのmod_limitipconnを外したらかなり余裕ができて、Sun Fire T2000でも何とかなっていたので長い間リプレースせずにいました。今は本当に限界なのでリプレースの準備をしています。 その際にCPUとメモリを増設して、CPUを48コアにメモリを192GBにしました。DIMMスロットが32あるのにメモリが192GBなのは、以前積んでいた4GB×16枚に8GB×16枚を混載したからです。仮想化を用いない単一のシステムに、これだけのCPUとメモリを載せるのは珍しいのではないでしょうか。 増設は意外と苦戦しました。最初に増設したときにはブートしませんでした。調べたらCPUソケットのピンが1本曲がっていました。これを針でつんつんして直したらブートしました。曲がっている写真が左、直したあとが右です。まだ少し変形しています
トラフィックの新記録が出ました
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 昨日のFirefox 6のリリースで、ftp.jaist.ac.jpが流したトラフィックの新記録が出ました。5分平均で3835.9Mbpsがその記録です。実際には一時的に4Gbpsの上限にぶつかっています。23時過ぎにトラフィックがガクッと落ち込んでいるのは、上限にぶつかったためBouncerから死亡判定を受けてトラフィックが割り当てられなくなったためです。 0時前後にも何度かトラフィックが落ち込んでいますが、これはCPUが耐えられなくなってBouncerから死亡判定を受けたためです。ロードアベレージは0時前後に90近くに達しています。UltraSPARC T1は3
新しいサーバを構築中
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 今のSun Fire T2000はCPUの処理能力が不足気味なので、処理能力の高いサーバに置き換えることにしました。UltraSPARC T2のT5120が1台あるのですが、メモリが16GBしかないので増設する必要があります。しかし純正メモリはとても高いし、適当なメモリを刺したら保守が効かなくなります。そこで新たにx86サーバを1台作ることにしました。 ミラーサーバのワークロードはメモリ帯域が十分あればCPUのコアの数だけスケールするので、コア数の多いOpteron 6100シリーズを採用しました。Supermircoの4ソケットのベアボーン2042G-TRFに、今
BufferedLogsは効果絶大
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Apache HTTP ServerのBufferedLogsディレクティブは、マニュアルでexperimentalとされていたので今まで試していませんでした。BufferedLogsディレクティブを有効にすると、リクエストごとにログを出力せずに、いったんバッファに蓄えてまとめて出力するようになります。 マニュアルにはBufferedLogsディレクティブによってディスクアクセスが効率的になると書かれていますが、これが効いてくるのはむしろパイプ経由のログ出力です。ログがパイプに出力されて、パイプの反対側のプログラムが実行可能になる頻度が下がるからです。このところCP
ftp.jaist.ac.jpの最も忙しい一日
昨日、Firefox 4.0β5/3.6.9/3.5.12、Thunderbird 3.1.3/3.0.7、SeaMonkey 2.0.7が同時にリリースされました。そのせいでftp.jaist.ac.jpには、これまでにないほど高い負荷が掛かっていました。 CPUの使用率は昼過ぎから翌朝まで、ほぼ100%に張り付いたままでした。ロードアベレージは、パイプ経由のログ出力を一つ止めるのを忘れていたため12時前に一度跳ね上がっていますが、止めたところいったん落ち着きました。しかし、アメリカが活動時間に入ると1000を超えて、しばらく下がりませんでした。ロードアベレージのグラフはログスケールです。 いつもならロードアベレージが1000を超えると、急激に性能が悪化して処理が追い付かなくなり、Bouncerによってアクセスの割り当てが止められます。割り当ての停止が繰り返し起こると、Bouncerがサ
ロードアベレージが10,000を超えた
昨日Firefox 3.6.4と3.5.10がリリースされたのですが、今回はCPUが忙しかったです。何度かロードアベレージが10,000を超えました。 ロードアベレージとCPUの使用率のmrtgによるグラフは以下の通りです。 上のuptimeは、ロードアベレージのグラフが最初に5,000を超えたときに取ったものです。ロードアベレージが10,000を超えていても普通にuptimeが返ってくるのは、さすがSun Fire T2000といったところでしょうか。 CPUの使用率は深夜から朝にかけて100%に張り付いたままでした。前に100%に張り付いた時にはhttpdのバージョンアップでしのぐことができましたが、今回はどうにもなりませんでした。
ヤフオクで落札したQuad GbEを増設してみた
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 以前のエントリで書いたように、4つあるネットワークインターフェイスを全部アグリゲートしていたのをやめて、2本ずつアグリゲートしてIPMPでロードバランスするようにしてみました。しかし、インターフェイスが突然応答しなくなる症状は治まるどころか、よけいにひどくなってしまいました。 以前の構成では1本死ぬとすぐに全滅していたのですが、この構成ではアグリゲーションが1組だけ死んで、もう一方は生き残ります。ほおっておけば全滅するのでしょうが、その前に死んでいるアグリゲーションをunplumb/plumbして起こせば復旧できます。これでしばらくしのいでいたのですが、さすがに無理
オンボードのGbEの性能が出ませんでした
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 2月18日の朝から定例のFirefoxのアップデートが始まりました。今回は借りていたSun Multithreaded 10 GbE Networking Card (nxge)を返却していたので、オンボードの4つのGbEをアグリゲートして立ち向かったのですが、見事に玉砕しました。 18日の18時ごろに急に出力パケットが詰まり、外からのpingにも応えなくなったので、一番怪しいLSOを切って19時ごろにリブートしました。ところが1時間も経たないうちにまた詰まってしまったので、今度はJumbo Frameを切って21時15分ごろにリブートしたのですが、ちょっと手違いが
Mozilla.orgのミラーネットワーク
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 以前のエントリでも取り上げましたが、Firefoxのダウンロードやアップデートのアクセスは、国や地域に関係なく世界中のミラーサーバに振り分けられます。この負荷分散を行っているのがBouncerと呼ばれるプログラムです。Bouncerは各サーバに割り当てられたウェイトに基づいて負荷を割り振ります。各サーバの稼働状況も確認して、止まっているサーバへの割り当てを止めたり、過負荷のサーバのウェイトを下げたりもします。 ウェイトは自己申告です。大きすぎてさばききれなければ、Bouncerがそれを検出して徐々に下げます。あまりにもつらければ、IRCで下げてーって叫ぶと手動で下げ
ロードアベレージが1000を超えた
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 12月17日の未明にftp.jaist.ac.jpのロードアベレージが1000を超えました。気がついたときには峠を過ぎていて、15分平均がちょうど1000くらいで、1分平均は120くらいまで下がっていました。忙しい間はMRTGがsnmpdからロードアベレージを正しく取れていなかったため、残念ながら証拠が残りませんでした。UltraSPARC T1は32スレッド同時に処理出来るので、1000といってもシングルコア・シングルスレッドのCPUの31くらいですけどね。 12月16日の朝にFirefox 3.5.6がリリースされました。翌午前1時くらいにアメリカのからのアクセ
ネットワーク性能のチューニング (TCP編)
前回はsun4vアーキテクチャのSolarisでネットワーク性能を改善する方法について説明しました。今回はSolaris一般についてTCPの性能を改善する方法を説明します。 TCPの性能のチューニングといえば、まずはウィンドウサイズです。必要なウィンドウサイズは、通信相手とのRTT(ms)÷1000×帯域(bps)÷8で求められます。今どきはRTTが300msくらいあるヨーロッパ相手でも50Mbpsとか出ることがあるので、2MBはほしいです。国内については、石川県から東京を経由して行くので場所によってはRTTがいくらか大きくなりますが、悪くても50ms程度なので2MBもあれば320Mbpsまで対応できます。 受信ウィンドウの最大値を決めるカーネルパラメータはtcp_recv_hiwatで、デフォルトは48KiBです。ミラーサーバは受信のスループットをあまり必要としませんが、これはあまりにも
L2ARCがやってきた
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 先日ご迷惑をおかけしたばかりですが、openSUSE 11.2のリリースの前にOSのバージョンをSolaris 10 10/09 (s10u8)に上げてしまいたかったので、日曜日の18時ごろから40分ほどftp.jaist.ac.jpを止めてしまいました。 Live Upgradeを使ったので、停止時間は再起動1回の間で済むはずだったのですが、ちょっとしたミスがあって停止時間が長くなってしまいました。敗因はluupgradeと再起動の間にZFSの構成が変わっていたことでした。luupgradeしたら、すぐに再起動しましょうね。 ともあれOSのバージョンはs10u8に
Ubuntu 9.10のリリース直後に遅かったわけ
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 今回のUbuntu 9.10のリリースの際に、ftp.jaist.ac.jpが本来の性能を発揮できず、日本のUbuntuユーザの皆様にご迷惑をおかけして申し訳ありません。 今回性能を発揮できなかった理由は二つあります。一つは、ディスクアレイが一つ故障していたため、代わりにJAISTの学内インフラのEqualLogicのiSCSIストレージを借りていたこと。もう一つは、Firefoxのアップデートが突然Ubuntu 9.10のリリースの前日に降ってきたことです。 Firefoxのアナウンスの日付はUbuntuの二日前ですが、日本時間ではFirefoxが28日の正午、U
SSDによるコンテンツキャッシュ(ソフト編)
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. ZFSにはSSDをキャッシュに使ってランダムリードの性能を稼ぐL2ARCという仕掛けがあります。L2ARCはOpenSolarisでは使えるのですが、Solaris 10ではまだ使えません。10u6 (10/08)で使えるようになると言われていたのが延期されて、今年の10u7 (5/09)で使えるだろうと思っていたのが、また延期されてしまいました。実は10u7に合わせてSSDを購入したのですが、当てが外れてしまいました。 仕方ないのでバージョン2.2から実用可能になったApacheのmod_disk_cacheを使おうかと思ったのですが、これがうまくありませんでした
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTPリクエストに基づくファイルキャッシュ機構