gzip 圧縮されたファイルを最強の圧縮レベルで再圧縮

当サイト http://sonic64.com/ は、さくらインターネットのレンタルサーバーサービスを利用している。レンタルなので、ディスク容量が足りなくなっても自宅のクライアント PC と違って簡単に増設することはできない。ディスク容量は貴重だ。ディスクの1バイトは血の一滴。

で、さくらインターネットでディスクの無駄遣いを見つけた。さくらインターネットでは各ユーザーに apache のアクセスログが提供されていて、最新のログ以外は gzip で自動的に圧縮される。そのときの gzip のレベルが -9 になっていないので、ディスクスペースが無駄になっている。

非常に細かいんだけど、gzip の圧縮レベルがデフォルトの -6 と -9 では、圧縮後のファイルサイズで一日あたり100KB くらいの違いが出てくる。ログは1年分保存されるので、100KB * 365 = 36.5MB の差がある。これはちょっと無視できない。

というわけで、gzip 圧縮されたファイルを最強の圧縮レベルで再圧縮するスクリプトを書いた。

#!/bin/sh

find $HOME/log -type f -maxdepth 1 -mtime +1 -mtime -2 -regex .*.gz |xargs gunzip
find $HOME/log -type f -maxdepth 1 -mtime +1 -mtime -2 ! -regex .*.gz |xargs gzip -9

やってることはものすごく単純。単に2日前の圧縮ファイルを find で探し出して展開、その後最高の圧縮レベルを指定した gzip で再圧縮してるだけ。直近1日以内のファイルはまだ gzip されてないので除外。2日以上前のファイルは、このコマンドで処理済みなので除外。

これを cron で一日一回実行するために crontab に仕込んでおく。一応 nice コマンドでプロセスの優先度を最低にしておく。

# recompress with max compression level
5 6 * * * nice -19 $HOME/script/recompress_log.sh

ここまでやって思ったんだけど、これってさくらインターネットのサポートに要望として出した方がいいかな。そうすれば全ユーザーが幸せになれるな。よし、あとでサポートにメールしておこう。

ところで、この圧縮率の差が生まれる原因って、logrotate か rotatelogs あたりのオプションにあるのかな? それとも独自のシェルスクリプトか何かのオプションが原因なのかな。

追記。
2005-12-07 に『「gzip 圧縮されたファイルを最強の圧縮レベルで再圧縮」への指摘とその反応』を書いた。