ログファイルの圧縮方法
圧縮レベル2と3では、bzip2よりずっと短い所要時間で高い圧縮率が得られています。興味深いのはレベル4で、所要時間が大きく増えたのに圧縮率が下がっています。xzはレベル4からLZ法の一致文字列を探すアルゴリズムが変わるので、これが裏目に出ているようです。 bzip2より2割以上高い圧縮率が得られるレベル7以上では、所要時間は5倍以上になります。ログファイルの圧縮方式が混ざるのは何かと面倒なので、5倍の所要時間でこの程度の圧縮率の差ではxzに変更する気にはなれないです。 圧縮率はそうでもないですが、xzの伸張速度の速さはとても魅力的です。デフォルトの圧縮率のファイルを伸張するのに、bzip2が1分22秒かかるのに対してxzは25秒しか掛かりません。ログを集計するときに伸張速度が3倍近く速いのはとても有利です。 もし圧縮方法を決め直せるならxzにするかもしれません。適宜レベルを調節してbzi
ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/...
以下のURLにアクセスできるのを見て、「おかしいんじゃないか」とか、「どんだけUbuntu好きなんだよw」とか言っているのを、ときどきtwitterで見掛けます。 http://ftp.jaist.ac.jp/pub/Linux/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ これは/pub/Linux/ubuntu/にubuntu -> .というシンボリックリンクがあるだけです。そのため、パスに含むことができるシンボリックリンクの数の最大まで、ubuntuを繰り返せます。ftp.jaist.ac.jpはSolaris 10なので20個です。 ミ
10GbEのNICを挿してみた
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Ubuntu 12.04の前日にFirefox 12がリリースされることに、Ubuntu 12.04のリリースの数日前に気が付きました。Firefox 12のリリースが4月25日の朝で、Ubuntu 12.04のリリースは4月26日の22時くらいです。Firefoxの更新の初日はピークで3.7Gbpsくらい帯域を使用し、翌日も3Gbpsを超えることがあります。特に22時以降はアメリカの東海岸のFirefoxの更新が増えるので、これがUbuntu 12.04のリリースにぶつかるとftp.jaist.ac.jpの帯域の上限の4Gbpsを超える可能性があります。そこで急き
L2ARCを止めてみた(後編)
前編に書いたように、pcacheをARCでキャッシュしない設定でデータを取ってみたところ、ARCのヒット率は93.4%から59.8%にL2ARCは63.5%から3.6%に激減しました。pcacheはほぼ変わらず59.8%です。ARC、L2ARCともにヒットしたデータは、ほとんどpcacheからもたらされたものであったことがわかります。L2ARCにいたってはほとんどがそうでした。このときの処理の流れを示したのが以下の図です。 以下のグラフのようにストレージの負荷は、ピークでも60%以下にに下がりました。SSDの負荷が当然上がりますが60%以下にとどまっています。SSDのI/Oは、pcacheのreadが1日平均で345.4MB/s、writeが0.3MB/s、L2ARCは readが11.6MB/s、writeが11.1MB/sです。L2ARCが書いただけ読んでいる傾向は同じです。つまり f
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したときに残ったファイルの領域がすべて解
RAID-Zは遅いよ
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 以前紹介しましたが、ftp.jaist.ac.jpのストレージは2TBのDeskstar 7K2000を24個積んでいます。ZFSの構成は、11個ずつでRAID-Z2を2つ作りストライピングしています。残りの2個はRAID-Z2のスペアです。この構成の問題は読み込みのIOPS (1秒間あたりに可能な読み込み回数)がとても少ない低いことです。 RAID-Zは普通のRAIDと異なり、RAIDを組むディスクの個数を増やしても読み込みのIOPSは上がりません。普通のRAIDでは複数のブロックへのアクセスを複数のディスクで同時に行えるので、ディスクの数を増やせばIOPSが向上
新しいサーバを構築中
日本最強の看板を下ろしたミラーサーバ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の管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 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
メモリを64GB積んでみる
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Sunから贈られたSun Fire T2000にはメモリが16GB積まれていました。2006年秋から話が始まって、USの決裁が下りて実物が届けられたのは2007年5月です。8コアモデルにメモリ16GBですから、当時としてはがんばった構成だったと思います。16あるメモリスロットに、1GBメモリがぎっちり刺さっていました。 16GBのメモリに対して、普通の負荷のときのユーザプロセスによる使用量はわずか1.7GBで、残りのほとんどはカーネルメモリキャッシュでした。そのうちZFSのARCが7.7GBで、2.6GBは使われていなかったので、16GBで足りないと思ったことはあり
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がいいところでした
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Raspberry PiのSDカードイメージのミラーを始めました