ブラウザのベンチマーク (2)

バッテリー駆動 & ファンレスの自然空冷(手前のMacBook Air M4)で,SpeedoMeter 3.1でこれだけのスコアが出ることをApple Siliconを使ってない方々はご存じない.奥は強制空冷のM4 Mac mini.

以前,手持ちのいろんなPCの環境でSpeedoMeter3.1によるベンチマークを測定しました.

今回Raspberry Pi 4 Model B RAM 8GBにRaspberry Pi OS 13.4 (Trixie)を走らせてFirefoxで測定しました.スコアは0.668で最低新記録を更新しました.

Raspberry Pi 4 Model B RAM 8GB Raspberry Pi OS 13.4 Firefoxによるベンチマークスコア

M4 Mac miniでx86_64(AMD64)をエミュレートするより遅いとはなかなかです😓

比較表をupdateしました.

DescriptionSafariFirefoxChrome (Chromium)BraveOptionalComment
Macbook Air M450.639.256.353.7
M4 Mac mini51.740.056.053.8
M4 Mac mini w/Rosetta 249.916.60.785Intel binaryをRosetta 2で動かす.Chromeについては本文参照
iPhone 1428.5iOS 26.4
Intel Mac mini (2018)19.913.719.918.9Core i7 6-core 3.2GHz
Lenove ノートPC17.818.0 (Edge)Core i7-10750H 2.60GHz
Google PIXEL 8a16.2
Android 16
Manjaro Linux AMD6411.17.26 (Konqueror)Core i7-4790S 3.20GHz
Nixos Linux AMD649.7210.9 (Chromium)8.21 (GNOME Web)同上
Mac mini Late 20129.625.8710.69.55Core i7 quad-core 2.6GHz
Raspberry Pi 52.534.73 (Chromium)6.55Raspberry Pi OS 13.3 RAM 8GB
Raspberry Pi 4 Model B0.668Raspberry Pi OS 13.4 RAM 8GB

reset-failed

何気なくroot権限で1

systemctl status

で全体を眺めようとしたら,赤い字で “degraded” と出ます.

これまでも出ていたと思いますが気にしていませんでした.せっかくですからAI (Gemini)に聞いてみました.

systemctl --failed

で,certbot.timerであることがわかりました.以下省略しますが,もともとSlackwareでLet’s Encryptから証明書を “手動” で発行してもらっています.その場合,自動で更新できないようです.どっちみち管理しているもう一か所も手動なので,いつも2台続けて更新作業をしてきました.ですので,certbotによる自動更新を止めます.

systemctl disable --now certbot.timer
systemctl reset-failed certbot.service

これでめでたく “degraded” が消えました.

  1. 筆者はSlackware流儀のため,システムのメンテはroot権限で行いコマンド毎のsudoは使いません. ↩︎

Raspberry Pi 4しばらく登板 (2)

Raspberry Pi 4 (RPi4)で運用し始めてまる2日経過しましたが,問題は特にないです.WordPressの反応もSlackware ARM (32bit)で運用していたときより速い感じがします.

Fail2Banも着実に排除するIPアドレスを増やしていってます.

また,GUIがそれなりに動くのはいいです.Firefoxが使えるので,記事を書いたり修正するのも楽です.

Slackware ARM (32bit)でもKDEが動くのですが,ちゃんと動くWebブラウザーがないのが残念なところでした.KDE自体も重かったです.

その点Raspberry Pi OSの標準であるPIXELは軽量でいいです.

RAMは4GBでちょうどいい感じです.しばらくLAN内で続けて動かしている旧サーバーはRAM 8GBで,これももったいないのでいずれ入れ替えようと思います.

Orphan

以前経験したのに忘れてしまっていました.

サーバーをSlackware ARM 15.0からRaspberry Pi OS 13.3に切り替え,古いサーバーのデータなどを整理していたら,総容量が200GB程度まで減りました.

今まで1TBのSSDをつないでいましたが,半端な容量で使い道のない250GBのSSDがありこれに引っ越すことにしました.1TB SSDも空きます.

作業はManjaro AMD64 (x86_64)で行います.fdiskでGPTのパーティションを切り,mkfsでブート用のvfatとルートのext4をフォーマットします.

これが落とし穴で,Manjaroでフォーマットしたext4はSlackware 15.0では認識されないのです.

2回,コピーしてブートしてくれないので,インターフェースが悪いのかSSD自体が悪いのかなど悩みましたが,ManjaroでフォーマットしたボリュームはSlackwareでは読めないことを思い出しました.

このBLOGにもそれに関する記事があるはずですが今回見つけられませんでした😓

Geminiに聞いてみたら,古いKernelでは最新のmkfs.ext4のデフォルトでフォーマットしたボリュームはtoo newでマウントできないんだそうです.

回避策としては,

mkfs.ext4 -O ^orphan_file,^metadata_csum_seed /dev/sdXN

とします.あるいはSlackware上でフォーマットすればよいのです.

しかし,このような後方互換性のない新機能というのもちょっと困ったもんです.名前をext5にしてくれていればまだ分かりやすいものを.

Raspberry Pi 4しばらく登板

Raspberry Pi 5 (RPi5)による新サーバーの運用もだいたい目鼻がつきました.ここでいったんRPi5からRaspberry Pi 4 Model B (RPi4)にサーバー担当を交代しました.

実はこれが一番やりたかったことで,これまで,32bit OSのSlackware ARM 15.0をRPi4で動かしてきましたが,同じハードで64bit OSだとどれくらいパフォーマンスが違うのか,ということです.

ChatGPTによればArmv8では,64bit OS/アプリと32bit OS/アプリでそれほどパフォーマンスに目だった差はないとのことです.

Slackwareの頃のWordPressプラグインRedis Object Cacheのグラフを取っておけばよかったのですが,探したらありませんでした😓

これが,先ほどWordPressをRPi5からRPi4に切り替えたRedis Object Cacheの反応のグラフです.

Redis Object Cacheの反応時間.最大のピークは60 ms

最初の大きなピーク(60 ms)あたりがRPi4の起動したタイミングです.その前はRPi5ですから,両者の性能の差が顕著に出ています.たぶん,RPi4をSlackwareARMで動かしてきたときもこんなもんだったと思います😓

今回の件についてはChatGPTの言うことは正しかったようです.残念です.