ログファイルの圧縮方法
圧縮レベル2と3では、bzip2よりずっと短い所要時間で高い圧縮率が得られています。興味深いのはレベル4で、所要時間が大きく増えたのに圧縮率が下がっています。xzはレベル4からLZ法の一致文字列を探すアルゴリズムが変わるので、これが裏目に出ているようです。 bzip2より2割以上高い圧縮率が得られるレベル7以上では、所要時間は5倍以上になります。ログファイルの圧縮方式が混ざるのは何かと面倒なので、5倍の所要時間でこの程度の圧縮率の差ではxzに変更する気にはなれないです。 圧縮率はそうでもないですが、xzの伸張速度の速さはとても魅力的です。デフォルトの圧縮率のファイルを伸張するのに、bzip2が1分22秒かかるのに対してxzは25秒しか掛かりません。ログを集計するときに伸張速度が3倍近く速いのはとても有利です。 もし圧縮方法を決め直せるならxzにするかもしれません。適宜レベルを調節してbzi
RAID-Zの読み込みのIOPSはなぜ低いのか
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 現在ftp.jaist.ac.jpはストレージの性能不足に悩まされています。ピーク時にストレージのI/Oが飽和して、スループットがやや低くなることがあります。ストレージは11本のHDDで組んだRAID-Z2を2組たばねて構成しています。読み込みのIOPSは、HDDが22本あるのに約600しか出ません。HDDのIOPSは約180出ているので、全体のIOPSはHDDの約3.6本分になります。 これはあくまでもキャッシュなしの性能です。読み込みのI/Oの98%はARCかL2ARCのいずれかにヒットするので、キャッシュ込みのIOPSは約30,000となります。最近はこれでも
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とは大きく異なるものになっているはず
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が向上
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を使おうかと思ったのですが、これがうまくありませんでした
ftp-adminの憂鬱
最初に、5月12～13日の計画停電によるシステム停止で、ご迷惑をおかけしたことをおわびします。 このタイミングでftp.jaist.ac.jpのハードウェアのリプレースを行いました。新しいサーバーはAMD EPYC 7551Pを一つ搭載したDell PowerEdge R7415です。従来はSupermicro 2024GにOpteron 6344を4つ搭載して48コアでしたが、今回はシングルソケットで32コアとなります。 従来からJAISTは、Dellから機材の提供を受けて評価することを継続的に行っていました。今回EPYCを試したい旨打診したところ、DellがEPYCを推していることもあり、機材を提供していただけることになりました。 シングルソケットなのは、Dellが推しているのがこの構成であることと、Solaris 11 for x86のライセンス費がソケット単位なので、ライセンス費が
BufferedLogsは効果絶大
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Apache HTTP ServerのBufferedLogsディレクティブは、マニュアルでexperimentalとされていたので今まで試していませんでした。BufferedLogsディレクティブを有効にすると、リクエストごとにログを出力せずに、いったんバッファに蓄えてまとめて出力するようになります。 マニュアルにはBufferedLogsディレクティブによってディスクアクセスが効率的になると書かれていますが、これが効いてくるのはむしろパイプ経由のログ出力です。ログがパイプに出力されて、パイプの反対側のプログラムが実行可能になる頻度が下がるからです。このところCP
パイプ経由のログ出力はCPUを浪費する
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. Apache HTTP Serverでログをパイプ経由でプログラムに出力すると、リクエストを処理するたびにログを処理するプログラムへのコンテキストスイッチが起こります。そのためアクセスが増えたときにCPUをかなり浪費します。UltraSPARC T1は32個のコンテキストを保持できて、1クロックでコンテキストスイッチできるので問題ないと思っていました。しかし、CPUの使用率が100%に達して、さらに負荷が掛かる状況になると違いました。 ftp.jaist.ac.jpにはパイプ経由のログ出力が3つあります。エラーログとアクセスログのrotatelogsへの出力と、以前
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
