タグ

ブックマーク / ftp-admin.blogspot.com (5)

  • ロードアベレージが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時くらいにアメリカのからのアクセ

    ロードアベレージが1000を超えた
  • 新しいストレージを構築してみた(ソフト編)

    最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 前回構築したストレージでは、ホストから12個のハードディスクがそのまま見えます。これを9D+2P+1Sの構成でRAID-Z2にしました。ZFSのRAIDには1つ注意しなければならない点があります。それはRAIDを構成するディスクの数を増やしても、IOPSが増えないことです。 ZFSのRAIDはブロックを書くときに、ブロックサイズに合わせてストライプサイズを変えて、すべてのディスクに書きます。ブロックを読むときはパリティを除くすべてのディスクから読みます。ブロックサイズが小さすぎて、ストライプサイズが512バイトよりも小さくなるときには、書き込むディスクの数を減らしま

  • KeepAliveTimeoutは2秒

    最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 先日行われた第二回 ライブドア テクニカルセミナーをustreamで見ました。pixivの中の人の話が聞けて面白かったです(資料と動画はこちら)。 そのときに出てきたのが、Apache HTTP ServerでKeepAliveTimeoutを2秒に設定しているという話です。MPMもpreforkでもworkerでもなくeventで運用しているとのことでした。eventならKeepAliveTimeoutを伸ばしてもいい気がするのですが、「安全のため」2秒にしているそうです。ちなみにftp.jaist.ac.jpのKeepAliveTimeoutも2秒です。 HTT

  • net-snmpのC10K問題(後編)

    最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. なぜsnmpdがリクエストに答えないのか突き止めるべく、まずprstat (topみたいなやつ)で様子を見てみたら、snmpdが3%以上のCPU使用率でトップに君臨していました。この使用率は32CPUで計算されているので、当は8コアのUltraSPARC T1にはかなりの重荷です。 いったい何をそんなに忙しくしているのかとtrussで追ってみたら、ひたすらファイル記述子6番からgetmsgでメッセージを読んでいました。このメッセージの読み込みが忙しくてリクエストに答えるひまがないようです。 こんなときはlsofがあると簡単なんですが、インストールしていなかったので

  • net-snmpのC10K問題(前編)

    最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 昔C10K問題というのが話題になりました。Y2K問題をもじった名前なので2000年から数年間くらいですね。インターネットのバックボーンが1Gbpsに到達した。GbEを備えた1GHzのCPUのサーバが安価に手に入るようになった。しかし、10,000クライアントを同時にさばこうとすると、ハードウェアではなくOSがボトルネックになるという問題です。 当時はsendfileのようなゼロコピーsendのシステムコールはありませんでした。大量のスレッドを効率よく実行できるのは一部の商用OSだけでした。大量のファイル記述子の状態変化を効率よく待つ仕掛けもありませんでした。これでは

    net-snmpのC10K問題(前編)
  • 1