2022年02月07日(月) - 22:36 | カテゴリ:
Linux
ファイルを固めたりバックアップを作成する時など利用頻度の高い圧縮・展開コマンドだが、
最近はファイル容量の増加が著しい割に、コマンドは数年前から変わっていない様に感じる。
記憶媒体の容量増加も進んでいるので圧縮しないケースが増えたのも事実だが、
やはり普段使わないファイルで容量を食うのは避けたいのが本音だと思う。
表題の圧縮率測定は6年前にコチラの記事で実施したが、
ここ数年でCPUに始まり、メモリやSSDのアクセス速度が向上した事もあり、
2022年に再調査したらどうなるのか気になった。
という事で、メジャー・マイナーな圧縮コマンドをインストールして処理速度を測定してみた。
アーカイブの展開速度はアルゴリズム・CPU処理速度・ディスクアクセスで大体決まるが、
圧縮速度は上記の3つが複雑に絡まる上、対象ファイルの容量も重要な速度要素となる。
純粋に比較するなら前回と同じ環境がベストだが、6年前と同じ環境を揃えるのは無理なので、
趣向を変えて誰でも同じ条件を再現出来るVPSを使いつつ複数回測定する方針に変更した。
● 実行環境
- 新規にサーバインスタンスを作成し、CentOS Stream 9をテンプレートインストール
- インストール直後に”dnf update”を実行して2022年02月05日の最新状態へアップデート
- 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 |
● 計測方法
- バイナリファイルとテキストファイルに対して各圧縮コマンドを実行
- 各コマンド事に6回の圧縮処理を実行する事で計測ブレを極力無くす
- 圧縮率指定が出来るコマンドは、速度重視・指定無し・圧縮重視の3種類を測定
ただし、アーカイブ化(＝無圧縮)オプションは計測を省略する
- 時間計測にはLinuxのtimeコマンドを使い、real時間をファイル圧縮に要した時間とする
- 圧縮率は『圧縮後のファイルサイズ ÷ 圧縮前のファイルサイズ』で算出
- 圧縮対象の元ファイルは下記を利用
テキストファイルは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で使われる事となりそうだった。
でも、利用シーンによっては違う圧縮形式が選択肢になり得る事を把握した上でベストを選びたい。
« 続きを隠す
2022年01月30日(日) - 22:29 | カテゴリ:
Linux
自宅サーバで運用しているProxmoxにスタティックルートを設定しようとしたら、
Web GUIから追加する方法が分からなかったのでメモ。
結論を先に書くと、Web GUIから追加する事は出来ずCLIで設定を直接弄る必要があった。
筆者のProxmox環境では、各NICでサーバインスタンスのトラフィックを出しつつ、
ホストサーバにも接続出来る様にする必要があった為、
物理NIC→ブリッジ→管理I/Fの様に仮想NICを構成している。
この状態でセグメント毎に戻り通信を分散出来るようにスタティックルートを書きたかったのだが、
画像の通りWeb GUIではゲートウェイ(デフォルトルート)しか設定出来なかった。
同じ事を考えている人は多いと思うので調べてみたら次のフォーラムがヒットした。
要約すると、”/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を使っている人は意外と嵌るので備忘録としておく。
2021年11月28日(日) - 19:25 | カテゴリ:
Linux
CentOS 8のサポートが2021年末で終了すると発表され紆余曲折あったLinux界隈。
筆者も自宅サーバでCentOS 8を利用しているので、年末迄に方針を固める必要があった。
色々な環境を動かしているので、CentOS Streamが適切な検証環境もあったり、
Web・DNS・Mail・DBと安定稼働させたい本番系があるのも事実だった。
当初は全台をCentOS Streamに移行予定だったのだが、
以前試した時に謎の挙動をしたので、本番系は他のディストリビューションへ移行する事に。
AlmaLinuxとRockyLinuxの二つが候補となったが今回はRockyLinuxを採用する事にした。
という事で、RockyLinuxを選んだ経緯とアップグレードした結果を書こうと思う。
RockyLinuxへツールで引っ越したサーバのバージョンがこちら。標記もRockyに変わっていた。
移行には公式が準備しているツールを利用した。
そのままのコマンドだが、筆者が撃ち込んだ実際のコマンドは次の通り。
# curl https://raw.githubusercontent.com/rocky-linux/ \
rocky-tools/main/migrate2rocky/migrate2rocky.sh -o migrate2rocky.sh
# chmod u+x migrate2rocky.sh
# ./migrate2rocky.sh -r
# reboot
|
CentOS・AlmaLinux・RockyLinuxはRHEL 8と互換性があるので、
結果として3つのディストリビューションも相互に互換性がある。
そんな中で移行ツールも各ディストリビューションで公開されており、
万が一、開発停止になっても別の物に移行出来るのもRockyLinuxを選んだ理由となる。
ちなみに、OracleLinuxはJavaサポート切れとSolarisの恨みがあるのと、
MiracleLinuxは原資がコロコロ変わっている印象があり、不安要素が大きかったので没にした。
他の選定理由はCentOSと同じ構築体制を取っているのかあたりだが、
決定打はソフトウェアのアップグレードは比較的簡単だけどダウングレードは困難である点だった。
後ろ向きな意見となるが、殆どの場合でダウングレードは面倒臭いのが常なので、
万が一の時に移行先へアップグレードで引っ越し出来るかが重要になりそうと踏んだ。
RockyLinuxの方が数日レベルでリリースが遅いので、
今後開発が危うくなった時もAlmaLinuxへ引っ越しが出来るので、初回はRockyLinuxにした。
でも実際に引っ越した結果、問題は全く起きず正常稼働してくれているので継続利用しようと思う。
………
ちなみに、RHELの追従速度は次の通り。SecureBootもちゃんと対応していた。
| |
RHEL 8 |
AlmaLinux 8 |
RockyLinux 8 |
| v8.3 |
2020/11/03 |
2021/03/30 |
N/A |
| v8.4 |
2021/05/18 |
2021/05/26 |
2021/06/21 |
| v8.5 |
2021/11/09 |
2021/11/12 |
2021/11/15 |
| SecureBoot |
○ (v8.1) |
○ (v8.4) |
○ (v8.5) |
RockyLinuxが発足した直後は開発遅延も大きかったが、
体制が整ったらしく他と遜色ないリリース速度を出すまでになっている。
SecureBootも対応済で機能面で大きな差がが無い上、
コントリビューターも揃ってきている様なので、今後はリリース日の差が更に埋まると思う。
………
このWebサーバも既にRockyLinuxで稼働しているのだが、
バグ含めた100%の移植率を誇るだけあり問題なく稼働している。
ソースビルドしたアプリは勿論の事、自作したスクリプトや管理プログラムもそのまま動いている。
EPEL等のサードパーティリポジトリも使えており、本当の意味で移行コマンドを実行して完了した。
自鯖で本番利用している環境はRockyLinuxへ移行したが、
開発環境ではCentOS Streamを利用する上、KVMホストはCentOS 7を使い続けているので、
当面の間はCentOSを引き続き利用する事になりそう。
今回の騒動をマイナスに捉える人も多いが、
コミュニティが活発になり選択肢が増えるのはメリットと捉えているので、
今後もLinux界隈をウォッチしながら様々なディストリビューションを試していきたい。
« 続きを隠す
