過負荷で接続が困難です
今朝リリースされたCentOS 7へのアクセスが殺到しているため、昼過ぎからftp.jaist.ac.jpへの接続が困難になっています。14時過ぎにはロードアベレージが900を超えました。過去の例では、この辺で処理が詰まって応答しなくなるのでユーザーから見放してもらえるのですが、今回はロードアベレージが1000を超えても処理が継続しているため、負荷が下がらない状況となっています。 どうにもならないので、18時の段階でCentOS 7のディレクトリのパーミッションを落としました。アクセスすると403 Forbiddenになります。CentOS 7をダウンロードする際には以下のいずれかのミラーを使ってください。 http://ftp.iij.ad.jp/pub/linux/centos/7/ http://ftp.riken.jp/Linux/centos/7/ http://ftp.tsuk
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とは大きく異なるものになっているはず
新しいサーバの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. 普通のRAIDでもRAID-Zでも複数のディスクにデータがストライピングされます。ディスクの本数を増やせばシーケンシャルリードは速くなると一般に言われていますし、実際そうです。ランダムリードとはいえ、ストライピングされているのにRAID-Zが遅いことに納得できない人が多いようです。何の説明が足りないか考えていて、ハードディスクの遅延を忘れていたことに気が付きました。僕もそれを忘れていたため誤った説明をしていました。 ハードディスクでは、リクエストを受けてから読み込むまでにシークと回転待ちの遅延が発生します。こちらのレビューを見るとDeskstar 7K2000の遅延
大きすぎるl2arc_write_maxはよくない
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. この記事は全面的に間違えています。この記事はZFSのL2ARCの性能を向上させる方法として以下のものを紹介しています。 ZFSのレコードサイズを128KBよりずっと小さなものにする l2arc_write_maxをより大きくする l2arc_noprefetchを0に設定する これらすべては悪い結果しか生みません。 まず絶対にZFSのレコードサイズを特定の値に設定してはいけません。唯一の例外はZFSをDBMSに使うときだけです。ZFSは自動的にファイルごとにレコードサイズを適切に設定します。レコードサイズを設定するとこれが台なしになります。 L2ARCのSSDへの書
Solaris 10 08/11 (u10)へのアップグレードではまった
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 以前からpcacheのZFSで、消したファイルの領域が解放されない現象に悩まされていました。ファイルをオープンしているプロセスがいるならわかるのですが、サービスを全部止めてオープンしているプロセスがいなくなっても空き領域が増えないのです。その結果、duで確認した使用量とdfで確認した使用量がどんどん乖離していきます。 この症状がひどくなって空き領域がなくなったときは、一度umountしてmountすると回復します。unlinkされたファイルの情報はumount -fされた場合に備えてファイルシステムに記録されていて、mountしたときに残ったファイルの領域がすべて解
トラフィックの新記録が出ました
日本最強の看板を下ろしたミラーサーバ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
ZFSはRAIDと相性が悪い
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 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がいいところでした
BufferedLogsは効果絶大
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Apache HTTP ServerのBufferedLogsディレクティブは、マニュアルでexperimentalとされていたので今まで試していませんでした。BufferedLogsディレクティブを有効にすると、リクエストごとにログを出力せずに、いったんバッファに蓄えてまとめて出力するようになります。 マニュアルにはBufferedLogsディレクティブによってディスクアクセスが効率的になると書かれていますが、これが効いてくるのはむしろパイプ経由のログ出力です。ログがパイプに出力されて、パイプの反対側のプログラムが実行可能になる頻度が下がるからです。このところCP
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
ログローテーションはrotatelogsで、圧縮はpbzip2で
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Apache HTTP Serverで日ごとに別のファイルにログを出力するのは、標準添付されているrotatelogsでできるのですが、意外と知られていないようです。アクセスログならこんな感じです。 CustomLog "|/インストール先/bin/rotatelogs /出力先/access_log.%Y%m%d 86400 540" combined マニュアル通りなら、この設定ではrotatelogsが起動してから24時間で出力先のログファイルが切り替わりそうに見えます。しかし、実際にはrotatelogsはtime(2)の返す値を86400秒で丸めてから開始
Fedoraは週末に強い
最近、http://ftp.jaist.ac.jp/で直近2時間くらいのダウンロード傾向がわかるようにしてみました。サーバで30分に1度データを生成して、ブラウザがAjaxで取ってきてCSSで描画します。データの生成は、SSDにキャッシュするファイルを決定するプログラムにやらせています。 このグラフをながめていて面白いことに気がつきました。上位5位くらいは不動でmozilla.org、sourceforge.net、CentOS、Fedora、mergedocと続くのですが、週末にだけFedoraとCentOSの順位が逆転するのです。Firefoxのアップデートがあった週は量が異常に多いので除いて、今年のログ全部について集計してみたらやはりそうなっていました。 Fedoraはオフィスより家庭でより多く使われているのでしょう。逆に、mozilla.orgのダウンロードは週末に減っています。m
ロードアベレージが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時くらいにアメリカのからのアクセ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ubuntuのアップデートを高速化する方法