DigiLoog

ファイルを固めたりバックアップを作成する時など利用頻度の高い圧縮・展開コマンドだが、
最近はファイル容量の増加が著しい割に、コマンドは数年前から変わっていない様に感じる。
記憶媒体の容量増加も進んでいるので圧縮しないケースが増えたのも事実だが、
やはり普段使わないファイルで容量を食うのは避けたいのが本音だと思う。

表題の圧縮率測定は6年前にコチラの記事で実施したが、
ここ数年でCPUに始まり、メモリやSSDのアクセス速度が向上した事もあり、
2022年に再調査したらどうなるのか気になった。

という事で、メジャー・マイナーな圧縮コマンドをインストールして処理速度を測定してみた。

アーカイブの展開速度はアルゴリズム・CPU処理速度・ディスクアクセスで大体決まるが、
圧縮速度は上記の3つが複雑に絡まる上、対象ファイルの容量も重要な速度要素となる。
純粋に比較するなら前回と同じ環境がベストだが、6年前と同じ環境を揃えるのは無理なので、
趣向を変えて誰でも同じ条件を再現出来るVPSを使いつつ複数回測定する方針に変更した。

● 実行環境

1. 新規にサーバインスタンスを作成し、CentOS Stream 9をテンプレートインストール
2. インストール直後に”dnf update”を実行して2022年02月05日の最新状態へアップデート
3. OSチューニングは行わず、出来る限り素の状態に近くして計測開始

VPS	ConoHa 東京リージョン
CPU	3コア (Intel Xeon Gold 6230 2.10GHz)
メモリ	2GB
SSD	100GB
OS	CentOS Stream 9 x86_64

● コマンドバージョン

コマンド	バージョン
gzip	1.10-8
bzip2	1.0.8-8
xz	5.2.5-7
zip	3.0-30
7zip	16.2-21
lzh	6.10
rar	1.14i

● 計測方法

1. バイナリファイルとテキストファイルに対して各圧縮コマンドを実行
2. 各コマンド事に6回の圧縮処理を実行する事で計測ブレを極力無くす
3. 圧縮率指定が出来るコマンドは、速度重視・指定無し・圧縮重視の3種類を測定
   ただし、アーカイブ化(＝無圧縮)オプションは計測を省略する
4. 時間計測にはLinuxのtimeコマンドを使い、real時間をファイル圧縮に要した時間とする
5. 圧縮率は『圧縮後のファイルサイズ ÷ 圧縮前のファイルサイズ』で算出
6. 圧縮対象の元ファイルは下記を利用
   テキストファイルは1度展開した後にtarコマンドで無圧縮アーカイブに固め直して計測

バイナリ	binary-0X.iso	CentOS-Stream-8-x86_64-20220202-boot.iso
テキスト	text-0X.tar	linux-5.16.6.tar.xz

今回は対象コマンドや計測回数が増加したので、次の様なスクリプトを実行して放置した。
コマンドを連発しているので仮想ホスト側で制限がかかる可能性もあるが、
気にしたらベアメタルサーバを持ち出さないとダメになるので諦めた。

#!/bin/sh date echo for LIST in `ls | egrep -iv "(bench|tmp)"` do echo ${LIST} time gzip -c ${LIST} > ${LIST}.gz echo "---" done ls -l du -l rm -rf *.gz

………

計測結果の生データとCSVファイルは下記ダウンロードリンクを参照。
そのままのデータなので二次加工もしやすい筈。

今回の計測条件で測定してみたらバイナリとテキストの両方とも7zipが圧倒的に速かった。
前回の時は7zipの処理速度が若干早い中、バランスが取れているのはbzip2の印象だったが、
内部処理が変わったのか躍進していた。
意外なのはxz形式でソースコードの圧縮でも利用される中、圧縮率重視の7zipには負けた。

圧縮率と処理速度の両方とも好成績なのがWindows利用されるrar形式だった。
テキストはそこまで圧縮出来なかったが、
バイナリは96.5%近くまで圧縮しつつ処理速度が2分程度という驚異の結果となった。
xz形式で同じ容量まで圧縮すると10分要する事からも、rarの完成度が出てきた結果となる。

Linuxで良く利用されるgzip・bzip2・xzは前回同様にバランスが取れた結果となった。
デファクトスタンダードとして使われる事が多い三つだが、
不得手なく処理出来るからこそ安定した圧縮率と処理速度を誇っていた。

結果をグラフにしたら、LZMA/LZMA2アルゴリズムを使うxz・7zip形式の速度が顕著になった。
その分、圧縮率が高いので処理速度が遅いのは仕方ない部分もあるが、
同種のアルゴリズムなのにxzと7zipで1.5～2.0倍の速度差が出ているのが気になった。

“ns-lab BB”は現行サーバ基盤へ刷新した時にログの圧縮形式をxzに変更したが、
ここまで顕著に速度差が出るなら7zipを試したい気持ちも若干出てきた。
だがkernelソースでも利用されているxzや、根強く認識のあるgzipはまだ現役な上、
Linuxで7zipは使い勝手が悪いのも事実だったりする。
そんな事もあり、当面はgzip・xzの二強と、間を補完するbzip2を使う事になると思われる。

6年前の計測結果から若干変わった結果となったが、デファクトスタンダードは早々変わらないので、
今後もgzip・bzip2・xzの三つがLinuxで使われる事となりそうだった。
でも、利用シーンによっては違う圧縮形式が選択肢になり得る事を把握した上でベストを選びたい。

