ログファイルの圧縮方法

以前紹介したのですが、ftp.jaist.ac.jpのアクセスログの圧縮にはpbzip2を使っています。最初はgzipを使っていましたが、アクセス数の増加とともにログが大きくなって、ディスク容量を圧迫するようになってきたのでbzip2に切り替えました。

Apache httpd 2.4.1を試してみた

Apache httpd 2.4.1をftp.jaist.ac.jpで試してみました。最初にevent MPMを試したのですが、起動してから数分で応答がだんだん遅くなって、最後には応答を返さなくなるので使用を断念しました。次にworker MPMを試したのですが、2.2.22と比べてメモリーとCPUをかなり大きく使います。

SSD cache for Apache httpd

Our server has four SSDs (Intel X25-M 160GB). We are using two for L2ARC of ZFS. We need another cache just after boot up because L2ARC is volatile. We create an original caching mechanism named pcache (periodic file caching), and use two SSDs for it.

HTTPリクエストに基づくファイルキャッシュ機構

HTTPリクエストに基づくファイルキャッシュ機構のソースを公開しました。リクエストをしばらく集計してからキャッシュするファイルを決めて、非同期にファイルをSSDにキャッシュするので、mod_disk_cacheのようにリクエスト時にクライアントを待たせることがありません。技術的な概要は前に説明した通りです。この説明と大きく異なるのは、rsyncを実行しないで自前でファイルを更新することです。

BufferedLogsは効果絶大

Apache HTTP ServerのBufferedLogsディレクティブは、マニュアルでexperimentalとされていたので今まで試していませんでした。BufferedLogsディレクティブを有効にすると、リクエストごとにログを出力せずに、いったんバッファに蓄えてまとめて出力するようになります。

パイプ経由のログ出力はCPUを浪費する

Apache HTTP Serverでログをパイプ経由でプログラムに出力すると、リクエストを処理するたびにログを処理するプログラムへのコンテキストスイッチが起こります。そのためアクセスが増えたときにCPUをかなり浪費します。UltraSPARC T1は32個のコンテキストを保持できて、1クロックでコンテキストスイッチできるので問題ないと思っていました。しかし、CPUの使用率が100%に達して、さらに負荷が掛かる状況になると違いました。

ftp.jaist.ac.jpにはパイプ経由のログ出力が3つあります。エラーログとアクセスログのrotatelogsへの出力と、以前紹介したSSDキャッシュのためのプログラムへの出力です。アクセスが多いときには最後の1つを止めていました。これを止めないと13,500クライアント、660リクエスト/秒が限界で、ロードアベレージが10,000を超えます。止めれば17,000クライアント、790リクエスト/秒までいけます。rotatelogsをやめてファイルにログを直接出力するようにすれば、さらに余力ができるはずです。今後はFirefoxのアップデートで欧米からのアクセスがなくなるので、そこまで逼迫することはないでしょうけど。

ログローテーションはrotatelogsで、圧縮はpbzip2で

Apache HTTP Serverで日ごとに別のファイルにログを出力するのは、標準添付されているrotatelogsでできるのですが、意外と知られていないようです。アクセスログならこんな感じです。

CustomLog "|/インストール先/bin/rotatelogs /出力先/access_log.%Y%m%d 86400 540" combined

ロードアベレージが1000を超えた

12月17日の未明にftp.jaist.ac.jpのロードアベレージが1000を超えました。気がついたときには峠を過ぎていて、15分平均がちょうど1000くらいで、1分平均は120くらいまで下がっていました。忙しい間はMRTGがsnmpdからロードアベレージを正しく取れていなかったため、残念ながら証拠が残りませんでした。UltraSPARC T1は32スレッド同時に処理出来るので、1000といってもシングルコア・シングルスレッドのCPUの31くらいですけどね。

KeepAliveTimeoutは2秒

先日行われた第二回 ライブドア テクニカルセミナーをustreamで見ました。pixivの中の人の話が聞けて面白かったです(資料と動画はこちら)。

そのときに出てきたのが、Apache HTTP ServerでKeepAliveTimeoutを2秒に設定しているという話です。MPMもpreforkでもworkerでもなくeventで運用しているとのことでした。eventならKeepAliveTimeoutを伸ばしてもいい気がするのですが、「安全のため」2秒にしているそうです。ちなみにftp.jaist.ac.jpのKeepAliveTimeoutも2秒です。

SSDによるコンテンツキャッシュ(ソフト編)

ZFSにはSSDをキャッシュに使ってランダムリードの性能を稼ぐL2ARCという仕掛けがあります。L2ARCはOpenSolarisでは使えるのですが、Solaris 10ではまだ使えません。10u6 (10/08)で使えるようになると言われていたのが延期されて、今年の10u7 (5/09)で使えるだろうと思っていたのが、また延期されてしまいました。実は10u7に合わせてSSDを購入したのですが、当てが外れてしまいました。

仕方ないのでバージョン2.2から実用可能になったApacheのmod_disk_cacheを使おうかと思ったのですが、これがうまくありませんでした。

worker MPMの設定(後編)

前回の話で何がいけなかったのかというとMaxSpareThreadsが小さすぎたのです。MaxSpareThreadsはクライアント数の変動幅より十分大きくないと、プロセスの終了と起動の頻度が高くなり、結果として終了待ちプロセスの数が増えてしまいます。

MaxSpareThreadsをMaxClientsに合わせてしてしまえば、MaxSpareThreadsが理由でプロセスが終了することはなくなります。しかし、不要なプロセスを起動したままにするのも気持ちが悪いので、できることなら適切に終了させたいものです。

worker MPMの設定(前編)

ftp.jaist.ac.jpではHTTPサーバとしてApache HTTP Server (以降Apacheと略記)を使っています。lighttpdじゃないんですかって？ えぇ、違います。SourceForge.netのミラーネットワークに参加するためには、Apacheのmod_rewriteを前提にした複雑なURL書き換え規則を受け入れる必要があるので、Apacheでないとだめなんです。