« 続きを隠す

外部公開していない”ns-lab BB”サーバがインターネットへ通信する時、
NW経路の都合で仮想ルータを使ってNAPTする様にしている。
その仮想ルータにIIJ SEIL/x86を使っているのだが最新OSのAyameを弄る必要が出た。

というのも、IIJ SEIL/x86 Fujiが600円でばら撒かれていた時に購入したライセンスが尽きてしまい、
弾補充とAyame移行検証も兼ねてProxmox上の仮想インスタンスへ入れる事となった。

仮想インスタンスに割り当てたスペックは次の通り。
他にも仮想サーバが動いている環境だが、オーバーコミットしていないので遅延は少ない筈。

今回は10GBファイルをダウンロードするwgetを同時に3本実行して負荷をかけてみた。
上画像のターミナルはProxmox上のtopコマンドだが、SEILの仮想ゲストCPU負荷100%近かった。
下画像はSEILの負荷状況をSNMPで取得した物だが、こっちもCPU負荷が80%近くに上がっており、
両サイドから見たとしても負荷がかなり高い事がわかる。

今回は最低限のスペックしか割り当てていないので負荷が高い物と思われるが、
誤自宅が簡単に購入できるライセンスはCPU1コアの物なので、そもそも増強する事が難しい。
25万円出せばエンタープライズライセンスを購入出来るが石油王じゃないとこの金額を即出すのは辛い。
スタンダードライセンスでもCPUを2コアを積める様になれば速度を出せそうだが、
そんな環境はエンタープライズを買うか物理ルータを買えというお達しなんだと思う。

Fujiを利用している人がAyameを弄りだして面食らうのがコンフィグの作り方だと思う。
そもそもコマンド体系が全く違うのでドキュメント片手に格闘する必要が出てくるが、
SEIL弄っている人なら1時間弄れば慣れると思う。
実際に筆者も弄ってみたが2時間程度で大体の挙動とコマンド体系を覚える事が出来た。

結構よく出来ているのだが、Firewall設定の様に1行で多数のオプションを書くとバグる事があるので、
業務利用やコアな事をやるにはバグを飼いならすスキルと成熟が必要とも感じた。

慣れが必要な誤自宅向けルータではあるが、
Ciscoに程度慣れて違うメーカーに手を出したくなった人は是非とも弄ってもらいたい。

自宅サーバで運用しているProxmoxにスタティックルートを設定しようとしたら、
Web GUIから追加する方法が分からなかったのでメモ。
結論を先に書くと、Web GUIから追加する事は出来ずCLIで設定を直接弄る必要があった。

筆者のProxmox環境では、各NICでサーバインスタンスのトラフィックを出しつつ、
ホストサーバにも接続出来る様にする必要があった為、
物理NIC→ブリッジ→管理I/Fの様に仮想NICを構成している。

この状態でセグメント毎に戻り通信を分散出来るようにスタティックルートを書きたかったのだが、
画像の通りWeb GUIではゲートウェイ(デフォルトルート)しか設定出来なかった。
同じ事を考えている人は多いと思うので調べてみたら次のフォーラムがヒットした。

• Proxmox VE: Networking and Firewall > up ip route add is ignored

要約すると、”/etc/network/interfaces”にスタティックルートを直記するのが唯一の手段らしい。
筆者はmgmt1の”OVS IntPort”にプライベートIP宛のルーティングを切りたかったので次の様にした。

$ cat /etc/network/interfaces
auto mgmt1
iface mgmt1 inet static
    address 192.0.2.2/24
    post-up route add -net 10.0.0.0/8 gw 192.0.2.1
    post-up route add -net 172.16.0.0/12 gw 192.0.2.1
    post-up route add -net 192.168.0.0/16 gw 192.0.2.1
    ovs_type OVSIntPort
    ovs_bridge vmbr1

細かく設定するならpost-downとルーティング削除も追加すべきだが、
そこまで厳密な制御は今回いらなかったので設定しなかった。

………

2022年末頃のProxmox VE 7.2までは”route add”で動いていたのだが、
Proxmox VE 7.3でバグってしまったので下記に変更した。
何回か再起動もしてみたが問題なく適用出来ている。

$ cat /etc/network/interfaces
auto mgmt1
iface mgmt1 inet static
    address 192.0.2.2/24
    post-up ip route add 10.0.0.0/8 via 192.0.2.1 dev ${IFACE}
    post-up ip route add 172.16.0.0/12 via 192.0.2.1 dev ${IFACE}
    post-up ip route add 192.168.0.0/16 via 192.0.2.1 dev ${IFACE}
    pre-down ip route del 10.0.0.0/8 via 192.0.2.1 dev ${IFACE}
    pre-down ip route del 172.16.0.0/12 via 192.0.2.1 dev ${IFACE}
    pre-down ip route del 192.168.0.0/16 via 192.0.2.1 dev ${IFACE}
    ovs_type OVSIntPort
    ovs_bridge vmbr1

この設定でWeb GUIからmgmt1にデフォルトルートを切りなおしたり、
仮想NICのVLAN変更なども実施したが今の所問題なく動いている。
小技なのとDebian/Ubuntuに慣れた人ならお手の物だが、
RHEL使いやNetworkManagerを使っている人は意外と嵌るので備忘録としておく。